Polyfill as Needed With Polyfill-Service
Polyfill as Needed With Polyfill-Service
In this article, a web developer shows how to maximize the performance of loading polyfills for your application users using an open source tool he created.
Join the DZone community and get the full member experience.Join For Free
Have you seen our HERE Twitch channel to livestream our Developer Waypoints series?
So what did I do to fix my IE10 bug? Well, one thing that really bugs me is that I have to ship all this code for polyfills to all browsers even if they do support these features. But a few years ago I heard of a service that was able to ship polyfills that are relevant only to the browser requesting them. I created my own endpoint that uses the module that powers that service and I'll write about that next week!
That's today's article! I'll explain how I created a
With the way I have my usage of polyfill-service configured today, if I make a request for
The state of the art with polyfills is to include those polyfills in your
bundle.jsfile (in fact, lots of apps are just using all of
If I run Chrome 67 on my
polyfill.js file, it comes back basically empty. By using polyfill-service, only the browsers which need the polyfills receive them. This means that they can use my app quicker and I'm not taking up some of your bandwidth to download stuff you don't need (which actually means saving people actual dollars if they don't have unlimited data).
Another aspect of using something like polyfill-service is that, because my polyfills live in a completely different file from my
bundle.js, I can have it cached forever, so users only need to download it once and never need to download it again. So even for users on bad networks, they'll benefit from not having to expend resources re-downloading a file that will never change.
The polyfill.io service from Financial Times is awesome, but with no SLA (service level agreement), many companies can't rely on it for mission-critical applications. Luckily, the module that powers it is completely open source so you can set up your own service in-house in a pretty straightforward way and that's exactly what I did.
With the app I'm working on right now (paypal.me), we have a server that's responsible for some light server-rendering for SEO purposes. Basically, our server is a Node.js server using KrakenJS (a wrapper on top of Express), so I added a
get handler to the Express app:
And with the
getBrowserPolyfill is a typical express route handler:
There's a little bit more to it, but this is the basic idea. So let's talk about a few aspects of this solution.
So the polyfill-service module needs to know what the user agent string is to determine what the
req.headers['user-agent'] as that value, though I allow the
ua query string to override this and I have a fallback to IE 9 just in case. And in the case that polyfill-service encounters a user agent it doesn't recognize, I have it configured to just treat it as if it needs all the polyfills (via the
unknown: 'polyfill' option).
There are a LOT of features that polyfill-service supports out of the box. It defaults to the most useful ones, but it's a good idea to configure it. At first I thought: "Hey, let's just have it support everything." But then I found out that if you asked it to polyfill everything it could, it'll get HUGE (mostly because it actually supports
Intl with every language pack which is kinda reeeally big). So I ended up with specifying
default-3.6 as the features config. That's working great and supports everything that I care to support.
This one's a bit interesting. So that
shouldCacheAggressively is a bit dangerous, so here's what I do... Because we're server-rendering the page, I can actually generate the URL for the polyfill. It ends up looking like this (for IE 11):
There are two query strings on there:
v which is associated to a
version that I have hard-coded. This allows me to break the cache in the event of an emergency if we need to change the config or something.
I also generate it with the
ua which is the user agent as part of the query string for the
polyfill.js file. Remember how I mentioned earlier that I allow the
uqquery string to override
req.headers['user-agent']? So that's what this is doing. The reason I do this is for caching. With such a specific URL, I can safely cache this forever. If the user upgrades (or downgrades!?) their browser, but the cache isn't deleted, then this URL is changed and the old cached version isn't used.
One "fun" experience I had while building this involved polyfill-service not playing nice with the way that Babel transpiles classes. Follow that Twitter thread and GitHub issues linked for a "fun" time of your own...
Best of luck to you!my newsletter .
Published at DZone with permission of Kent C. Dodds . See the original article here.
Opinions expressed by DZone contributors are their own.