Notebook
Why your website is slow and what to do about it
Core Web Vitals in plain English. What is actually measured, the four most common causes of a slow website, and what you can fix without a developer.
A slow website loses visitors before it has even loaded, and Google takes it into account when ranking results. The good news is that most slow websites are slow for one of four reasons, and two of them you can fix yourself.
What is actually measured
Google uses three indicators, known together as Core Web Vitals. In plain terms:
- LCP — how long it takes for the largest element on the screen to appear. Usually the main image or the heading. Target: under 2.5 seconds.
- INP — how quickly the page responds when you click on something. It replaced the older FID. Target: under 200 milliseconds.
- CLS — how much the content jumps around while loading. That is the effect where you go to click a link and it shifts under your finger. Target: below 0.1.
You can measure this for free in PageSpeed Insights, or in Google Search Console if you have it connected. Search Console is more accurate, because it shows data from real visitors rather than from a single lab test.
Cause one: images
In nine cases out of ten this is the main culprit. A photo uploaded straight from a camera is often five megabytes and 6000 pixels wide. On the site it is displayed at 800 pixels wide — so megabytes get downloaded that nobody will ever see.
What you can do yourself: before uploading, resize images to a sensible size (on most sites a width of 1600 px is enough) and save them as WebP. There are free online tools for this, and plugins that do it automatically on upload.
What needs a developer: setting up lazy loading, correct sizes for different screen widths, and preloading the main image so that LCP improves.
Cause two: too many plugins
Every WordPress plugin brings its own CSS and JavaScript with it, and most of them load on every page — including pages where they are not used at all. A slider plugin used on the home page also loads on the contact page.
What you can do yourself: go through the list of plugins and switch off the ones you do not use. Switching a plugin off is not enough — delete it. For each one, ask what exactly it does. If you cannot answer, you probably do not need it.
What needs a developer: loading scripts conditionally, only where they are needed, and replacing heavy plugins with a few lines of custom code.
Cause three: hosting
The cheapest shared hosting means a few hundred other websites are running on the same server as you. When one of them gets a surge, you slow down too.
How to spot it: in PageSpeed Insights, look at the server response time. If it is above 600 milliseconds, the problem is underneath the site, not in it, and optimising images will not save it.
What to do: moving to better hosting is usually the cheapest speed-up you can buy. For Slovak sites it also helps if the server sits in Europe.
Cause four: fonts and external scripts
Every font from Google Fonts, every chat widget, every tracking script is another connection to somebody else’s server that your page has to wait for. Three fonts in five weights means fifteen files.
What you can do yourself: consider whether you really need three different fonts. Two are almost always enough. And go through the tools stuck onto your site — a broken chat widget from 2022 is still slowing it down.
What needs a developer: hosting the fonts locally, limiting them to the weights actually used, and deferring scripts that are not needed the moment the page loads.
What NOT to do
Do not buy five “optimisation” plugins at once. They get in each other’s way, minify the same files twice, and the result is usually a broken layout and a site slower than before. One good cache plugin is enough.
And do not chase a hundred points in PageSpeed. It is a rough guide, not a grade. Real data from visitors in Search Console matters more than the score from a single measurement.
Where to start today
- Measure your site in PageSpeed Insights — mobile as well as desktop
- Look at the server response time; if it is high, deal with hosting first
- Find the largest images on the home page and shrink them
- Delete the plugins you cannot explain
- Measure again and compare
If nothing improves after that, the problem is deeper and the code needs looking at. That is when to write to me — I start with a measurement and you get a list of findings ordered by their effect on speed, with an estimate of the work for each one. You decide which of them I do.