Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Preload: What Is It Good For?

Preload (spec1) is a new web standard aimed at improving performance and providing more granular loading control to web developers. It gives developers the ability to define custom loading logic without suffering the performance penalty that script-based resource loaders incur.

Further reading on Smashing: Link

A few weeks ago, I shipped9 preload support in Chrome Canary, and barring unexpected bugs it will hit Chrome stable in mid-April. But what is that preload thing? What does it do? And how can it help you?

Well, <link rel="preload"> is a declarative fetch directive.

In human terms, it’s a way to tell a browser to start fetching a certain resource, because we as authors (or as server administrators, or as smart-server developers) know that the browser is going to need that particular resource pretty soon.

Didn’t We Already Have That? Link

Kinda, but not really. <link rel="prefetch"> has been supported on the web for a long while, and has decent browser support10. On top of that we’ve also supported <link rel="subresource">11 in Chrome for some time. So what’s new about preload? How is it different from these other directives? They all tell the browser to fetch things, right?

Well, they do, but there are significant differences between them. Differences that warrant a shiny new directive that tackles many use cases that the old ones never did.

<link rel="prefetch"> is a directive that tells a browser to fetch a resource that will probably be needed for the next navigation. That mostly means that the resource will be fetched with extremely low priority (since everything the browser knows is needed in the current page is more important than a resource that we guess might be needed in the next one). That means that prefetch’s main use case is speeding up the next navigation rather than the current one.

<link rel="subresource"> was originally planned to tackle the current navigation, but it failed to do that in some spectacular ways. Since the web developer had no way to define what the priority of the resource should be, the browser (just Chrome and Chromium-based browsers, really) downloaded it with fairly low priority, which meant that in most cases, the resource request came out at about the same time that it would if subresource wasn’t there at all.

How Can Preload Do Better? Link

Preload is destined for current navigation, just like subresource, but it includes one small yet significant difference. It has an as attribute, which enables the browser to do a number of things that subresource and prefetch did not enable:

  • The browser can set the right resource priority, so that it would be loaded accordingly, and will not delay more important resources, nor tag along behind less important resources.
  • The browser can make sure that the request is subject to the right Content-Security-Policy12 directives, and doesn’t go out to the server if it shouldn’t.
  • The browser can send the appropriate Accept headers based on the resource type. (e.g. advertise support for “image/webp” when fetching images)
  • The browser knows the resource type so it can later determine if the resource could be reused for future requests that need the same resource.

Preload is also different since it has a functional onload event (which, at least in Chrome, wasn’t working for the other two rel values).

On top of that, preload does not block the window’s onload event, unless the resource is also requested by a resource that blocks that event.

Combining all these characteristics together enables a bunch of new capabilities that were not possible until now.

Let’s go over them, shall we?

Loading Of Late-Discovered Resources Link

The basic way you could use preload is to load late-discovered resources early. While most markup-based resources are discovered fairly early by the browser’s preloader13, not all resources are markup-based. Some of the resources are hidden in CSS and in JavaScript, and the browser cannot know that it is going to need them until it is already fairly late. So in many cases, these resources end up delaying the first render, the rendering of text, or loading of critical parts of the page.

Now you have the means to tell the browser, “Hey, browser! Here’s a resource you’re going to need later on, so start loading it now.”

Doing so would look something like:

<link rel="preload" href="late_discovered_thing.js" as="script">

The as attribute tells the browser what it will be downloading. Possible as values include:

  • "script",
  • "style",
  • "image",
  • "media",
  • and "document".

(See the fetch spec14 for the full list.)

Omitting the as attribute, or having an invalid value is equivalent to an XHR request, where the browser doesn’t know what it is fetching, and fetches it with a fairly low priority.

Early Loading Of Fonts Link

One popular incarnation of the “late-discovered critical resources” pattern is web fonts. On the one hand, in most cases they are critical for rendering text on the page (unless you’re using the shiny font-display CSS values15). On the other hand, they are buried deep in CSS, and even if the browser’s preloader parsed CSS, it cannot be sure they’d be needed until it also knows that the selectors that require them actually apply to some of the DOM’s nodes. While in theory, browsers could figure that out, none of them do, and if they would it could result in spurious downloads if the font rules get overridden further down the line, once more CSS rules come in.

In short, it’s complicated.

But, you could get away from all that complexity by including preload directives for fonts you know are going to be needed. Something like:

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

One point worth going over: You have to add a crossorigin attribute16 when fetching fonts, as they are fetched using anonymous mode CORS17. Yes, even if your fonts are on the same origin as the page. Sorry.

Also, the type attribute is there to make sure that this resource will only get preloaded on browsers that support that file type. Right now, only Chrome supports preload, and it does support WOFF2 as well, but more browsers may support preload in the future, and we cannot assume they’d also support WOFF2. The same is true for any resource type you’re preloading and which browser support isn’t ubiquitous.

Dynamic Loading Without Execution Link

Another interesting scenario that suddenly becomes possible is one where you want to download a resource because you know you’d need it, but you don’t yet want to execute it. For example, think of a scenario where you want to execute a script at a particular point in the page’s life, without having control over the script (so without the ability to add a runNow() function to it).

Today, you are very limited in the ways you can do that. If you only inject the script at the point you want it to run, the browser will have to then download the script before it can be executed, which can take a while. You could download the script using XHR beforehand, but the browser will refuse to reuse it, since the resource wasn’t downloaded with the same type as the one that is now trying to use the resource.

So what can you do?

Before preload, not much. (In some cases you can eval() the contents of the script, but that’s not always feasible nor without side effects.) But with preload you can!

var preload = document.createElement("link");
link.href = "myscript.js";
link.rel = "preload";
link.as = "script";
document.head.appendChild(link);

You can run that earlier on in the page load process, way before the point you want the script to execute (but once you’re fairly confident that the script loading will not interfere with other, more critical resources that need loading). Then when you want it to run, you simply inject a script tag and you’re good.

var script = document.createElement("script");
script.src = "myscript.js";
document.body.appendChild(script);

Markup-Based Async Loader Link

Another cool hack is to use the onload handler in order to create some sort of a markup-based async loader. Scott Jehl18 was the first to experiment19 with that, as part of his loadCSS library. In short, you can do something like:

<link rel="preload" as="style" href="async_style.css" onload="this.rel='stylesheet'">

and get async loaded styles in markup! Scott also has a nice demo20 page for that feature.

The same can also work for async scripts.

We already have <script async> you say? Well, <script async> is great, but it blocks the window’s onload event. In some cases, that’s exactly what you want it to do, but in other cases less so.

Let’s say you want to download an analytics script. You want it to download fairly quickly (to avoid losing visitors that the analytics script didn’t catch), but you don’t want it to delay any metrics that impact the user experience, and specifically, you don’t want it to delay onload. (You can claim that onload21 is not the only metric that impacts users, and you would be right, but it’s still nice to stop the spinning loading icon a bit sooner).

With preload, achieving that is easy:

<link rel="preload" as="script" href="async_script.js"
onload="var script = document.createElement('script');
        script.src = this.href;
        document.body.appendChild(script);">

(It’s probably not a great idea to include long JS functions as onload attributes, so you may want to define that part as an inline function.)

Responsive Loading Link

Since preload is a link, according to the spec it has a media attribute. (It’s currently not supported in Chrome, but will be soon.) That attribute can enable conditional loading of resources.

What is that good for? Let’s say your site’s initial viewport has a large interactive map for the desktop/wide-viewport version of the site, but only displays a static map for the mobile/narrow-viewport version.

If you’re being smart about it, you want to load only one of those resources rather than both. And the only way to do that would be by loading them dynamically, using JS. But by doing that, you’re making those resources invisible to the preloader, and they may be loaded later than necessary, which can impact your users’ visual experience, and negatively impact your SpeedIndex22 score.

What can we do to make sure the browser is aware of those resources as early as possible?

You guessed it! Preload.

We can use preload to load them ahead of time, and we can use its media attribute so that only the required script will be preloaded:

<link rel="preload" as="image" href="map.png" media="(max-width: 600px)">

<link rel="preload" as="script" href="map.js" media="(min-width: 601px)">

Headers Link

One more feature that comes along free with link tags is that they can be represented as HTTP headers23. That means that for most markup examples I showed above, you can have an HTTP response header that does exactly the same thing. (The only exception is the onload-related example. You cannot define an onload handler as part of an HTTP header.)

Examples for such HTTP response headers may look like:

Link: <thing_to_load.js>;rel="preload";as="script"

Link: <thing_to_load.woff2>;rel="preload";as="font";crossorigin

HTTP headers can come in handy when the person doing the optimization is not the same person who’s responsible for editing the markup. The prominent example is an external optimization engine that scans the content and optimizes it (full disclosure: I work on one24).

Other examples can include a separate performance team that wants to add such optimizations, or an optimization build process where avoiding HTML fiddling significantly reduces complexity.

Feature Detection Link

One last point: In some of our examples above, we’re relying on the fact that preload is supported for basic functionality such as script or style loading. What happens in browsers where this is not true?

Everything breaks!

We don’t want that. So as part of the preload effort, we also changed the DOM spec so that feature detection of supported rel keywords would be possible.

An example feature detection function could look something like:

That enables you to provide fallback loading mechanisms in cases where the lack of preload support would break your site. Handy!

Doesn’t HTTP/2 Push Cover Those Same Use Cases? Link

Not really. While there is some overlap between the features, for the most part, they complement each other.

HTTP/2 Push has the advantage of being able to push resources that the browser hasn’t sent the request for yet. That means that Push can send down resources before the HTML even started to be sent to the browser. It can also be used to send resources down on an open HTTP/2 connection without requiring a response on which HTTP Link headers can be attached.

On the other hand, preload can be used to resolve use cases that HTTP/2 cannot. As we’ve seen, with preload the application is aware of the resource loading taking place, and can be notified once the resource was fully loaded. That’s not something HTTP/2 Push was designed to do. Furthermore, HTTP/2 Push cannot be used for third-party resources, while preload can be used for them just as efficiently as it would be used on first-party resources.

Also, HTTP/2 Push cannot take the browser’s cache and non-global cookie state into account. While the cache state might be resolved with the new cache digest specification25, for non-global cookies there’s nothing that can be done, so Push cannot be used for resources that rely on such cookies. For such resources, preload is your friend.

Another point in preload’s favor is that it can perform content negotiation, while HTTP/2 Push cannot. That means that if you want to use Client-Hints26 to figure out the right image to send to the browser, or Accept: headers in order to figure out the best format, HTTP/2 Push cannot help you.

So… Link

I hope you’re now convinced that preload opens up a new set of loading capabilities that weren’t feasible before, and you’re excited about using it.

What I ask of you is to go pick up Chrome Canary, play around with preload, break it into pieces and come whining back to me27. It’s a new feature, and like any new feature, it may contain bugs. Please help me find them and fix them as early as possible.

(og)

Footnotes Link

  1. 1 https://w3c.github.io/preload/
  2. 2 https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/
  3. 3 https://www.smashingmagazine.com/2015/11/why-performance-matters-part-2-perception-management/
  4. 4 https://www.smashingmagazine.com/2015/12/performance-matters-part-3-tolerance-management/
  5. 5 https://www.smashingmagazine.com/2016/02/getting-ready-for-http2/
  6. 6 https://www.smashingmagazine.com/2016/02/everything-about-google-accelerated-mobile-pages/
  7. 7 https://www.smashingmagazine.com/2015/12/reimagining-single-page-applications-progressive-enhancement/
  8. 8 https://www.smashingmagazine.com/2014/09/improving-smashing-magazine-performance-case-study/
  9. 9 https://groups.google.com/a/chromium.org/d/msg/blink-dev/_nu6HlbNQfo/XzaLNb1bBgAJ
  10. 10 http://caniuse.com/#feat=link-rel-prefetch
  11. 11 https://web.archive.org/web/20150907034803/https://www.chromium.org/spdy/link-headers-and-server-hint/link-rel-subresource
  12. 12 http://www.html5rocks.com/en/tutorials/security/content-security-policy/
  13. 13 http://calendar.perfplanet.com/2013/big-bad-preloader/
  14. 14 https://fetch.spec.whatwg.org/#concept-request-destination
  15. 15 https://tabatkins.github.io/specs/css-font-display/
  16. 16 https://github.com/w3c/preload/issues/32
  17. 17 https://drafts.csswg.org/css-fonts/#font-fetching-requirements
  18. 18 https://twitter.com/scottjehl
  19. 19 https://github.com/filamentgroup/loadCSS/issues/59
  20. 20 http://filamentgroup.github.io/loadCSS/test/preload.html
  21. 21 http://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/
  22. 22 https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
  23. 23 https://tools.ietf.org/html/rfc5988
  24. 24 https://www.akamai.com/us/en/resources/front-end-optimization-feo.jsp
  25. 25 https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-00
  26. 26 https://www.smashingmagazine.com/2016/01/leaner-responsive-images-client-hints/
  27. 27 https://twitter.com/yoavweiss
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook

Advertisement

Yoav Weiss does not get discouraged easily and is not afraid of code. He is a Web performance and browser internals specialist, especially interested in the intersection between Responsive Web Design and Web performance. He has implemented the various responsive images features in Blink and WebKit as part of the Responsive Images Community Group, and is currently working at Akamai, focused on making the Web platform faster. You can follow his rants on Twitter or have a peek at his latest prototypes on Github. When he's not writing code, he's probably slapping his bass, mowing the lawn in the French countryside or playing board games with the kids.

  1. 1

    Fascinating. Can you explain how you ended up with both a type= and as= attributes?

    2
    • 2

      Type attribute is defined [1] as an advisory hint that communicates the MIME type of the defined resource. As such, just as Yoav illustrated, you can use it to conditionally fetch a certain type of resource.. if the browser supports it.

      However, the above says nothing about who will “consume” said resource. For example, it is possible to fetch an image via the img tag, XHR, iframe, etc. Each of these destinations has different characteristics, in terms of priority of the fetch, enforced CSP policies, and so on. Hence the need for `as`, which maps to Fetch destination [2].

      [1] https://html.spec.whatwg.org/#attr-link-type
      [2] https://fetch.spec.whatwg.org/#concept-request-destination

      3
  2. 3

    Great article, Yoav. Link preload is a fantastic performance optimization solution. The use cases you laid out are extremely helpful. Thanks for all your work to make this happen!

    4
  3. 5

    Vegard Strønen

    February 27, 2016 1:13 am

    In my opinion, this is spooky.

    What if a third party resource failes? Not by lack of browser support, but by connection errors for example. Same with font display mechanism. Should you as a developer, designer or any other web professional deside if the user “is allowed” to view this in a fallback font? What if our font don’t load in time? Should a user on slow cell connection then not be allowed to browse your site?

    I agree that script-wise it _might_ be useful. Let’s say if a important button is rendered way before the JavaScript is available to handle the click event. But what will happen, in the real world, is that people will put their entire minified JS library in there. (Because it’s SO important, I promise!)

    And about responsive loading. Are you crazy? Is the interactive map on a desktop SO important that you have to preload it and possibly blocking the rest of the content?! And what about using a HTML5 standard – the picture element?

    I see the power of preload, but with great power comes great responsibility. And in my opinion this looks like even another feature for people to make ineffective, poor accessible, unstable websites, and just need a feature to speed up their site.

    0
    • 6

      In my opinion, this is spooky.

      In what way?

      What if a third party resource failes? Not by lack of browser support, but by connection errors for example. Same with font display mechanism. Should you as a developer, designer or any other web professional deside if the user “is allowed” to view this in a fallback font? What if our font don’t load in time? Should a user on slow cell connection then not be allowed to browse your site?

      I’m not sure what you refer to there. If you mean that “font-display: swap” is a recommended pattern, then I agree. Still, even if you’re using such patterns, preload enable the swap to happen sooner, and is more likely to get the final font in place before the user started reading.

      And about responsive loading. Are you crazy? Is the interactive map on a desktop SO important that you have to preload it and possibly blocking the rest of the content?! And what about using a HTML5 standard – the picture element?

      In some cases, yes: the interactive map is important as it’s what the users see and interact with first. That content doesn’t “block” the rest of the content as it will get downloaded according to its relevant priority, like any other content discovered by the browser. As to using the picture element, it currently doesn’t allow an empty source set. This of course can be worked around using a “spacer” DATA-URI, in which case, yes, you wouldn’t need the preload the small viewport resource.

      I see the power of preload, but with great power comes great responsibility.

      I think we agree here: like any feature, preload should be used responsibly and thoughtfully.

      2
      • 7

        Vegard Strønen

        February 27, 2016 1:13 pm

        Thanks for replying, Yoav! Great article, even if we disagree on some of the examples :)

        1
  4. 8

    I don’t mean to be a party pooper. But…

    I think as people get more “advanced” (aka technology advances), the more they overcomplicate things for no reason. Nowadays people are talking about gigabit download speeds and unless you live in a farm in the middle of Kentucky, changes are you have fiber (and I don’t mean in your cereal). My internet speed at home is not even anywhere close to that speed (30Mbps). However, I do not remember when was the last time I sat in front of a page for seconds (that’s SECONDS!!!) waiting impatiently for a page to present itself. I do remember back in the days when Flash was hot, I hated websites with pre-loaders (regardless how pretty they were) where I had to stare at a thermometer showing me percentages. Some were insanely resource intensive and sometimes took over a minute to download. And that was on my 56k modem…or was it 128kbps? I don’t even remember what I had back then, but I do remember I still had to dial in!

    Today, with a mere 30Mbps (and that counts as “slow” nowadays), pages are nearly instantly loading. Regardless. Youtube, smashingmag, blogs, online newspapers, dev portals, online stores, etc, you name it. Still, people are making it even more obsessive. Even THAT instant speed is not good enough.

    DUDE! C’mon. I do value all the new discoveries and possibilities, but don’t feel you need to overdo it. It’s like those obsessive people whose “passion” is to see how much more they can overclock a processor. They just r-e-a-l-l-y need to push the memory timing to the limit where programs might start freezing and/or crashing, just to get that 4.59MHz out of that single core. Because let’s face it, the standard, out of the box 4.5MHz is just unacceptable. This could potentially cut down my rendering time by 1.25 seconds! Imagine that!

    That’s how it feels with all these obsessive new techniques and tricks. Just to get that page loaded by an extra 6 milliseconds faster. However, I’m sure that today’s impatient kids and small/large business owners will do appreciate and value it once I show them the pingdom results – despite the fact they might not even have a clue what are they looking at.

    I remember back in the days I used to love the web. Development was fun, entertaining, and provided many levels of enjoyment. To some extent it still is today. But it’s getting so obsessive that maybe it’s not me the one who needs counseling.

    0
    • 9

      You do realise there are other continents out there? Just because your country has (mostly) decent speeds are you saying we shouldn’t bother about everywhere else where 30mbs is treated as pretty fast high speed and the average is around 3mbs (my part of the world).

      5
    • 10

      You might want to look into the difference between bandwidth and latency, in addition to how the HTTP 1.x protocol works. Furthermore, keep in mind that the number of mobile internet users passed the number of desktop internet users a few years back.

      4
    • 11

      Peter Bengtsson

      March 16, 2016 11:31 am

      I found that interesting. Wrong, but interesting. So I blogged about it separately.

      http://www.peterbe.com/plog/web-performance-optimizations-dark-side

      1
    • 12

      Here’s why people keep fighting for those last few ms: Google bases search rank partly on page responsiveness. You get what you measure!

      0
  5. 13

    First I want to thank you for such a great article on preload. Everything makes sense to me, but I am still stuck on “crossorigin”. On w3c the example with two fonts; only the last font is listed crossorigin, do we label each one or just the last one? Also this article just to use it for images and fonts, what about javascript being loaded say from cdnjs.com for example would we need to add crossorigin to that as well?

    Many thanks and a wonderful article.

    2
    • 14

      Thanks for your comment and for pointing out the disagreement with the spec’s examples. I went looking at these examples, dug up the relevant github issue, and to be honest I’m no longer 100% sure what the right behavior should be.

      I commented on the issue, and hopefully, once we all agree on the right behavior there, I’ll align either the spec examples or the Chrome behavior accordingly.

      0
      • 15

        Thank you, please post here an update and I will keep checking this page for the answer.

        0
  6. 16

    It’s all about speed of loading.. You could have 100mb fiber, and still have scripts that block render the page, and see that flickering, when a page could be optimised in such a way, so you feel that is 1kb instead of 100kb… So don’t be the party pooper, clearly you are not a hardcore speed frontend fanatic :)

    1
  7. 17

    Nicolas Hoizey

    March 1, 2016 7:24 am

    Great article, and great new way to improve web performance, thanks!

    When you tell us about the media attribute, you say preloading will only happen for positive media queries. I thought it is not currently the case for stylesheets, which are all loaded. Am I wrong?

    0
    • 18

      That is true for stylesheets, where the resource has to be downloaded (even if in some engines, an non-matching `media` attribute results in it being downloaded in lower priority).

      For preload though, the browser shouldn’t download the resource when `media` is not a match.

      0
  8. 19

    Can we use this to preload images for image carousel?

    2
  9. 21

    Hi, thanks for great article, i think it’s a good evolution this option.
    If i choose to preload javascript on homepage, my page will be larger for engine , so, maybe get a rank penality ? (is it possible ?)
    Imagine 5 fonts and 3 large javascripts ?

    Otherwise i think javascript promises are great to use and not enough explained.I know it’s not exactly the same but it’s a way of preloading element.

    Have you article about this ?

    1
    • 22

      “Otherwise i think javascript promises are great to use and not enough explained.I know it’s not exactly the same but it’s a way of preloading element.”

      Promises really have absolutely nothing to do with preloading. Using a Promise will not load anything earlier or faster. It’s just a language construct.

      0
      • 23

        Yes it’s true , but in my case it looks the same. I was thinking about preloading elements on HomePage index.php (and get a different loading page time : my first question) or use a dialog box (with a message to wait) on the next page and use Javascript promises to preload content , to avoid users to see loading progress… Big question for me that’s why this article is interesting to me.

        0
  10. 24

    طراحی سایت

    March 2, 2016 1:32 pm

    very good post thanks

    0
  11. 25

    Rodrigo Rosenfeld Rosas

    March 3, 2016 2:44 pm

    It would be handful if we could tell the browser when the application is finished loading from a user point of view so that the browser loading indicator would go away, which is specially handful when the application does not rely on onload. So, if the analytics script is still loading it shouldn’t matter to the end user…

    0
    • 26

      No, we need that indication of when things are still loading, so we know when it’s safe to scroll. If anything there should be a way to make it keep going until all the content is done.

      The problem is everyone measures the time until the loading indicator goes away as their only metric for site responsiveness, so everyone focuses on stopping it as soon as possible — just loading the bare minimum layout and then async loading the actual content. This is especially annoying on mobile, where I might think the page is done, start scrolling down, and then have it jerk to the top again when a block of text asynchronously loads.

      0
  12. 27

    Rodrigo Rosenfeld Rosas

    March 3, 2016 3:14 pm

    I’d like to suggest an improvement to the filmstrip feature since it’s related to performance even though it does not relate to this article.

    It’s sad that the filmstrip requires you to reload the page because this way you can’t test the case where cached resources are not requested (even if it responds with 304). Could you suggest the dev tools team to not enforce page reloading to get the filmstrip to work? Also it would be awesome if we could tell the filmstrip feature we are not interested in evaluating the unload timing…

    0
  13. 28

    Hi Yoav Weiss great article I got a question for you and Ilya Grigorik. Most of the internet browsers support prefetch and dns-prefetch, but right now it seems only Google Chrome version 50 and above supports preload. I was thinking is it possible for you to create a javascript script that first checks the browser if it supports preload or not? If it does then the javascript displays the preload list. If not then it displays the prefetch/dns-prefetch list.

    What do you think…?

    1
    • 29

      Thanks Sarah! :)

      It is certainly possible to create such a polyfill (using the feature detection capabilities).

      I’m not sure regarding it being useful for all use-cases, since prefetch has lower priority, but it might be useful for some of them. Would be interesting to test that approach.

      1
      • 30

        Alexander Farkas

        March 20, 2016 1:08 pm

        A polyfill could look something like this:
        https://gist.github.com/aFarkas/34dde117000ec7075053

        Although the polyfill including the preload links have to be added before any (other) external stylesheets and scripts to be able to actually preload something. Otherwise the “preload” starts after downloading the CSS (which isn’t desired in most cases).

        0
  14. 31

    I would like to point out a mistake on the w3c page under fonts example they do not say you need to add type, but you are saying here to add type, so I am guessing the w3c and github are wrong and need to be updated to mention about adding type to fonts.

    0
  15. 32

    Jitendra Vyas

    March 12, 2016 8:15 am

    How we can know in the website’s waterfall rel="preload" is working or not.

    0
  16. 33

    Jitendra, it took me a while to see this.

    So use Chrome Canary (it’s not hit the main Chrome release at time of writing). Open developer tools and load your page. If it works you should see the initiator as (index:33) if you have this preload on line 33, and the asset is loaded then.

    However you might notice the same asset loading again later. For example I set my fonts to preload and noticed it was loading them once for preload and again from my CSS in the usual place. This confused me and made me think this was a bug but this is due to a combination of “Disable cache” being ticked in Developer tools and/or using F5 to force the reload – both of which will cause the double download. So the only real way to see this properly is to clear your cache, browse to a different page, open developer tools and make sure “Disable Cache” is not ticked , and then browse to your page.

    1
  17. 34

    SAID ASSEMLAL

    March 16, 2016 3:43 pm

    Awesome as always Yoav! Thanks a lot for sharing this with us

    0
  18. 35

    Great article, thanks!

    -1
  19. 36

    Really great article. We’re experimenting with the SW, having the origin providing it with a JSON that tells is stuff to do, such as prefetch, redirect, cache, etc, and we’re often ending up in discussing the relation to preload and also the client hits.

    An article about the relation preload, client hints, H2 push and Origin driven SW “prefetching” would be helpful I believe!

    0
    • 37

      Interesting article, thanks!
      I tried this approach for preloading a “JSON” document. The document is preloaded correctly, but it doesn´t prevent Chrome from loading the same document again when required through XMLHttpRequest some milliseconds later. Using different values for “as” and “type” did not change anything. Has anybody successfully preloaded a JSON document?

      1
  20. 38

    David ALimian

    April 21, 2016 9:00 pm

    Thanks alot Yoav for this wonderfull documentation and being the first browser to implement support for preload. I used it and seeing significant gains.

    one small feedback, the preloads do show in network panel but only under all tab, i think maybe they should show in js tab if as=”script”, css tab if as=”style” etc.

    1

↑ Back to top