w3ctag / polyfills

Finding on polyfills
https://w3ctag.github.io/polyfills
18 stars 6 forks source link

Discussion on "Do not serve polyfills that are not required by the user" #9

Closed DavidBruant closed 7 years ago

DavidBruant commented 7 years ago

Shipping unnecessary bytes to users that don't need them wastes the user's time and data allowance. Polyfill authors following good practice may throw a warning if the polyfill is loaded when not needed.

Consider using techniques such as feature detection in the browser to dynamically determine which polyfills to use, or User-Agent based browser identification to do so on a server.

I would argue that feature detection for the sake of not sending unnecessary bytes leads to counter-productive results. Indeed, even in the best case, sending the correct polyfills can only go like this:

The website code can be sent in the middle, but has to wait until the second round-trip is over before being parsed and executed.

I believe the cost of network round-trip is always significantly bigger performance-wise than the cost of unnecessary bytes.

The User-Agent-based technique does not suffer from this problem.

triblondon commented 7 years ago

There are basically three approaches:

  1. Ship the polyfill to everyone regardless of browser support (fewer RTs and easy but wasteful on network and CPU)
  2. Perform feature detection on client (no wasted bytes or CPU, but extra RT)
  3. Perform feature detection on server (no wasted bytes, CPU or extra RTs, but can be unreliable and fragile)

I don't think we're ever going to achieve wide agreement on which of these is best but it does make sense to lean one way or the other in different circumstances (eg size of polyfill, % of browsers that need it). I think we could tweak the advice to be more along those lines.

triblondon commented 7 years ago

@DavidBruant would language like this help?

Shipping unnecessary bytes to users that don't need them wastes the user's time and data allowance, but performing feature detection first can delay the loading of necessary polyfills. It is generally better to optimise for modern browsers, so performing client-side feature detection and waiting for an extra script to load on older browsers is usually a good trade off. However, if the full set of polyfills you might need in the worst case constitutes a negligible overhead, then you could choose to serve the full set to all browsers.

DavidBruant commented 7 years ago

sounds good to me

triblondon commented 7 years ago

Wording added in #26, but example to be discussed in MIT F2F