Tight Mode: Why browsers produce different performance results

This article is sponsored by DebugBear
Matt Zeunert, from DebugBear, casually mentioned Tight Mode while describing how browsers prioritize and fetch resources. I wanted to nod like I understood what he said, but I had to ask: what the heck is Tight mode?
What I received were two artifacts. One of them was the following video of Akamai Web Performance Expert Robin Marx speaking in France at We Love Speed a few weeks back:

Tight Mode prioritizes resources by removing anything marked as High or Medium priority. All other resources are constrained and left outside, watching in until the document body is firmly attached, signaling the blocking scripts being executed. Then, resources marked as Low priority can be allowed to enter the door during the second loading phase.
We’ll get to it. It’s important to note that…
Chrome and Safari Enforce Tight mode
Both Chrome and Safari have Tight Mode running. Chrome’s Tight Mode is shown in the last image. Compare Safari’s next with Chrome’s.

Look at this! Safari, like Chrome, discriminates against High-priority resource in its initial fetch. However, the loading behavior is wildly different between the two browsers. Safari seems to exclude the five PNG images with Medium Priority, while Chrome allows them. Safari, on the other hand, makes all Medium and Low-priority assets wait until all High Priority items have finished loading, despite using the same HTML. Safari’s behavior is the most logical, as you can clearly see in the last image where Chrome appears to exclude some High-priority items from Tight Mode. There’s some nonsense going on there, which we’ll discuss.
Firefox, where are you? It doesn’t use any additional tightening measures to evaluate the priority of resources on a webpage. This is the “classic waterfall” approach to fetching resources and loading them.

Chrome And Safari Trigger The Tight Mode Differently
Robin makes it very clear in his talk. Chrome and Safari both support Tight Mode, but trigger it in different circumstances. We can explain this as follows:

Chrome
Safari

Tight Mode triggered
While blocking JS is busy.
While blocking JS and CSS anywhere is busy.

Chrome prioritizes resources only when JavaScript is involved. Safari, on the other hand, looks at JavaScript and CSS, as well as any place they might be in the document, regardless of whether or not it is in the. This helps explain why Chrome excludes the images marked as High Priority in Figure 2 from Tight Mode implementation – it only cares for JavaScript in this case.
Chrome will not load a script with fetchpriority=”high”, even if it encounters the script in the document. Safari, on the other hand, honors fetchpriority wherever it appears in the document. This helps to explain why Chrome leaves the two scripts “on the table” in Figure 2, whereas Safari appears to load them when Tight Mode is enabled.
Safari’s process isn’t perfect. The following markup is given:

You might expect Safari to delay the two scripts of Low Priority in until the five images are downloaded. This is not the case. Safari loads these two scripts instead during its version Tight Mode.

Chrome and Safari Exceptions
I mentioned earlier that low-priority resources will be loaded during the second phase after Tight Mode is complete. But I also said that this behavior comes with a large caveat. Let’s talk about that.
According to Patrick’s post, Tight Mode is the initial phase of loading resources and the constraints that are placed on them until the body of the document is attached (basically, after all the blocking scripts have been executed in the head). But there is a second part that I forgot to include:
In tight mode, low priority resources are only loaded when there are less than 2 in-flight requests.

A-ha! There is a way to load low-priority resource in Tight mode. It’s when less than two “in flight” requests are detected.
What does “in flight” even mean?
This is what it means when less than two High or Medium priority items are requested. Robin shows this by comparing Chrome and Safari in the same conditions where there are two High-priority images and ten regular scripts:

Safari is the easiest way to get started.

It’s not difficult, is it? The 10 images are then downloaded after the two scripts of High Priority. Let’s now look at Chrome.

As expected, we have loaded the High-priority scripts first. Chrome decides that it will let in the first 5 images with Medium priority and then exclude the last 5 images with Low priority. What. The. Heck.
Chrome’s reasoning is noble: Chrome wants to load only the first five pictures because the Largest Contentful Paint is likely to be one of them. Chrome is betting that the web would be faster if it handled some of this logic automatically. It’s a noble reasoning, even if the results aren’t 100% accurate. It is confusing and makes it difficult to understand Tight Mode when Low- and Medium-priority items are treated as High-priority.
Chrome’s discriminatory process is made even murkier by the fact that it appears to accept only two resources of Medium priority. The rest of the resources are marked as Low priority.
Chrome prioritizes the first five images that are not critical if it sees only one or two items entering Tight Mode.
Safari is doing something similar but in a completely different context. Safari accepts Medium and Low Priority items in Tight Mode, regardless of where they are located within the document. As we saw, any asynchronous script or deferred one will be loaded immediately.
How to manipulate Tight Mode
This could be a great article to follow up, but I’ll direct you to Robin’s video as his first-person research deserves to be consumed directly. Here’s the gist.

These high-level features can influence priority. They include resource hints (i.e. preload and preconnect), Fetch Priority API and lazy-loading.
We can indicate fetchpriority=`”high”andfetchpriority=”low”` on items.
<link rel="preload" href="defer.js" as="script" fetchpriority="low"

Use fetchpriority="high". This will allow us to include items that are lower in the source in Tight Mode. Using fetchpriority="low, we can exclude items higher in the Source from Tight Mode.
For Chrome, this works on images, asynchronous/deferred scripts, and scripts located at the bottom of the .
Safari only allows images to be viewed.

Watch Robin's talk to get the full story. It starts around the 28:32 mark.
That's Tight…
It's crazy to me that so little information is available on Tight Mode. I would have expected something like this to well-documented, perhaps over at Chrome Developers, or somewhere similar. But all we have is an easy to read Google Doc, and a detailed presentation to give a clear picture of how the two major browsers prioritize and fetch resources. Please let me know if there is any additional information you've published or found. I'd be happy to include it in the discussion.