To add PageSpeed to your reverse proxy chain, you must add it through the local CLI, by running the following command within the directory of your repository:
section append pagespeed:188.8.131.52
After running this command, you will notice a pagespeed directory within your repo containing two files named
http.conf place any PageSpeed directives that need to be specified at the nginx “HTTP” level, and place all other directives within the
PageSpeed has it’s own internal cache which causes problems when used alongside the Varnish Cache reverse proxy. You will need to add a VCL file located here, to your
varnish directory. You will then need to add the following code snippet above your
vcl_recv block in your
pagespeed-requirement.vcl from above will split user-agents in to five groups, each with different support for capabilities such as WebP, Lazy load images and different type of screensize. Be aware that this will also split Varnish Cache up in to 5 different buckets to ensure user-agents with different capabilities are served only from the bucket that stored assets corresponding to those capabilities. This is great for high traffic sites despite the splitting of the cache. High traffic should ensure the caches are populated while also receiving the benefits of user-agent specific optimisations.
If you would prefer higher Varnish Cache hit rates as opposed to user-agent specific optimisations, then you should remove all the logic under
sub pagespeed_capability_detection in
pagespeed-requirement.vcl and replace it with a single line
set req.http.PS-CapabilityList = "fully general optimizations only";
This will only enable optimisations which will work on all user-agents and will not split the cache up in to multiple buckets. This is better for low traffic sites and/or if you wish to maximise cache hit rate, which in turn minimises load on the origin.
When IPRO is enabled, the URL for an asset such as
123.jpg will not be changed to Pagespeed URLs such as
123.jpg. If the resource has not finished optimising, Pagespeed will send an
s-maxage=10 value in the Cache-Control header so Varnish Cache will only keep that asset for 10 seconds then recheck with Pagespeed if that asset is requests after 10 seconds. Once the asset is optimised, Pagespeed will send a much longer Cache-Control header so Varnish Cache will store the optimised asset for longer.
pagespeed InPlaceResourceOptimization on;
To turn PageSpeed on and off simply change line 1 in your default
server.conf file located in your pagespeed directory on your application repository:
If you want PageSpeed turned on:
If you want PageSpeed turned off:
By default we have enabled only the specific filters listed in EnableFilters, not the PageSpeed CoreFilters on line 7 of the default
pagespeed RewriteLevel PassThrough;
This link here provides a list of filters available with PageSpeed’s EnableFilters. To enable or disable any of the filters just append or remove the filter name from line 10 of the default
If you wish to see debugging information about a certain page, perhaps trying to find out why an asset isn’t being optimised by Pagespeed, you can view source on the page you are trying to debug. Then add this querystring
?PageSpeedFilters=+debug to the view-source URL. If the URL of the page already contains querystrings, use
&PageSpeedFilters=+debug. You should now see comments next to assets that indicate reasons why is was not optimised. e.g.
<!--Resource headers are preventing rewriting of https://www.example.com/123.gif-->
To learn how to configure PageSpeed, please check out the PageSpeed config documentation.
Below are a list of all the PageSpeed filters with links to instructions on how to properly implement them within your
server.conf file. You will be following the nginx configuration instructions as PageSpeed is configured with nginx on section.io.