Speed matters more for visitors than for ranking

Why it matters, in order

First, because visitors leave. The measured relationship between load time and abandonment is steep on phones, and somebody who leaves never sees your offer.

Second, because crawlers fetch slow sites less, so new pages take longer to be found.

Third, because it is a ranking signal. Real, and the smallest of the three reasons, which is why chasing a score for its own sake is the wrong way round.

Visitors leaving is the first reason and the largest. Ranking is the third, and chasing a score for its own sake is the wrong way round.

The three usual causes

Images that were never resized. A photograph several thousand pixels wide, displayed small, downloaded in full by every visitor.

Third party scripts. A chat widget, an analytics tag, a review badge, a social feed. Each is a separate connection to somebody else's server before your page settles.

Web fonts loaded from elsewhere, often several weights of several families, each one a file the visitor waits for before text appears.

Images, third-party scripts and web fonts account for nearly all of it on a small business site, which makes the diagnosis short.

What to do first

Resize and compress every image to roughly what is displayed. On a typical small business site this alone is the largest single improvement available.

Then remove third party scripts nobody uses. The chat widget nobody answers, the feed from an account that stopped posting, the tag for a tool you cancelled.

Then reduce fonts. Two weights of one family is plenty for most sites, and serving them from your own domain removes another connection.

• Resize and compress every image
• Remove third-party scripts nobody uses
• Cut the number of font weights and families
• Serve fonts from your own domain
• Turn on compression and sensible caching
• Test a deep page on a phone, not the homepage on office broadband

Caching and delivery

Files that rarely change should be cached so returning visitors do not download them again. That is a hosting setting rather than a content decision.

Serving from a network with points close to your visitors reduces the distance every request travels, which matters more than people expect.

Compression on the page itself is standard and worth confirming, because an uncompressed page is several times larger than it needs to be.

Measuring honestly

Test on a phone, on a normal connection, not on your office network with a cached copy. That is the condition most of your visitors are in.

Field data from real visitors is more useful than a single lab test, because it reflects actual devices rather than a simulated one.

Compare the same page over time rather than chasing a number. A page that got faster is a success whatever the score says.

Field data from real visitors is more useful than a single lab test, because it reflects actual devices — see Core Web Vitals.

What not to do

Do not strip useful content to win a score. A fast page that answers nothing is worse than a slightly slower page that does.

Do not install a performance plugin on top of a slow site and call it fixed. The plugin is another script and the images are still oversized.

Do not optimize the homepage alone. Most visitors arrive on a deep page from search, and that is the page whose speed they actually experience.

Do not strip useful content to win a score. A fast page that answers nothing is worse than a slightly slower page that does.

How ours are served

Pages here are static files served from a network close to the visitor, compressed, with assets cached by content so a changed file always means a changed address.

Nothing is loaded from a third party by default, which removes the category of delay that is hardest to fix later.

Every page passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards, which includes confirming that images declare their dimensions.