What is a performance-optimized order of assets in the HTML head?

Web Performance Optimization Discussions
1

I have a bunch of assets like:

  • Preloaded local javascript - <link rel="preload" as="script" href="my.js">
  • Local javascript - <script type="text/javascript" src="my.js" async defer>
  • DNS-Prefetch of CDN domain - <link rel="dns-prefetch" href="//my.cdn.com">
  • Preconnect of remote javascript - <link rel="preconnect" href="//consentscript.tld">
  • Remote javascript - <script type="text/javascript" src="https://remote.server/my.js" async defer>
  • Inline javascript - <script>myFunc...;</script>
  • Inline styles - <style>body{color:black;}</style>
  • Inline and remote fonts

What is the correct, performance-optimized order of their placement in the HTML head?

Empirically I see, the order influences the performance. But I can’t find anything substantial that would answer this question.

Some years ago, Stoyan Stefanov of phpied.com offered a test tool to test the performance of different orders of different assets (local and remote CSS, JS, images, and fonts) - but now I can no longer find this tool too.

1 Like
2

It is going to vary by browser a bit and very much by what the actual styles and scripts do, but for Chrome, generally:

If your scripts are already in the markup, don’t preload them unless you actually want to change the order or the priority. If the underlying script is async then it won’t be blocking the parser or render and preloading it will make it load sooner (if you actually need it sooner then the explicit priority boost can help).

Inlining fonts can be really painful as it eliminates the ability to cache them. Preloading the font and serving it from the same origin as the HTML will tend to work better and avoid the crossorigin issues of opening a new connection.

Blocking and inline javascript that is needed in the head of the document works well if it is before the external css (if there is any and the script doesn’t depend on the css). Otherwise the HTML parser will have to stop when it gets to the script tag until the stylesheet has loaded and been processed.

DNS prefetch and preconnect can be helpful if the browser isn’t trying to fetch those resources with away (they are either not discoverable in the HTML or they are delayed for priority reasons) but don’t use them unless that’s actually the case. They won’t help speed up a connection for something the browser tries to fetch right away anyway and if it is for a cacheable resource then you’ll be making extra connections that may not be needed.

4 Likes
3

In case you were talking about cuzillion, I think it was Steve Souders’ originally but he open sourced it and Patrick Hulce rehosted it here: Cuzillion

3 Likes