3 ms·

> Everyone who visits the site will need essentially all of these files. Not necessarily. For instance, I wholly block JavaScript and as a result I could avoi

> Everyone who visits the site will need essentially all of these files. Not necessarily. For instance, I wholly block JavaScript and as a result I could avoid downloading ~283 KB of JavaScript resources from your page (out of ~412 KB resources in total). I could read your page fine. If I understand correctly, with a WebBundle there would be no way for me to avoid downloading resources which are explicitly meant to not be downloaded by the way I configured my user agent?

jefftk 6y ago
Nearly all of the JavaScript on my page comes from two third-party loads: ga.js and gpt.js. As I describe in the post, bundling wouldn't work well for including third-party resources (for the same reasons that it is uncommon for sites to proxy third-party resources onto their own domains today). Specifically in the case of first party JavaScript, however, you are right. A site might decide to serve all of its first party resources in a bundle, and people who don't run JS would end up downloading some extra bytes. This is a situation we commonly have already, however, when there is HTML or CSS that is only ever used when activated by JavaScript. I do think you're right that this would mean people in your position would end up downloading slightly more useless bytes, but not by a large fraction?
- gorhill 6y ago
  > it is uncommon for sites to proxy third-party resources onto their own domains Isn't the purpose of Signed HTTP Exchanges to be able to deliver 3rd-party resources from another domain?
  - yencabulator 6y ago
    That would leave Google Ads at the mercy of people updating their local copies, to make any changes. I doubt they want that.
    - jefftk 6y ago
      It would also make it difficult to canary new versions of JavaScript by serving a new version to only a small fraction of traffic.
  - jefftk 6y ago
    First, WebBundles and Signed HTTP Exchanges (SXG) are separate proposals. A bundle lets you serve multiple resources and response to a single request, while SXG lets one site serve content from another site in a way that the browser can verify authenticity and integrity. Snyder's post and my response are only about bundles (despite Snyder saying that he intends to treat multiple proposals in a single one). > Isn't the purpose of Signed HTTP Exchanges to be able to deliver 3rd-party resources from another domain? Essentially, but only in cases where the origin matters. JavaScript doesn't care about its origin: all that matters is that the right code. Loading adsbygoogle.js from a Google domain vs the publisher rehosting it on their own domain both results in the same script execution. Where origin matters is primarily in the URL bar. SXG allows one site (ex: search engine, social network, content aggregator) to speed up navigation to another site. Browsers have, over time, experimented with various forms of page preloading. They all have the problem, however, that the site being preloaded needed to be contacted to request the page. This is a problem from a privacy perspective, because if you search for "mattress" on a search engine, the search engine is reasonably confident you're going to click on the first result and hints to the browser that a preload would be a good idea, the site gets a hit from your browser whether or not you end up visiting the page. Now the operators of the first hit page have learned that you are likely searching for mattresses. SXG allows destination pages to opt into allowing the originating page to cache a copy for a limited time, giving you privacy preserving preloading. This is another approach to the main problem that AMP tried to solve: instead of only working if pages follow a declarative spec, it works on any page that opts in but it requires an extension to the spec and some browser work.
- kuschku 6y ago
  > Nearly all of the JavaScript on my page comes from two third-party loads: ga.js and gpt.js Well if you're using Google Analytics and Publisher Tags, you're not the kind of person to care about your users' experience anyway...
  - jefftk 6y ago
    My visitors who don't want analytics/ads run ad blockers, and won't show up in my analytics or load my ads. That seems like a fine solution? The ads are relatively unobtrusive, all the way at the bottom of the page.

jefftk 6y ago

Nearly all of the JavaScript on my page comes from two third-party loads: ga.js and gpt.js. As I describe in the post, bundling wouldn't work well for including third-party resources (for the same reasons that it is uncommon for sites to proxy third-party resources onto their own domains today). Specifically in the case of first party JavaScript, however, you are right. A site might decide to serve all of its first party resources in a bundle, and people who don't run JS would end up downloading some extra bytes. This is a situation we commonly have already, however, when there is HTML or CSS that is only ever used when activated by JavaScript. I do think you're right that this would mean people in your position would end up downloading slightly more useless bytes, but not by a large fraction?

gorhill 6y ago
> it is uncommon for sites to proxy third-party resources onto their own domains Isn't the purpose of Signed HTTP Exchanges to be able to deliver 3rd-party resources from another domain?
- yencabulator 6y ago
  That would leave Google Ads at the mercy of people updating their local copies, to make any changes. I doubt they want that.
  - jefftk 6y ago
    It would also make it difficult to canary new versions of JavaScript by serving a new version to only a small fraction of traffic.
- jefftk 6y ago
  First, WebBundles and Signed HTTP Exchanges (SXG) are separate proposals. A bundle lets you serve multiple resources and response to a single request, while SXG lets one site serve content from another site in a way that the browser can verify authenticity and integrity. Snyder's post and my response are only about bundles (despite Snyder saying that he intends to treat multiple proposals in a single one). > Isn't the purpose of Signed HTTP Exchanges to be able to deliver 3rd-party resources from another domain? Essentially, but only in cases where the origin matters. JavaScript doesn't care about its origin: all that matters is that the right code. Loading adsbygoogle.js from a Google domain vs the publisher rehosting it on their own domain both results in the same script execution. Where origin matters is primarily in the URL bar. SXG allows one site (ex: search engine, social network, content aggregator) to speed up navigation to another site. Browsers have, over time, experimented with various forms of page preloading. They all have the problem, however, that the site being preloaded needed to be contacted to request the page. This is a problem from a privacy perspective, because if you search for "mattress" on a search engine, the search engine is reasonably confident you're going to click on the first result and hints to the browser that a preload would be a good idea, the site gets a hit from your browser whether or not you end up visiting the page. Now the operators of the first hit page have learned that you are likely searching for mattresses. SXG allows destination pages to opt into allowing the originating page to cache a copy for a limited time, giving you privacy preserving preloading. This is another approach to the main problem that AMP tried to solve: instead of only working if pages follow a declarative spec, it works on any page that opts in but it requires an extension to the spec and some browser work.
kuschku 6y ago
> Nearly all of the JavaScript on my page comes from two third-party loads: ga.js and gpt.js Well if you're using Google Analytics and Publisher Tags, you're not the kind of person to care about your users' experience anyway...
- jefftk 6y ago
  My visitors who don't want analytics/ads run ad blockers, and won't show up in my analytics or load my ads. That seems like a fine solution? The ads are relatively unobtrusive, all the way at the bottom of the page.