Measure before you change anything
There are two kinds of speed data and they answer different questions. Lab data is a test run on demand from a data centre: repeatable, good for comparing a change you just made. Field data is what real visitors actually experienced on their own phones and connections, and it is what Google uses when speed affects your rankings.
A site can score well in a lab test and badly in the field, and that is the common case rather than an oddity: the lab test ran on a fast connection in a nearby data centre, and your customers are on a phone with two bars.
So start with field data if you have enough traffic for it, and treat a lab score as a tool for measuring your own fixes rather than as the verdict. Record the starting numbers before you touch anything. Without them you will not be able to tell whether a change helped.
Core Web Vitals, in plain language
Three measurements describe most of what a visitor experiences as slowness. They are worth understanding individually, because they have completely different causes and fixes.
Largest Contentful Paint is how long until the biggest thing on screen appears, usually a hero image or a headline. This is the one people mean by slow, and it is usually an image problem or a slow server response.
Interaction to Next Paint is how long the page takes to respond when someone taps something. When a page looks ready but a tap does nothing for a second, this is what is bad, and the cause is almost always too much JavaScript running.
Cumulative Layout Shift is how much the page jumps around as it loads. It is the reason someone taps the wrong button because an ad or a banner pushed the page down under their thumb. The causes are images without reserved dimensions, late-loading fonts, and anything injected above existing content.
Images: the usual culprit
In the large majority of slow sites I look at, images are the first and biggest cause, and the fix changes nothing about how the site looks. The pattern is always the same: photographs uploaded straight from a camera or phone, stored at full resolution, and sent at full size to a device displaying them at a fraction of that.
What actually helps, roughly in order of payoff:
- Serving modern formats, which are substantially smaller than JPEG at the same visible quality.
- Sizing images to how they are actually displayed, and sending a smaller file to a phone than to a desktop.
- Loading images below the fold only as the visitor approaches them, rather than all of them at once.
- Giving every image explicit dimensions, which fixes layout shift at the same time.
- Taking a hard look at decorative background images and sliders, which cost the most and convince no one.
A photography-heavy site is where this pays best. Website speed in Fort Lauderdale is almost entirely this problem, because marine and hospitality listings carry hundreds of full-resolution photographs each.
Scripts, tags, and the tracking nobody audited
The second big cause is JavaScript, and on business sites it is usually not the site's own code. It is the accumulated tracking: analytics, an ad pixel from a campaign that ended, a chat widget, a heatmap tool someone trialled, a popup builder, a review carousel. Each one was small on its own and nobody removed any of them.
Two useful questions. Which of these is still being used by anyone, and which need to run before the page is usable rather than after? Most tracking can load after the content without losing a single measurement, and chat widgets in particular are frequently the single heaviest thing on a page.
Fonts belong in this section too. Each custom font weight is a separate download, and text that waits for a font is text the visitor cannot read yet. Loading fewer weights and showing text immediately in a fallback usually gains more than it costs in appearance.
Hosting, caching, and the first byte
If the browser waits a long time before receiving anything at all, no amount of image optimisation will help, because nothing has started yet. That wait is the server, and it has three usual causes: cheap shared hosting, a database doing too much work on every request, or a plugin making an external call while the visitor waits.
Page caching fixes the symptom for anonymous visitors by serving a prepared copy, and it is worth having. It does not help logged-in visitors, a cart, or a checkout, which is why e-commerce sites need the underlying cause addressed rather than papered over.
This is also where hosting upgrades genuinely pay off, and the only part of the list where spending money is the fix rather than a substitute for one.
Plugins and themes
On WordPress, a slow site with no obvious cause is usually carrying too much machinery. Thirty plugins mean thirty sets of styles and scripts loaded on every page, including the ones only needed on a single contact form. Page builders add their own layer on top, and a theme that has been changed twice is often still loading assets from both predecessors.
The plugin audit in the maintenance checklist is the speed fix as well as the security one. It is unglamorous and it routinely removes more weight than any optimisation plugin will.
Test the way your customers actually arrive
Most local search happens on a phone, frequently outdoors, often on a connection worse than the one in your office. A desktop test on fibre will never show you what that is like, which is why plenty of owners believe their site is fast while their field data says otherwise.
Test on a mid-range phone, not a current flagship, with the connection throttled to something realistic. In Cape Coral the decisive moment is a homeowner standing in a driveway comparing three contractors, and whoever loads first gets the call. That is the condition worth optimising for, and it is not the one most sites are measured in.
What actually moves the number
If you only do a few things, do these, in this order:
- Fix the images. Modern formats, correct sizes, loaded as needed.
- Remove tracking and widgets nobody uses, and defer what remains.
- Cut font weights down and let text render immediately.
- Deal with server response time: caching, then hosting if caching is not enough.
- Audit plugins and remove what is not load-bearing.
- Reserve space for images, embeds, and anything that appears late, to stop the page jumping.
Then measure again, and compare against the numbers you recorded at the start. Speed work without a before and after is guesswork with an invoice attached.
When speed work is not the answer
Sometimes the honest answer is that the site is slow because of what it is, not how it is configured. A site built on a page builder three themes deep, carrying years of abandoned plugins, can be optimised into something tolerable, but it will not become fast, and the work costs more than it returns.
There are two signs of that. The audit finds a dozen causes rather than three, and every fix requires working around something structural rather than changing a setting. At that point a redesign is the cheaper option, and the redesign guide covers how to do it without losing the rankings you already have.
A speed audit should tell you which of those two situations you are in. If the structure is the problem, that is worth knowing before paying for optimisation twice.
Getting it done
If you want the audit rather than the explanation, my website speed service measures on real mobile hardware, names each cause with what it costs you in seconds, and then fixes them in order of payoff.
For built examples: the Athlean-X case study covers optimising a site handling over 100,000 daily visitors, where theme, CSS, and JavaScript work gained more than 20 Lighthouse points, and Learn Athlean-X covers the same kind of work on a high-traffic WordPress blog.