How to speed up a website and what helps most

Somebody ran the site through a speed test, it returned a number in the forties, and now that number is a problem to be solved. The developer is asked to raise it, work is done, the number rises, and visitors notice nothing.

That happens because the score is a summary of measurements, and raising a summary is not the same as making a page feel faster. Where the slowness comes from in the first place is a separate question, answered in our article on why your website loads slowly.

Why a score out of a hundred guarantees nothing

The score is a weighted average of several timings, calculated on a simulated device and a simulated connection.

Two things follow from that. The first is that the same page tested twice returns different scores, sometimes by ten points or more, because the simulation is affected by whatever else the testing machine is doing. Chasing a three-point difference is chasing noise.

The second is that the weighting is somebody’s judgment about what matters. A page can improve on the timing a visitor actually feels while the score drops, because a different component of the average moved the other way.

The score is useful for one thing, which is finding what to look at. Its list of specific problems is worth reading. The number at the top is worth ignoring.

The metrics that describe what a person feels

How long until the first picture

The measurement that corresponds most closely to the feeling of waiting is the time until the largest visible element on the screen has appeared.

On most pages that element is the main image or the headline block on the first screen. Until it is there, the visitor is looking at something incomplete, and that is the interval they experience as loading.

This is the metric worth optimizing first because it is the one that maps onto behavior. Improving it means the page looks ready sooner, whether or not the rest has finished.

Why the page jumps under your finger

The second measurement counts how much the content moves after it first appears.

The visitor starts reading, an image finishes loading above the text and pushes it down, or an advertisement block appears and the paragraph jumps. On a phone this causes the specific irritation of tapping the wrong thing because the button moved while the finger was descending.

The causes are almost always the same: images with no declared size, fonts that load late, and advertising blocks and widgets that appear after the main content. Declaring sizes is one of the cheapest fixes and one of the most noticeable.

The delay before the page responds to a touch

The third measurement is how long the page takes to react to an interaction.

A visitor taps a menu and nothing happens for half a second, because the browser is busy executing scripts and cannot respond. The page looks finished and behaves as though it is frozen, which is worse than looking unfinished.

This one is caused by the amount of code running rather than by the amount of content, which is why a visually simple page loaded with third-party scripts can feel slower than a heavy one without them.

Server response time, measured separately

Before any of the above, there is the time between the request and the first byte coming back.

This interval is entirely the server’s, and nothing done in the browser affects it. If it is long, everything downstream starts late, and no amount of image optimization compensates. When the cause is the server itself, setting it up and keeping it running is part of server administration.

The distinction that matters here is between a page built fresh for every visitor and one served from cache. A cached page is returned in a fraction of the time, and for most company sites the majority of pages can be cached safely. Which parts of the plan constrain this is explained in our article on how to choose hosting.

What genuinely produces a result

The list is shorter than the list of available optimizations, and the order matters.

• Caching finished pages. The single largest gain on most sites.
• Images in modern formats, sized correctly. Usually the heaviest thing on a page.
• Loading below-the-fold images later. Nothing loads that is not seen.
• Removing unused code. Styles and scripts nobody needs.
• Removing third-party scripts. Each one is somebody else’s server.
• Declaring element sizes. Stops the jumping caused by images and blocks with no size.

The first two together account for most of the improvement on a typical site, and both are ordinary work rather than deep engineering.

Images deserve the emphasis. On the majority of sites that test badly, the largest single problem is a photograph uploaded at its original resolution and displayed at a fraction of that size, so the visitor downloads several times more data than they see. Fixing that across a catalog is mechanical work with a large and immediate effect.

What helps little or not at all

Several popular optimizations are worth knowing about mainly so that time is not spent on them.

Combining all styles and scripts into one file was important years ago and matters much less now, because modern connections handle multiple parallel requests well. On some sites it makes things worse by forcing everything to load before anything renders.

Removing whitespace from code saves a small fraction of a small file. It is free to do and it is not a project.

Inlining the styles needed for the first screen produces a measurable gain on some sites and creates a maintenance problem on all of them, because those inlined styles then have to be regenerated whenever the design changes. On a site that is actively edited it is usually not worth the ongoing cost.

In short, leave these alone.

• Combining every file into one. Mattered years ago, rarely now.
• Stripping whitespace from code. Free, and worth almost nothing.
• Inlining first-screen styles. A gain and a permanent maintenance cost.
• Preloading everything. Delays the resources that mattered.
• Switching off analytics for points. Trading data for a number.
• Installing a one-click speed plugin. Raises the test number and breaks what was working.

Preloading everything the page might need is an optimization that easily backfires. Preloading a few genuinely critical resources helps; preloading twenty makes the browser fetch them all at once and delays the ones that mattered.

The most dangerous route is a plugin that promises speed at the press of a button. Such plugins defer scripts and styles aggressively, so the test number rises while part of the site stops working, and nobody notices right away.

Where to start checking

The order below finds the largest problems fastest.

• Measure the server response first. If it is slow, start there.
• Look at the total page weight. And what the heaviest files are.
• Count the third-party scripts. Analytics, chat, pixels, fonts.
• Test on a phone on mobile data. Not on office Wi-Fi.
• Compare two or three pages. The home page is not representative.

The fourth point changes conclusions more than any other. A site that loads in one second on a desktop connection can take six on a phone on a weak signal, and a good share of the audience is in exactly that condition.

The fifth matters because the home page is usually the most optimized page on any site. The pages that receive search traffic are the ones worth measuring, and they are frequently much worse.

Lab data vs. field data

There are two kinds of speed measurement and they answer different questions.

Lab data is a test run on demand under controlled conditions. It is repeatable, it is available immediately, and it tells you what the page does on that particular simulated device.

Field data is collected from real Chrome users over recent weeks. It reflects real devices, real connections and real locations, and it is the version that corresponds to what people experience. It exists only for sites with enough Chrome traffic, and if the report shows none, the lab test on the mobile profile is what you have.

When the two disagree, the field data is right. A page that scores well in a test and poorly in field data is fast on a fast machine and slow on the phones your customers actually hold.

The practical consequence is that after making changes, the test result updates immediately and the field data takes weeks. Judging a fix by the field data means waiting, and judging it by the test alone means possibly having improved nothing.

Targets worth aiming at

The sensible targets apply to the individual timings rather than to a score, and their thresholds are published.

The largest element on the screen should appear within about two and a half seconds, layout shift after it appears should stay within 0.1, and the response to a tap should land within 200 milliseconds.

A site that meets those three on a phone on an ordinary connection is a good site. A score in the nineties on a desktop test while failing them on a phone is a good number attached to a slow site.

Mobile and desktop always diverge

The gap between the two is normal and it is large, and it surprises owners every time.

The phone test simulates a mid-range device on a mobile connection, and the desktop test simulates a fast machine on a fast connection. The same page routinely scores in the nineties on one and the fifties on the other, and neither number is wrong.

Which one to care about follows from your own analytics. For most businesses the majority of visitors are on phones, and the mobile figure is therefore the one that describes the business.

Third-party scripts and what they cost

Every script from somebody else’s server is a dependency, and most sites have accumulated several.

Analytics, a chat widget, an advertising pixel, an external font, a review widget, a map. Each one is a request to a server you do not control, and if that server is slow today, your page is slow today.

Before deciding which to keep, look at what each type typically costs the page.

• Analytics. Small, and usually worth keeping.
• An advertising pixel. Small individually, and they accumulate.
• External fonts. Moderate, and easily hosted yourself instead.
• A map. Heavy, and only needed on the contact page.
• A chat widget. Often the heaviest of the third-party scripts.
• A review widget. Heavy, and often loading on every page.

Do this audit once a year. List every external script, establish who added it and why, and remove the ones whose reason no longer exists. On a site that has been running for years, half the list is usually orphaned.

The chat widget deserves particular attention, because it is heavy and it often loads on every page, including ones where nobody would use it.

What can be fixed quickly

Some of this is a project and some is an afternoon, and the afternoon items are worth doing first.

Enabling page caching, compressing and resizing the images already uploaded, declaring sizes on images, lazy-loading below-the-fold content, removing dead third-party scripts and updating to a current PHP version are all short tasks with visible effects. That kind of work is billed at $25/hr and usually takes a day or two on a typical site.

What is not quick is a heavy template, a database that has accumulated years of records, or a site running thirty extensions where a third are doing the same job twice. Those are structural, and the reasoning behind them is traced in our article on why your website loads slowly, while the process of establishing which category your site is in is described in our article on what a website audit finds.

Keeping the result once it is achieved is its own task, because speed degrades as content and extensions accumulate. Watching for that is part of project support and development, and what such an arrangement covers month to month is listed in our article on what website support includes. Without it a site optimized this spring is back where it started by next year.

When chasing a perfect score is not worth it

There is a point where further work costs more than it returns.

Going from a poor score to a decent one is cheap and the visitor feels it. Going from decent to perfect usually means removing functionality the business chose deliberately, such as analytics, chat or a map, and those removals are business decisions rather than technical ones.

A shop that removes its chat widget to gain eight points and loses the conversations that widget produced has optimized the wrong number.

The test to apply is whether the change is felt by a visitor on a phone. If it is, do it. If it only moves the score, it is decoration.

Conclusions

Speed work should target the individual metrics rather than the overall score. The three that matter are how quickly the main element appears, whether the page stays still after that, and how quickly it responds to a tap.

Optimizing images, enabling caching and removing unneeded third-party scripts account for most of the available gain on a typical site, and all three are routine work. Most of the rest is either marginal or a maintenance burden disguised as an optimization.

If your site tests badly and you are not sure which category the problem falls into, send us the address. We will measure the server response separately from the page itself, tell you whether this is a day of work or a structural problem, and give you the two or three changes that would be felt by a visitor rather than only by the test.