LFW

Blog · What the free audit finds

Why the Page Is Blank for a Second

A white page for a second is not slowness in the usual sense. The server answered quickly. The browser has the page and is refusing to draw it until a few files arrive: stylesheets, a font, a script in the wrong place.

What the browser waits for, how to read the list the free audit gives you, and the three changes that end the wait on most organization sites.

The browser is holding the page back

A browser will not draw a page until it has the stylesheets named in the page head. If it drew first and styled later, the visitor would see raw text jump into shape, which is worse. So it waits. Every stylesheet the head asks for is a file the visitor's phone has to fetch before anything at all appears.

Scripts in the head do the same thing unless they are marked to defer. The browser stops reading the page when it reaches one, fetches it, runs it, and only then continues. A tag manager, a chat widget, or an analytics snippet placed in the head is a pause before the first word.

Fonts are the third cause and the sneakiest. A page can be drawn and still show no text, because the text is set in a web font that has not arrived, and the default behavior in most browsers is to hide the text for up to three seconds rather than show it in a stand-in face.

What the free audit shows you

The free audit runs the same browser measurement Google uses. Two numbers matter for this problem. First Contentful Paint is the moment the first text or image appears. Largest Contentful Paint is the moment the main thing on the page appears. If the first is over about 1.8 seconds, the visitor sat on a white page.

Under the numbers is a list of the files the browser waited for, with the time each cost. On most organization sites it is a short list: the theme stylesheet, two or three plugin stylesheets, a font from a font service, and one script that should have been at the bottom of the page.

Fix one: let the text show in a stand-in face

A font file can declare how the browser should behave while it loads. The setting is called font-display, and the value swap means show the text now in a fallback face and switch when the real font arrives. Visitors see words within the first paint instead of an empty column.

Show the code Hide the code CSS, 5 lines
@font-face {
  font-family: "Source Serif 4";
  src: url("/fonts/source-serif-4.woff2") format("woff2");
  font-display: swap;
}

If the font comes from a font service, the same setting is usually a parameter on the link the service gave you. If it comes from a theme, it is one line in the theme's font declaration. Self-hosting the font file removes a whole separate connection to another server, which on a phone is often the slowest part.

Fix two: scripts at the end, or deferred

A script that does not change how the page looks belongs at the end of the page, or in the head with the defer attribute, which tells the browser to fetch it in the background and run it after the page is drawn. Analytics, chat, tag managers, social embeds and video players all qualify. Almost nothing on an organization site needs to run before the first paint.

On WordPress most of these scripts arrive through plugins, and most plugins offer no setting for where their script goes. A caching or performance plugin can defer them in bulk. Test the site after switching that on, since a script that another script depends on will complain if it runs out of order.

Fix three: fewer stylesheets on pages that do not use them

A contact form plugin loads its stylesheet on every page, not only the contact page. So does the slider plugin, the events calendar, the gallery. A site with twelve plugins can ask for twelve stylesheets before drawing a page that uses none of them. Each is small. Together they are the wait.

The clean fix is to load each plugin's assets only on the pages that use them. Some plugins have that setting. For the rest, a performance plugin can do it by page, or the theme can enqueue them conditionally, which is a few lines for whoever maintains the site. The blunt fix, removing plugins nobody remembers installing, is often worth doing first.

What not to do

Do not chase the score. A page that paints in under a second on a phone is done, even if the measurement tool still lists suggestions. And do not inline everything into the page to avoid requests: a stylesheet that grows to tens of kilobytes inside every page is re-sent on every visit, when a linked file would have been cached after the first. We made exactly that mistake on LFW.com and corrected it this week.

Keep reading

September 20, 2026 4 minutes

What a Stranger Learns About Your Site in One Minute

Everything in this article is public. It is what a curious visitor, a vendor sizing you up, a journalist, or a scanner run by someone less friendly can read about your website in about a minute. The free audit is that minute, run on your behalf. This is what it looks at, in the order a stranger would.

September 20, 2026 3 minutes

Login Names Are Half a Login

Ask a WordPress site for its list of users and, by default, it answers. Every author's login name, in a machine-readable list, at a fixed address. Attackers do not have to guess who the accounts are. They only have to guess the passwords. Where the list comes from, how the free audit reports it, and the four changes that close it without locking anyone out.

All articles

    Powered by LFW Search
    Prefer to write?

    Tell us what needs to work better.

    Slow, fragile, hard to edit, missing a workflow. Say it plainly, and you'll get a straight answer, not a ticket number.