Get the text and main image in front of the visitor first, and let everything decorative arrive afterwards. Perceived speed depends on the order more than the total.

Total time against perceived time

Two pages both take four seconds to finish loading.

The first shows its heading and text after half a second and fills in images as they arrive. It feels quick.

The second shows a blank screen for three and a half seconds, then everything at once. It feels broken, and a proportion of visitors will have left before it appeared.

Same total time. Entirely different experience, and the only thing that differs is the order.

What blocks the start

The second is the classic problem. A tracking script or a widget placed in the head runs before the page can render, and if that company is slow today, your page is blank today.

The order that works

Roughly, and it holds for almost any page.

The text and layout first, so the page has structure and something readable.

The main image next, since that is what somebody looks at.

Then everything below the visible area, as they scroll.

Then the decorative and the analytical: animations, tracking, chat widgets, social embeds.

Nothing in that last group needs to run before somebody can read the page, and putting them first is the most common cause of a slow-feeling site.

A worked example

An accountancy firm whose homepage took about four and a half seconds in total and felt considerably worse.

The cause was a chat widget loaded in the head, before the stylesheet. Every visitor waited for a third-party server before anything was drawn.

When that provider was slow, which was several times a week, the blank period stretched past six seconds.

Moving the widget to load after the page content took the time-to-readable from around three seconds to under one. The total was almost unchanged.

Nobody had complained about speed. What they had noticed was people arriving and leaving, which is what a blank screen produces.

The chat widget still worked. It simply appeared a second later, which nobody noticed and nobody minded.

Deferring things safely

The mechanism, in plain terms.

Scripts can be marked so the browser continues drawing the page and runs them afterwards. Most analytics, tracking and widget code is designed to work this way and frequently is not installed that way.

What cannot be deferred safely: anything that changes what the page looks like above the visible area, because deferring it produces a visible jump.

Which is a reasonable argument for not having anything that rewrites the top of a page after it has already loaded.

Most platforms have a setting or a plugin that handles deferring, and testing after changing it is essential because the occasional script genuinely breaks.

The counter-case

Where load order should not be touched.

Anything affecting layout above the visible area, as above. A cookie banner is a common example; deferring it makes it appear late and push content down.

Consent and privacy tooling that must run before other scripts do, where deferring it defeats its purpose and may create a compliance problem.

And payment or security components on a checkout, where correctness matters more than a fraction of a second.

Everything else on an ordinary business site can wait until the page is readable.

The image at the top

A specific case worth its own attention.

The largest image above the fold is usually what determines when the page feels ready, and it competes for bandwidth with everything else.

What helps: sizing it properly, telling the browser to fetch it early, and not deferring it, since deferring the first thing somebody sees makes the page feel slower.

What hurts: loading it through a script, which means it cannot start downloading until the script has run.

A plain image in the page, correctly sized, is faster than any clever arrangement, and it is what most small business sites should be using.

The stylesheet problem

Harder to solve than scripts and worth understanding.

A browser will not draw anything until it has read the stylesheets, because drawing first and restyling afterwards would produce a visible flash of unstyled content.

Which means a large stylesheet, or several of them, delays the entire page by however long they take to arrive.

The proper fix is extracting the small amount of styling needed for the visible part and putting it directly in the page, then loading the rest afterwards. That is genuine work and it is what the fastest sites do.

The proportionate fix for a small business is simpler: reduce the number of stylesheets by removing the plugins that add them, which the plugin audit already covers.

A page loading one stylesheet rather than nine is most of the way there without any development.

Measuring the order

  1. Record the page loading on a phone, or use a tool that shows a filmstrip.
  2. Note when text first appears.
  3. Note when the main image appears.
  4. Note when the page stops moving.
  5. Compare those against the total load time.

The gap between step two and the total is where the opportunity sits. A page readable at one second and finished at four is fine; one blank until three is not, whatever the total figure says.

Why this is worth more than compression

A point of proportion.

Shaving a hundred kilobytes off a page is real and imperceptible. Moving a blocking script so text appears two seconds sooner is a change every visitor experiences.

The second is usually less work than the first and it is almost always the better place to begin.

Which is why load order deserves attention before file size on any page that is already reasonably light, and why a page that is heavy should have its images dealt with first and its order second.

Both are worth doing and doing them in the wrong order wastes effort, which is the most common mistake in this whole subject.

How to tell which situation you are in is covered in measuring speed without guessing.


Frequently asked questions

Why does order matter more than total time?

Two pages taking four seconds feel entirely different if one shows text at half a second and the other is blank until three and a half.

What blocks the start?

Stylesheets, scripts in the page head, fonts that hold text invisible, third-party requests, and large images competing for the connection.

What is the classic problem?

A tracking script or widget in the head. It runs before the page can render, so if that company is slow today, your page is blank today.

What order should things load in?

Text and layout, then the main image, then everything below the fold, then decorative and analytical things that nobody needs before reading.

What cannot be deferred?

Anything affecting layout above the fold, such as a cookie banner, and consent tooling that must run first. Everything else on an ordinary site can wait.

Why is this worth more than compression?

Shaving a hundred kilobytes is imperceptible. Moving a blocking script so text appears two seconds sooner is something every visitor experiences.

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.

Page blank for three seconds then everything at once?

That is load order rather than weight, and it is usually one script in the wrong place.

Start a Conversation