You speed up a website in three steps: measure where the visitor waits (server, images or JavaScript), fix the biggest bottleneck and verify the result with the same measurement. The most time is usually saved by properly resized images, fewer third-party scripts and a working cache. Slow loading and a delayed response to a click are two different problems, so I treat each one differently.
Why speed matters
A slow website holds customers up at the moment they decide. They click a service, look for a price or send an inquiry, and every wait gives them a reason to go to a competitor. How much it costs you specifically shows up in your analytics: compare conversions on mobile and desktop and on fast and slow pages.
Core Web Vitals assess loading (LCP), interaction responsiveness (INP) and visual stability (CLS). Google measures them at the 75th percentile of real visits, separately for mobile and desktop (definitions and method):
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
LCP |
When the largest element (photo, heading) appears |
up to 2.5 s |
2.5-4 s |
over 4 s |
INP |
How quickly the page reacts to a click or typing |
up to 200 ms |
200-500 ms |
over 500 ms |
CLS |
How much content jumps while loading |
up to 0.1 |
0.1-0.25 |
over 0.25 |
Speed and Google rankings. According to Google, Core Web Vitals are used by its ranking systems, but relevant content still wins even with weaker speed. Speed will not replace good content, but it helps against evenly matched competitors and above all improves what happens after the click.
Responsiveness helps people complete tasks. Test search, opening the offer and submitting a form. A performance score alone does not tell you whether a customer actually gets to the inquiry.
How to measure it (free, one minute)
Measuring speed in a minute
- PageSpeed Insights mobile and desktop scores including real-user Core Web Vitals (if the site has enough traffic); assess lab scores separately from actual visitor data
- Search Console → Core Web Vitals an overview of which groups of pages pass and which don't
- Common sense your own site on a phone over mobile data; whatever annoys you annoys your customers
To find the cause, use further tools:
| Tool | What to use it for | Data type |
|---|---|---|
| PageSpeed Insights | Quick overview of one URL, visitors' Core Web Vitals | lab + real visits |
| Search Console | Which page groups have a problem and whether a fix worked | real visits |
| Lighthouse in Chrome (F12) | Repeated tests while tuning, list of recommendations | lab |
| Chrome Performance panel | Which scripts block the page and delay clicks (INP) | lab |
| WebPageTest | Request waterfall, loading filmstrip, tests from different locations | lab |
Why is my PageSpeed score good while the site still feels slow?
Because the score is a lab test of a single visit. According to Google's documentation, PageSpeed Insights simulates mobile as one device on a mobile network, whereas real-visit data (Chrome UX Report) summarises the previous 28 days across many phones and connections. A customer's slow phone, a signed-in account, a full basket or advertising scripts that only start after cookie consent are invisible to the lab. What counts is the visitor-data section and Search Console; a 90+ score is a good start, not the goal.
What slows websites down most (and how to fix it)
Six most common causes of a slow website
- Images file size and loading priority
- JavaScript and plugins scripts that block the main thread
- Server and network time to first byte (TTFB), a good value is roughly 0.8 s or less
- Fonts and third-party scripts every font, map, video or chat is more waiting
- Cache and CDN finished pages and files without repeated generation and downloading
- Reaction after a click (INP) long JavaScript tasks that block the main thread
1. Images: file size and loading priority
Images are the most common and cheapest fix. A phone photo often has several megabytes and thousands of pixels, while the website displays it a few hundred pixels wide. The routine I use:
- Resize to the displayed size and use
srcsetto send phones a smaller variant than desktops. - Convert to WebP or AVIF and compare the result on the same photo (the example below saved over 330 kB).
- Lazy-load only below the first screen. Load the main image (LCP), on the contrary, as early as possible, with
fetchpriority="high". - Set width and height so the image does not push text around while loading (CLS).
2. Bloated JavaScript and plugins
Use the network panel and a profiler to identify downloaded scripts and main-thread work. Plugin count does not measure cost: some run only on the server or in administration. Remove unused functionality and verify analytics, forms and consent still work. A single tag manager can also launch many other scripts.
3. Server and network response
TTFB (time to first byte) includes server computation, the network, redirects and connection setup. Google considers roughly 0.8 s or less a good value (TTFB methodology). When TTFB is high, compare a cached and an uncached request: a fast cached response and a slow uncached one points to page generation (database, plugins), slow in both cases points to hosting or the network. With hosting, check the current PHP version (for WordPress), HTTP/2 or HTTP/3 and Brotli or gzip compression. Unnecessary redirects (http → https → www) delay every visit, so cut them down to one.
4. Web fonts and third-party scripts
Every font and every third-party script (maps, videos, chat, widgets) is more waiting. For fonts, these help:
- WOFF2 format and only the weights you really use (1-2 families, or one variable font).
font-display: swap, so text appears immediately in a system font instead of waiting for the web font (web.dev recommendations).- Self-hosting the font instead of loading it from a third-party server, if the site runs on a CDN.
Embed maps and videos as a preview that loads the real player only after a click. A chat widget can start after an interaction or with a delay after the page loads.
5. Missing cache and CDN
A cache stores finished pages and files so they do not have to be generated and downloaded again every time. Static files (images, CSS, JavaScript with a version fingerprint in the file name) can have a long browser lifetime, HTML pages a shorter one with change validation. A CDN then serves content from a server closer to the visitor. Just be careful with signed-in accounts, the basket and personal data: they do not belong in a public cache.
6. Slow reaction after a click (INP)
The page loads, but after a click on the menu, a filter or a button nothing happens for a moment. The cause is usually long JavaScript tasks blocking the browser's main thread. According to the web.dev guide to INP, these help:
- split long work after a click into smaller parts and show feedback first (for example the opened menu), the rest afterwards;
- defer scripts that are not needed immediately (analytics, chat, A/B tests, advertising pixels);
- reduce the DOM: thousands of elements on a page slow down every repaint;
- find in the Performance panel which script runs longest on a click.
INP is a typical problem for e-shops with many marketing scripts and websites built on heavy page builders.
Worked example: The second request checks the same version
verified HTTP example
| Request | Response | Body |
|---|---|---|
| GET /style.css | 200; ETag: "css-v1" | 21 B |
| GET + If-None-Match: "css-v1" | 304; ETag: "css-v1" | 0 B |
| Cache-Control in both | public, max-age=0, must-revalidate | - |
Captured locally. Revalidation example; does not test a CDN or browser speed.
How to speed up a WordPress website
WordPress is most often slowed down by three things: no page cache, unoptimised images and piled-up plugins or a heavy page builder. Without a developer you can:
- Turn on page caching, either at the hosting level or with one caching plugin (not two at once).
- Optimise images with a plugin that resizes them on upload and creates WebP.
- Review plugins: switch off unused ones and check in Lighthouse how much JavaScript and CSS the rest add to every page.
- Update PHP to a version your hosting and WordPress support. Versions past end of support no longer get security fixes (supported PHP versions) and newer versions tend to be faster too.
- Limit external fonts and embedded videos as in point 4 above.
If the site is still slow on mobile afterwards and most of the time is spent by the theme or page builder, further tuning tends to cost more than replacing the theme.
Checklist: 10 points of a fast website
- The main image loads immediately, the others lazily.
- Photos are resized to the displayed size and in WebP or AVIF.
- Images and embeds have dimensions, nothing jumps.
- The server responds within 0.8 s, pages come from cache.
- Only one redirect (or none) on the way to a URL.
- Brotli or gzip compression and HTTP/2 or HTTP/3.
- At most 1-2 font families in WOFF2 with
font-display: swap. - Third-party scripts are deferred and reviewed regularly.
- Maps, videos and chat load only after a click.
- You watch Core Web Vitals in Search Console and re-measure after every larger change.
When tuning isn't enough and it's time to rebuild
A mobile score below 40 or LCP above 4 seconds after image optimisation does not on its own mean a new website. Profile the affected URL first: server, requests, main thread, largest content element and third-party scripts. When the foundation is the brake (theme, page builder, system), compare the cost of further tuning with a rebuild including migration and testing. I explain technology choices in why Next.js for a business website; a fast website depends mainly on how it is built, not on the framework's name.
Website speed optimisation: how I do it for clients
When I do website speed optimisation, I always follow the same order so the work does not turn into random tweaks:
How I optimise speed for clients
- Starting point PageSpeed Insights for the main page types, Core Web Vitals in Search Console and real Chrome data where Google has it
- Causes by impact images, third-party scripts, server response, fonts; first whatever slows down the most pages at once
- Place of repair shared faults belong in the template, an unusually heavy image or integration on one URL may require a local fix
- Verification by measuring and watching so the site does not slow down again with later changes
A one-off optimisation is billed at €60/h and the budget is confirmed upfront based on the initial measurement. On an ongoing basis I handle it as part of website management: the Growth plan at €400 a month includes Core Web Vitals optimisation in its scope. The price of every plan is broken down in how much website management costs.
Frequently asked questions
What website speed is good?
The goal is good Core Web Vitals for real visitors: the largest element within 2.5 s (LCP), reaction to a click within 200 ms (INP) and stability within 0.1 (CLS), on mobile, where a site is usually slowest. The PageSpeed Insights score is a tuning aid, not the goal.
Does website speed affect Google rankings?
Yes, but to a limited extent. Google states that its ranking systems use Core Web Vitals, but it will still show relevant content on a slower page. Speed has a bigger effect on how many visitors actually complete a purchase or inquiry after the click.
How does hosting affect website speed?
Hosting mainly determines server response time (TTFB). Overloaded shared hosting or a distant server shows on every page. But when TTFB is fine and the site is slow, changing hosting will not help; images, scripts or the theme are the brake.
How can I speed up a website without technical skills?
Resize and convert images (with a plugin on WordPress), turn on page caching, remove unused plugins and replace embedded videos with a preview. You can do these steps from the admin and they tend to be the biggest part of the speed-up.
How much does website speed optimisation cost?
With me, a one-off job is €60/h with the budget confirmed upfront; a smaller site with common problems (images, cache, scripts) tends to take a few hours. Ongoing monitoring and optimisation are part of the Growth plan of website management.
Summary
Start by measuring specific pages in PageSpeed Insights and distinguish lab runs from visitor data. Prioritise fixes from the cause: images, scripts, server, fonts or cache. Lazy-load images below the first screen and load the main image as early as possible. Repeat measurement under comparable conditions after a change; a rebuild decision depends on what slows the site down and on the cost of the fix, not on a single score.
Don't want to deal with it yourself? Speed monitoring is part of my website care service, measurement, optimization and regular maintenance. And if your site is on fire right now, there's express help.