4 ms·

> 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

> 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
  I hope I've shown that I agree with you, 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". But, differently from YouTube, it's possible to serve a latency-optimised, user agent-optimised response in such a way that it's just a performance heuristic, without changing the actual functionality, which is still determined by traditional feature detection to the extent that is possible to do. When it's implemented that way, it's quite safe to serve the "wrong" response sometimes. Because it's safe to serve the wrong response, that allows automatic latency optimsiation, instead of brittle, hard-coded rules that will be wrong sometimes. Inputs are user-agent, client IP, client cookie state, and feedback about whether other resource bundles were fetched as well, or other kinds of feedback such as detected features. Output is which bundle to serve. This may improve performance over a hard-coded approach, because it adapts continually to new user-agents out there. Yet it is still coded as traditional feature detection (for features where that's possible), and works the way feature detection has always worked.

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
I hope I've shown that I agree with you, 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". But, differently from YouTube, it's possible to serve a latency-optimised, user agent-optimised response in such a way that it's just a performance heuristic, without changing the actual functionality, which is still determined by traditional feature detection to the extent that is possible to do. When it's implemented that way, it's quite safe to serve the "wrong" response sometimes. Because it's safe to serve the wrong response, that allows automatic latency optimsiation, instead of brittle, hard-coded rules that will be wrong sometimes. Inputs are user-agent, client IP, client cookie state, and feedback about whether other resource bundles were fetched as well, or other kinds of feedback such as detected features. Output is which bundle to serve. This may improve performance over a hard-coded approach, because it adapts continually to new user-agents out there. Yet it is still coded as traditional feature detection (for features where that's possible), and works the way feature detection has always worked.