Lofesa edited a comment on issue #1681: Uncacheable content, preventing rewriting of image URL: https://github.com/apache/incubator-pagespeed-ngx/issues/1681#issuecomment-594400620 Hi I can´t see the webp images, but don´t have the infinite loop. I see the debug messages that say "<!--4xx status code, preventing rewriting of.." on each resource, so pagespeed is unabe to fecht the resources.... maybe the ssl config don´t work. About nginx proxy... Have you stopped the service? I see it in the [Plesk doc](https://docs.plesk.com/en-US/obsidian/administrator-guide/web-servers/apache-and-nginx-web-servers-linux/apache-with-nginx/turning-off-nginx.70837/#turning-off-nginx) Whats happens with cache-control header? Pagespeed need that resources have a public cacheable cache-control header, the max-age value is used as the ttl (time to live) in the pagespeed cache, so if you set it to 5 minutes, pagespeed make the resource outdated every 5 min in their cache, and all the optimization process for that resource, restart again. When you say "We have a lot of dynamic content on the website that needs to be updated every 5 minutes or so...", you are talking about content, but for sure js , images or css files don´t change, so you can set their cache-control to 1 day or more time. The cache-control header say to the browser how much time the resource is valid in their cache, so the browser don´t need to download it again until it become outdated. When a resource become optimized by pagespeed, pagespeed changes their cache-control to 1 year.... What happens if the resource changes before this time? Well.. pagespeed set a hash in each optimized url, so if the resource changes, the hash change and you get a different url, that is cached for 1 year. But for now... What I can see in your site: 1,- The server header still be nginx, so the nginx proxy is in place 2.- I see the x-mod-pagespeed header, so the pagespeed module is in the background apache server 3.- I see that the home page has 2 cache-control headers, 1 with 3600,public and 1 with nocache,must-revalidate, max-age=0 4.- All others resources in the home page has a valid cache-control header with 3600, public 5.- When in debug mode, all resources have these message "<!--4xx status code, preventing rewriting of.." so pagespeed is unable to fecht the resources and then can´t optimize it. Maybe you have set the FechtHttps directives in the wrong place or your server has the certificate directory in other place. 6.- I see you have a rewrite rule to change www.weedstreet420.com to weedstreet420.com , maybe you need to add an auth directive to cover all variants, some like: ModPagespeedDomain http*://*.example.org By default pagespeed only authorize the http version from where the resources are served. With this directive you are authorizing pagespeed to rewrite all versions of your site, http/https and all the subdomains (mainly www and non-www versions). But my bet is that the ModPagespeedFetchHttps enable ModPagespeedSslCertDirectory directory ModPagespeedSslCertFile file are pointing to a bad directory/file. What linux distro are you using? If a debian/ubuntu, can you test that /etc/ssl/certs exists han have files in it? or if a redhat/centos this directory /etc/pki/tls/certs exist and have a cert.pem file in it? EDIT: As far as I can see, the images that are rewrited, like bg6.png or weedstreet420_logo.png, in the html code are relative url, images with and absolute url get the "<!--4xx status code,..." message. For me, this confirm that the problem is pagespeed can´t fecht resources over https.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
