What Loads Before Anything Is Visible

The gap nobody looks at

Between a visitor requesting your page and seeing anything at all, several things happen in order, and the visitor sees a blank screen throughout.

Most performance advice concerns total page weight, which matters for when the page finishes.

This is a different quantity: when the page starts. A site can be light overall and still show nothing for six seconds, and a heavy site can show useful text almost immediately.

The blank period is what people mean when they say a site feels slow, whatever the total says.

Why the browser waits

Not because it is being careful. Because of two specific instructions in your page that tell it to.

A stylesheet has to arrive before anything can be drawn, since drawing text and then restyling it would produce a flash of unformatted content that is worse than waiting.

A script in the head, by default, stops the browser processing the rest of the document until it has been fetched and run, because that script might change the document.

Both are reasonable defaults and both mean a single slow file can hold the entire page in a blank state, regardless of how small everything else is.

The usual culprits

• A large theme stylesheet covering every page type.
• Scripts in the head that are not needed until later.
• A tag manager loaded before anything else.
• Web fonts, which can hold text invisible while they load.
• Third-party files from a server you do not control.
• Chains, where one file requests another before finishing.

The fifth is the most dangerous, because a slow response from somebody else's server holds your page blank and there is nothing you can do about it in the moment.

Seeing it for yourself

Your browser's developer tools will show the whole sequence, and reading it once explains more than any amount of general advice.

Open the network view, empty the cache, and reload. You get a waterfall: every file, when it was requested, how long it took, and what waited on what.

What you are looking for is the tall stack at the beginning, before any content appears, and specifically anything wide near the top of it.

Performance tools will also list resources that block rendering by name, which is the shortcut if you do not want to read a waterfall.

Defer what is not needed yet

The single highest-value change and usually a small edit.

Most scripts on a business site do not need to run before the page is drawn: analytics, chat widgets, sliders, form validation, social buttons, cookie banners.

Marking a script as deferred lets the browser carry on building the page and run the script afterwards.

The distinction worth knowing is that one option runs the script as soon as it arrives, potentially interrupting, and the other waits until the document is parsed. For most business-site scripts the second is what you want, and it preserves the order they run in.

What genuinely must run early is a short list, usually consent handling and anything that changes the page's appearance immediately.

Keep the blocking stylesheet small

The stylesheet has to block, so the answer is to make what blocks smaller rather than to stop it blocking.

Many sites load one enormous stylesheet on every page, covering the shop, the blog, the booking system, and page types most visitors never see.

Splitting it so each page loads what it needs, or extracting the styles required for the visible top of the page and loading the rest afterwards, removes most of the delay.

On a template-driven site this is often a setting in a performance plugin rather than hand work, and it is worth checking before assuming a developer is needed.

Fonts hiding your text

A specific and very common cause of a page that has technically rendered while showing nothing readable.

By default some browsers hide text while a web font loads, on the reasoning that showing it twice in two typefaces looks worse.

On a slow connection that means a blank space where your headline should be, for as long as the font takes.

A one-line setting tells the browser to show the text immediately in a fallback and swap when the font arrives. The brief change in appearance is far less costly than an unreadable page, particularly for a visitor deciding whether to stay.

A worked example

A recruitment firm had a homepage weighing under a megabyte, which everybody agreed was fine, and which showed nothing for about seven seconds on a throttled connection.

The waterfall showed the reason immediately.

Four scripts in the head, none needed for the initial view: a tag manager, a chat widget, a slider library, and a social feed. Behind them, a web font holding all text invisible.

They deferred all four scripts and added the font display setting. Nothing was removed and nothing was compressed.

Text began appearing in about one and a half seconds.

The total page weight did not change at all, which is the point: the page had never been too heavy, it had been badly ordered.

Order is a different problem from weight

Worth separating clearly, because the two get treated as one and they need different fixes.

Weight is about how much you send, and it is fixed by compressing images, removing unused code, and dropping things nobody needs.

Order is about what you send first, and it is fixed by deferring, splitting, and prioritising.

A site can be excellent at one and poor at the other. The waterfall tells you which you have: a wide bar early is an ordering problem, and a page of consistently wide bars is a weight problem.

The counter-case

Deferring everything indiscriminately causes its own faults, and they are more visible than the problem being solved.

Anything that alters the appearance of the page must run before it is drawn, or the visitor sees one layout replaced by another, which looks broken and is worse than a short wait.

Consent and privacy scripts frequently need to run first by design, since their whole purpose is to gate what follows.

And a site relying on scripts to build its content at all cannot defer them without showing an empty page, which is a structural issue rather than a loading one.

Change one thing, reload, and look. This is an area where a confident bulk edit produces a fast site that flickers.

What to do

1. Open the network waterfall with an empty cache.
2. Find what blocks before anything appears.
3. Defer every script not needed for the first view.
4. Set fonts to display a fallback immediately.
5. Split or reduce the blocking stylesheet.
6. Reload after each change and check for flicker.

Steps three and four together account for most of the improvement available on a typical business site.

The number of files a page requests is covered in how many things a page loads.

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.