Scripts That Wait for Each Other

Parallel and sequential

A browser can download many things at once, so ten files of similar size arrive in roughly the time the slowest takes.

That is why page weight alone is a poor predictor of speed.

The problem is when one file has to arrive and run before the browser learns that it needs the next one.

Then the times add up rather than overlapping, and four small files in a chain can cost more than one large file on its own.

Where the chains come from

• A tag manager loading tools it lists.
• A tool that loads its own dependency.
• A font service returning a file that names files.
• A plugin requiring a library first.
• A script that injects another script.

The first is the most common on a small business site and the most invisible. A tag manager is one small file, and everything it loads is discovered only after it has run, so every tool inside it starts late by definition.

How to see it

Since this is visual rather than a number.

Open the network view in your browser's developer tools and reload the page.

Each request appears as a bar, and the bars show what happened simultaneously and what happened one after another.

A staircase, where each bar starts as the one above it finishes, is a chain.

A block of bars starting together is parallel loading and is fine.

You are looking for the longest staircase, which is the thing determining when the page becomes usable.

A worked example

A business had a page taking about six seconds despite being light.

The network view showed a staircase four deep: a tag manager loaded first, which loaded an analytics tool and a chat widget, and the chat widget loaded its own configuration file, which then loaded the interface.

Nothing in the chain was large and the total was over three seconds before the chat widget appeared, during which other work was competing for the connection.

Removing the chat widget, which nobody monitored, removed two links of the chain.

Moving the analytics tool to load directly rather than through the tag manager removed another.

The page came down to about three seconds without anything being made smaller.

Let scripts wait rather than block

The setting that stops a script holding up the page.

By default, a script encountered in the page can stop the browser from continuing to build the page until it has been fetched and run.

Marking scripts to load in the background, or to run after the page is parsed, lets everything else proceed.

Almost nothing on a small business site needs to block: analytics, chat, tracking, and most widgets can all run later without any loss.

Ask whoever maintains the site which scripts are blocking, since the answer is frequently several that need not be.

That single change frequently does more than removing anything.

Fewer sources, not just fewer files

Since each new domain has a fixed cost before any file arrives.

Connecting to a new server involves a lookup and a negotiation, which takes time regardless of how small the file is.

Six files from one place is considerably cheaper than six files from six places.

So consolidating where things come from helps even when the total weight is unchanged.

Self-hosting fonts and scripts where the licence allows removes those connections entirely.

Count the distinct domains your page contacts, which is usually a larger number than anybody expects.

Question the tag manager

Since it is frequently the top of the staircase.

A tag manager is genuinely useful where several people need to add and remove tracking without touching the site.

On a business where one person adds a tag every two years, it is an extra layer that delays everything inside it for no operational benefit.

Consider whether the tags it holds could simply be on the page directly, which removes a link from every chain at once.

That is a decision about how you work rather than a technical one, which is why it rarely gets asked.

Fix the order before the size

Because the returns are usually larger.

Compressing a script by a third saves a fraction of a second, and removing it from a chain can save a whole one.

So look at the staircase first and the file sizes second.

The exception is a genuinely large file, over a few hundred kilobytes, which is worth attention on its own.

For most small sites the weight is acceptable and the sequencing is not.

Tell the browser about the next domain early

A small technique for the connections you cannot remove.

Where a page will definitely need a file from another domain, the browser can be told at the top of the page to start the lookup and negotiation immediately, before it discovers the file.

That overlaps the connection cost with everything else happening rather than paying it at the moment the file is needed.

It is worth doing for two or three domains you genuinely depend on, such as a payment provider or a font host.

Applying it to a dozen domains works against itself, since the browser then opens connections it may not use, so keep it to the ones on the critical path.

The counter-case

Some chains are unavoidable.

A payment provider or a booking system will load what it needs in the order it needs, and that is not yours to rearrange.

Restructuring script loading also carries a real risk of breaking something, particularly where one script depends on another having run.

And on a simple site with three scripts there is no staircase to find.

Open the network view, look for the longest staircase, mark what can load later, and remove whatever nobody owns.

What to do

1. Open the network view and reload.
2. Look for the staircase.
3. Note what each step waits on.
4. Remove anything unowned.
5. Mark the rest to load later.
6. Count the distinct domains.
7. Question the tag manager.

Step two is what makes this actionable, since a chain is obvious as a picture and invisible in any summary figure.

What should arrive first is covered in what loads first and why it matters.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.