Improve downstream cache configuration

[nikolay]

If one follows the downstream cache configuration, the following issues will arise:

• Your Nginx configuration gets polluted with settings that are specific to a concrete version of PageSpeed and you need to be aware of exactly what optimizations are performed for which browser (capabilities) so that you can segment the cache by groups of features;
• Your site becomes vulnerable to crawlers as anything that's not recognized as a valid browser receives live requests.

I suggest adding a command that will return a simple cache segment based on the user agent into a variable. This way both the Nginx configuration will be simplified and it always be up-to-date with the underlying version of PageSpeed. User agents for which PageSpeed refuses to do any optimizations should return a separate segment, i.e. they still can be cached vs getting live requests, which can make a site vulnerable.

I also suggest adding an option to strip Google Analytics tracking query string parameters as an option. I only dare to suggest this as there's already a command to add the Google Analytics script, so, it makes one finished solution if your backend does not use those. It's not so easy to do a bunch of URL rewrites to remove Google Analytics tracking codes so that you don't become traffic-vulnerable due to cache busting.

[jeffkaufman]

@anupamadutta

[nikolay]

@jeffkaufman I just saw last week that the downstream caching configuration has changed and pretty dramatically in some aspects and it differs than then one you're using in your testing scripts. Which why should I'd rather implement? From the article or from your tests?

[oschaaf]

@nikolay can I close this?

[nikolay]

@oschaaf I'd rather not for the public good, I'm fine as I closely monitor the changes, and have now a lengthy configuration to deal with the issues I listed, but it's really painful if you have to implement it and start from 0.