3 ms·

>> It might sound naive, but why would fetching more JS later degrade the experience? I thought that bundle splitting was an accepted good practice. For example

>> It might sound naive, but why would fetching more JS later degrade the experience? I thought that bundle splitting was an accepted good practice. For example, you have your main core bundle, then some polyfill bundles (that get downloaded if the feature detector says it is needed), and then you have separate bundles for obscure and not-that-often-used stuff that gets loaded on demand. It is a genuine question, and I would like to learn what's wrong with this approach, because that's something I work with on a day-to-day basis. There isn’t anything wrong with this approach at all - keep doing this! It just doesn’t solve the initial load problem. This kind of code splitting _also_ happens on all google properties I am aware of. The problem here is what gets into the initial bundle, and is it enough to make the page useful. If the initial bundle isn’t enough to make the page useful, then the user has to wait for two requests to complete serially before they can perform their task.

jlokier 7y ago
> If the initial bundle isn’t enough to make the page useful, then the user has to wait for two requests to complete serially before they can perform their task. Since the alternative is just broken, I'm sure users with non-Google browsers would prefer a working page with one round-trip of extra latency. Meanwhile, it causes Chrome users no harm, they are unaffected. But anyway, there's no need for extra delay. You can put a coarse-grain "shall we load part 2" test inline in the HTML, and/or have the server predict from User-Agent (as a performance heuristic - and this can be automated). The above can provide the same, optimal latency to all different browsers, even when the site is beautifully well-tuned, 0RTT-optimised, TLS/3, QUIC service, with all the PUSH trimmings. (For even better performance you can select from multiple builds using the same heuristics, optimising out compatibility branches for other browsers on all browsers, not just the favourite. But this is not necessary, just to prevent the delay being discussed. It's an extra boost.) There is no latency excuse, just engineering deciding not to bother. Something Google should be criticised for, since they can afford to do better, have a monopoly, and claim to be a thought leader on open web standards.
- mattnewton 7y ago
  To be clear, I have no insight into the specific topic of the article (and I probably can’t comment on it if I did). I’m simply defending the process of segmenting experiences by user agent, which the original comment suggested could have been the cause, and also suggested that it was never best practice to do so. I think I’ve made a pretty good case that the original response from the server ought to be informed by the user agent string in an environment like YouTube, mainly for latency reasons. As for whether or not this particular issue is best solved by whitelisting and testing the new edge UA for this experience, or adding feature detection and testing that behavior with the new edge, isn’t really the same topic. And if this is what is happening, I’m not sure this method is “broken” here, it’s serving a working page to users with a preview browser.
  - danShumway 7y ago
    Original comment author here -- we can talk about using user agents to detect edge-case bugs as something that's valid to do. We can also talk about whitelisting specific user agents that don't require polyfills so you can speed up initial page load. I think these are reasonable things to suggest. So you're correct that there is some room for nuance and you're right to point that nuance out. But Youtube isn't doing either of those things -- it's assuming that a user agent it doesn't recognize by default isn't supported, and rather than serve a feature-detecting version of the page, it's serving users a message to use a different browser. I still maintain that this is basically never the right thing to do (or at least it's so close to "never" that doing so should require some very good, app-specific justifications). People are debating whether or not you can use JS to feature-detect every single specific bug, and whether or not you need to go the long path on feature-detection and do everything up front, or whether you can skip some steps for performance optimization, and they're missing the entire point of progressive enhancement. If you can detect Chrome or IE 6 and speed things up or avoid a bug, fine. But it's bad practice to rely on that detection. It's bad practice to have a single list of browsers you support and to turn everything off everywhere else. Partially because it's bad for the web in general, and partially because from a more practical perspective it's not always safe to assume that just because you see a user agent every feature you want will be supported -- extensions exist, custom-compiled browsers exist, and sometimes user agents are just reported wrong for fringe browsers. It's also just plain bad for the user because falling back on feature detection and adding a few seconds to page load is nearly always preferable to being told to download and install a new program. My original comment wasn't that user agent strings should be universally ignored, it was that it's unfortunate to see a company as respected as Google so fundamentally misunderstand something that's been widely taught as best-practice on the web for over a decade. I kind of feel like some of the people objecting are missing the forest for the trees -- talking about whether there's ever any valid reason at all to ever try to detect a specific browser instead of the underlying idea that the web uses a living standard and that it was designed to be client agnostic.

jlokier 7y ago

> If the initial bundle isn’t enough to make the page useful, then the user has to wait for two requests to complete serially before they can perform their task. Since the alternative is just broken, I'm sure users with non-Google browsers would prefer a working page with one round-trip of extra latency. Meanwhile, it causes Chrome users no harm, they are unaffected. But anyway, there's no need for extra delay. You can put a coarse-grain "shall we load part 2" test inline in the HTML, and/or have the server predict from User-Agent (as a performance heuristic - and this can be automated). The above can provide the same, optimal latency to all different browsers, even when the site is beautifully well-tuned, 0RTT-optimised, TLS/3, QUIC service, with all the PUSH trimmings. (For even better performance you can select from multiple builds using the same heuristics, optimising out compatibility branches for other browsers on all browsers, not just the favourite. But this is not necessary, just to prevent the delay being discussed. It's an extra boost.) There is no latency excuse, just engineering deciding not to bother. Something Google should be criticised for, since they can afford to do better, have a monopoly, and claim to be a thought leader on open web standards.

mattnewton 7y ago
To be clear, I have no insight into the specific topic of the article (and I probably can’t comment on it if I did). I’m simply defending the process of segmenting experiences by user agent, which the original comment suggested could have been the cause, and also suggested that it was never best practice to do so. I think I’ve made a pretty good case that the original response from the server ought to be informed by the user agent string in an environment like YouTube, mainly for latency reasons. As for whether or not this particular issue is best solved by whitelisting and testing the new edge UA for this experience, or adding feature detection and testing that behavior with the new edge, isn’t really the same topic. And if this is what is happening, I’m not sure this method is “broken” here, it’s serving a working page to users with a preview browser.
- danShumway 7y ago
  Original comment author here -- we can talk about using user agents to detect edge-case bugs as something that's valid to do. We can also talk about whitelisting specific user agents that don't require polyfills so you can speed up initial page load. I think these are reasonable things to suggest. So you're correct that there is some room for nuance and you're right to point that nuance out. But Youtube isn't doing either of those things -- it's assuming that a user agent it doesn't recognize by default isn't supported, and rather than serve a feature-detecting version of the page, it's serving users a message to use a different browser. I still maintain that this is basically never the right thing to do (or at least it's so close to "never" that doing so should require some very good, app-specific justifications). People are debating whether or not you can use JS to feature-detect every single specific bug, and whether or not you need to go the long path on feature-detection and do everything up front, or whether you can skip some steps for performance optimization, and they're missing the entire point of progressive enhancement. If you can detect Chrome or IE 6 and speed things up or avoid a bug, fine. But it's bad practice to rely on that detection. It's bad practice to have a single list of browsers you support and to turn everything off everywhere else. Partially because it's bad for the web in general, and partially because from a more practical perspective it's not always safe to assume that just because you see a user agent every feature you want will be supported -- extensions exist, custom-compiled browsers exist, and sometimes user agents are just reported wrong for fringe browsers. It's also just plain bad for the user because falling back on feature detection and adding a few seconds to page load is nearly always preferable to being told to download and install a new program. My original comment wasn't that user agent strings should be universally ignored, it was that it's unfortunate to see a company as respected as Google so fundamentally misunderstand something that's been widely taught as best-practice on the web for over a decade. I kind of feel like some of the people objecting are missing the forest for the trees -- talking about whether there's ever any valid reason at all to ever try to detect a specific browser instead of the underlying idea that the web uses a living standard and that it was designed to be client agnostic.