Why is my website slow? How to measure it and fix it yourself

"Why is my website slow?" usually arrives as a vague complaint. Slow on which page? On a phone or a laptop? On the first visit or every visit? Until you can answer those, any fix is a guess, and guesses cost money and change nothing.

This guide shows you how to measure website speed yourself, read the result correctly and decide what to fix first. The figures here come from the kerneltics site itself, because those are the ones we measured.

Why website speed matters

• Ad money. Someone who taps your ad and leaves before the page opens cost you a click and saw nothing. They often never reach your reports either, because the analytics code did not get to run. In Meta Ads Manager, compare link clicks with landing page views. A wide gap is your cue to check speed, especially on a page built for ads.
• Google. Google recommends good Core Web Vitals and says this lines up with what its core ranking systems reward. It publishes no weighting. A fast page that does not answer the question will not rank for being fast, and anyone promising a position in exchange for speed is guessing.
• Bookings and orders. A button that lags, or a page that jumps as you tap, loses the order.

How to measure website speed yourself (free, five minutes)

Paste a URL into PageSpeed Insights. You get two results from two different sources, and most confusion comes from mixing them up. Start with mobile, and test two pages: the home page and the page your traffic actually lands on. Home pages are often the slowest, because new visitors load them with nothing cached.

The top section: real users

These are real visits from Chrome users on their own devices and networks, and Google's advice is to start here when the data exists. Three details from the tool's documentation change how you read it:

• It covers the last 28 days. Fix your site today and this section moves gradually over weeks.
• The figure is the 75th percentile, not an average. Three quarters of visits got this or better. A page passes when it is good on all three metrics.
• Small sites may get no data. With too few visits, the tool shows whole-site figures instead, or nothing. Check which one you are reading.

Metric	What it tells you	Good	Poor
LCP	When the largest image or text block appears	2.5 s or less	Over 4 s
INP	How fast the page responds to a tap or key press	200 ms or less	Over 500 ms
CLS	How much the layout jumps	0.1 or less	Over 0.25
TTFB (supporting, not one of the three)	When the server's first response arrives	800 ms or less	Over 1,800 ms

Anything in between is labelled "needs improvement".

The bottom section: a simulation

Lighthouse loads your page on one mid-tier phone (Moto G4) over a mobile connection and gives a score: 90 and up is good, 50 to 89 needs improvement, under 50 is poor. Use it to find causes, not to judge the site:

• The score moves between runs even when nothing changed, because the network and test machine vary. Run it a few times and take the middle one.
• The test may not run anywhere near your customers. It runs from a Google data centre, and the report names only a region: North America, Europe or Asia. Its server timings are not necessarily what a visitor in Saudi Arabia gets, so also open the page on your phone over mobile data.
• Green is not a certificate. The same documentation says good lab data does not necessarily mean real visitors have a good experience.

GTmetrix and WebPageTest add a file-by-file view. Tools do not all measure LCP the same way, so compare a tool with itself, before and after. For the whole site over time, use the Core Web Vitals report in Search Console.

First, find out what your largest element is

The LCP filter in the diagnostics names the exact element and shows how its time was spent. Google splits that time into four parts:

Part	What is happening	What usually stretches it
Time to first byte	Waiting for the start of the page	A distant or crowded server, redirects, no page cache
Load delay	The browser has not started fetching it	CSS backgrounds, images added by JavaScript, lazy loading on the top image
Load duration	It is downloading	A big image or font file, distance
Render delay	Downloaded but not on screen	Blocking files, waiting on JavaScript, an A/B testing library hiding it

The two "delay" parts should sit close to zero. Google describes a page whose largest element stays hidden until JavaScript finishes: compress the image and the download gets shorter, yet LCP does not move, because the time shifts to render delay.

The largest element may not be an image at all. On our pages it is the Arabic headline, so compressing every image would leave LCP where it is. The font file is what moves it.

Why is my website slow? Six causes that keep coming up

1. Images

Camera photos at several megabytes, uncompressed, all loading in the first second. Dimensions matter even after compression. Five project images on our home page, already WebP, total 474 KB at their original 1144 px width, while a phone displays them at about 330 px. Adding smaller copies for the browser to choose from (srcset) brought the 640 px set to 125 KB.

The fix: compress, use WebP or AVIF, provide mobile sizes, set width and height so nothing jumps, and lazy-load what sits below the fold. The top image is the exception: loading="lazy" delays it and fetchpriority="high" brings it forward. A CSS background is only found after the stylesheet arrives, so make it a normal image or preload it.

2. Fonts, especially Arabic ones

A font from an external server, four weights when the design uses two, a file carrying alphabets you never show. Browsers typically hold back text until the font arrives, so when your largest element is a headline, the font decides your LCP.

On our site the Google Fonts stylesheet was the largest render-blocking request, about 1.3 seconds on mobile when we measured it. We replaced it with one variable WOFF2 file covering weights 400 to 700, for the Arabic range only, about 22 KB, declared directly in the page head.

The fix: a variable file or two weights, WOFF2, only the characters you use (check the licence), and font-display: swap so text shows in a fallback first. Two cautions. Self-hosting is not automatically faster: Google calls the difference less clear-cut and ties it to a CDN and HTTP/2. And the swap can shift text when the fallback differs in size, losing in CLS what you gained in LCP.

3. Third-party scripts

Analytics, ad pixels, chat widgets, maps, embedded video. This is usually what drives INP: while a phone is busy running someone else's code, your customer's tap waits.

Our Google Analytics library is about 190 KB. It used to download alongside the page's own files on slow phones. Now it loads once the page is on screen and the browser is idle, or on the first interaction. Events wait in a queue; the cost is that someone who leaves before that point is not counted.

The fix: remove what nobody reads, add async or defer to scripts in the head, and show maps and videos as a still image until tapped. A WhatsApp button needs no widget: a plain wa.me link does the job, which is how ours works. After using a deferral tool, confirm in the Network tab that the script really moved.

4. Plugins and themes

On WordPress, a plugin can load its files on every page, even pages that never use it. Heavy page builders and slider themes do the same.

The fix: on a staging copy, switch plugins off one at a time, measure after each, and remove what you can live without. Update WordPress and PHP, and clean the database. If most of your unused code comes from the theme, try a lighter one before considering a new site.

5. The server: hosting, caching and redirects

Look here when TTFB is high, because everything else waits for that first byte. Usual reasons: crowded shared hosting, a distant server, pages built from scratch for each visitor, and redirect chains (short link to http to www to the page).

The ad trap: ad links carry tracking parameters such as gclid and fbclid that differ on every click. If your CDN treats each value as a new page, every ad visitor goes back to the origin server instead of getting the cached copy. The page is quick when you open it and slow for everyone you paid for. Test the full ad URL, and set your cache to ignore those parameters.

The fix: caching for pages and static files, a CDN (ask about its nearest location to your visitors rather than assuming), and as few redirects as possible. Only then think about moving host.

6. How the site is built

Sites that depend on JavaScript for everything send an almost empty page, then draw the content. That is slow for visitors and slower for Google, and it is also reason two in why your website is not on Google. Fade-ins belong here too: a headline that starts transparent holds LCP back for the whole fade. Ours now appears in place on a fresh load, and fades are kept for content further down.

The fix: send the content with the page (pre-rendering or server-side rendering), and load heavy code only where it is used. Our 3D logo's library only downloads on pages that show it.

When the problem is tapping or jumping, not loading

High INP: too much code running at the moment of the tap. Go back to causes 3 and 4, and test on an ordinary phone, not your new one.

High CLS: images without dimensions, a banner injected above the content, or the font swap. Reserve the space for each element before it loads.

How to improve website speed: the order we work in

1. Real user data: which metric is poor, on which device? If all three are good, you probably have no problem worth paying for.
2. TTFB: if high, start with the server, caching and redirects.
3. The largest element: make it start loading with the first file on the page, and remove whatever delays it.
4. Images.
5. Scripts and plugins: remove first, defer second.
6. Fonts.
7. Moving host: last, and only if TTFB stays high after caching.

Change one thing at a time and measure after it, clearing the cache first. Google says a single quick fix rarely improves LCP in a meaningful way, so do not be surprised if step one shows little.

Before you pay anyone to speed up your site

Plenty of services sell a score of 90, and a score can rise while nothing changes for the visitor. One known method delays every script until the first interaction. The test never taps anything, so the score looks excellent, while the real visitor gets all that code on their first tap, which shows up in INP. So ask for these in writing:

• Before and after measurements of the same pages with the same tool, judged on real user data after 28 days, not the score on delivery day.
• A list of every change, and a backup taken before starting.
• A check after delivery: the contact form, cart and payment, the WhatsApp button and your tracking codes.

The wider questions are in how to choose a software company. Not worth your money: chasing 100 when visitors' metrics are already good, rebuilding the site before trying the above, and stacking speed plugins.

Website speed questions we get

I run WordPress. What do I do first?

One well-configured page cache plugin, plus compressing images to WebP. Neither touches the design.

My store is on a hosted platform such as Salla or Zid. What can I control?

Not the server, but images, the theme, add-on apps and tracking codes are yours. Remove any app you do not use and measure again.

Should I remove my ad pixels?

No. Load them after the content, and talk to whoever runs your campaigns before delaying them much, because too long a delay means fewer events reach the campaign.

Will speeding it up break my site?

Images and caching rarely change anything visible. Delaying scripts and merging stylesheets can break things, so do those one step at a time on a staging copy.

How often should I measure?

After every change, once a month, and after any new plugin or tracking code. Sites slow down gradually without anyone noticing.

How we do it

Send us your link and we start from the same order as above: real user data, then the largest element, then the six causes, and we tell you what is worth fixing and what is not. The examples here are from our own site, and you can check them in any page's source. Our live projects are on the works page, and the informational website package and its scope are on the services page. If you measure and hit a wall, book a free consultation and send us the link.