Why is my website slow, and does it actually matter?

Does speed matter for ranking?

Some, and less than the industry says. Google has said for years that page experience, including the Core Web Vitals, is a ranking signal, and it has also said content relevance outweighs it — a fast page about the wrong thing does not rank, and a slow page that is the best answer still can. Between two pages of similar relevance, the fast one is favored. That is the honest size of the ranking effect: a tiebreaker, not a lever.

The customer effect is the one to worry about. Most local searches happen on a phone, often on a cellular connection, often with a problem in front of the person. A page that takes several seconds to show anything, or that shows the number and then jumps it off the screen as an ad loads, loses that person to the next result. Speed is a conversion problem first. That is why it is in the no-calls post too.

What “fast” means, in Google’s numbers

Google publishes three thresholds — the Core Web Vitals — and measures them from real visitors on phones. “Good” means:

• Largest Contentful Paint (LCP) under 2.5 seconds — the main image or heading is on screen.
• Interaction to Next Paint (INP) under 200 milliseconds — a tap does something without a lag.
• Cumulative Layout Shift (CLS) under 0.1 — nothing moves around as the page finishes loading.

PageSpeed Insights shows both a lab run and, for sites with enough traffic, the real-visitor numbers from the field. The field numbers are the ones that count for search; the lab run tells you what to fix. The mobile tab is the one that matters.

The six usual causes

1. Images. A phone photo uploaded straight from the camera is several megabytes; a page with eight of them is a small movie. Resize to the display size, compress, serve WebP, and lazy-load everything below the first screen. On most small business sites this is more than half the problem.
2. The theme. Page-builder themes load their entire toolkit on every page — sliders, animations, icon sets, a dozen stylesheets — whether the page uses them or not. They are convenient to build with and slow to serve, and some cannot reach the thresholds however they are tuned.
3. Plugins and scripts. Each one is a file or ten. Chat widgets, review widgets, form builders, popup tools, analytics, pixels, a map embed. Each is a small delay, and there are twenty of them.
4. Hosting. Cheap shared hosting answers the first request slowly, and everything waits on that. A host with caching and an edge network serves the page from near the visitor.
5. Third-party embeds. An embedded map, a booking widget, a video player, a social feed — each pulls in another site’s code before yours finishes.
6. Fonts. Six weights of a Google font, loaded from another server, with the text invisible until they arrive.

What to fix first

In the order that pays: images, then the scripts and plugins you can remove, then hosting, then the theme. PageSpeed Insights names the largest element and lists the biggest files; start at the top of that list. Most sites get from a red score to a decent one on images and plugin pruning alone. The last stretch — from decent to genuinely fast — usually needs the theme replaced or the site rebuilt, because the page builder is the floor.

Measure after each change, on the mobile tab, and keep the numbers. A speed fix that is not measured is a speed fix that did not happen.

Why the sites we build are fast by default

Hand-written HTML and CSS, no page builder, no plugins, images sized and compressed at build time, fonts self-hosted in two weights, and the whole site served from a global edge network as static files — there is no server to be slow. Every page is measured with PageSpeed Insights before launch, and the numbers are in the launch report rather than a promise in the proposal. It is not clever; it is the absence of the six causes above.