BeaconURL: instrumentation vs critical css and images

[Otto van der Schaaf]

I have have a rough draft [1] with a small change for having a separate option for specifying the path where beacons that involve critical images and css should be send.

I think that when people change the beacon url they want to:

- change the path to circumvent interception by adblockers

- change the server to defer processing

When they want to defer processing, they probably do not intend to send the critical css and images data to another server.

For the actual beacon data we need for optimization -  people can change that path, but should we further constrain that option to being to a path only? Or is there a scenario where people have a good reason to changing the domain?

I also noticed that BeaconURL can be specified in configuration at the directory level, but the usages in both mps and nps take the global option for comparing the incoming url, so this probably will not work. Is there any objection against changing the scope to server-level?

[1] https://github.com/pagespeed/mod_pagespeed/compare/oschaaf-master-beaconing-url?expand=1

Issue that triggered this is https://github.com/pagespeed/mod_pagespeed/issues/1291 

Otto