#ASKTHEINDUSTRY 28: Can I use Link Preload across all browsers today ?
We talked about link rel=preload before. As a quick reminder: <link rel=”preload”> is the standard way for loading files asynchronously via markup. Preload is a very powerful declarative primitive for fetching resources, but its most common use case scenario is for loading non-critical CSS.
In the past, I’ve recommended using a code snippet by the filament group called loadCSS, in order to asynchronously request a stylesheet, so not to block rendering the initial content. However, relying on JavaScript for this process presents the drawback of bypassing all the good stuff the browser is optimized for: assets prioritization, optimal network utilization and so on. In addition, the parser needs to first discover your snippet, then parse it and only then it can finally execute and kick off the request.
Preload is great way to hand control back to the browser, and to move the request slightly upper in the chain. What about browser support though?
According to caniuse.com, things are not looking so good:
We can mix the two though, and adopt a Progressive Enhancement based approach: browsers supporting Preload will benefit from it, the rest will simply fallback to regular loadCSS via JavaScript. Here’s how:
- use <link rel=”preload” as=”style” href=”path/to/resource.css”> as you normally would
- inline this very tiny preload polyfill (679 bytes decompressed)
- inline loadCSS as well (809 bytes decompressed)
This way, you can greatly improve the performance of your website at the cost of just 718 bytes gzipped (!!)
For extra bonus points you can include a regular <link rel=stylesheet”> in a <noscript> tag, to support js-disabled environments.
If you’ve found this post useful at all, press the ❤ button! I read each and every comment, so be sure to contribute to the conversation with your thoughts!
