First, someone visits a website where the site-owner has installed pagespeed. Pagespeed does many optimizations that are all-server side, like combining multiple css files into one to reduce round trips, and none of the blocklists interfere with these. There are other optimizations, though, where pagespeed needs to know something about how the webpage renders in a browser. For example, we have a filter "prioritize_critical_css" that looks over all the css on your page to figure out which rules are actually relevant, and it inlines just those rules at the top of the page. Because js can modify css we can't do this in the webserver by statically analyzing the css, instead we need to ask a real browser which css rules it ended up using. So on the first few requests pagespeed includes some js that computes which css rules applied, and sends a list of rules back via an xhr to /mod_pagespeed_beacon. Then on later requests the server-side code will use that information to make pages load more efficiently.
All of these optimizations are about making the site load faster for its users, they're open source, and they only send information back to the webserver you loaded the page from. If this sounds compatible with EasyPrivacy, I'd love it if you could whitelist our beacons. They are:
- /mod_pagespeed_beacon? (on apache)
- /ngx_pagespeed_beacon? (on nginx)
- /pagespeed_beacon? (in the future, when we clean up the mod vs ngx distinction)
(This was reported on our mailing list
https://groups.google.com/d/msgid/mod-pagespeed-discuss/b2005b7a-ad30-4231-a4b9-82b428356a4a%40googlegroups.com