Your website loads instantly on the office Wi-Fi, on your new laptop, with everything already cached. Your customer opens it on a mid-range phone, on mobile data, stuck in traffic on the Ring Road. For them, it's a white screen, then a jumping layout, then a button that doesn't respond.
They don't complain. They go back and tap the next result.
Speed is the first impression of your business, delivered before anyone reads a word. The good news: Google publishes exactly how it measures it, and most fixes are well known.
What Core Web Vitals actually measure
Think of a restaurant. Speed isn't one thing there either. It's how long until your food arrives, how quickly the waiter reacts when you raise your hand, and whether the table stays still while you eat. Google's Core Web Vitals measure those same three things for a web page.
| Metric | What it measures | Restaurant picture | Good | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the main content, usually the hero image or headline, appears | How long until the main dish reaches the table | 2.5 s or less | Over 4 s |
| INP (Interaction to Next Paint) | How quickly the page visibly responds when someone taps, clicks or types | How fast the waiter reacts when you raise your hand | 200 ms or less | Over 500 ms |
| CLS (Cumulative Layout Shift) | How much the layout jumps around while loading | Whether the table moves as you reach for your glass | 0.1 or less | Over 0.25 |
Anything between good and poor counts as "needs improvement".
Two details matter. First, Google judges each metric at the 75th percentile of real visits, separately for mobile and desktop. So it isn't enough for most visits to be fast; three out of four have to be. Second, INP replaced an older metric, FID, in 2024. If an article still talks about FID, it's out of date.
Why CLS is more than an annoyance
A layout shift sounds cosmetic until it costs money. Imagine a customer about to tap "Continue". A late-loading banner pushes everything down, and they tap "Cancel" instead. That's CLS. It usually comes from images without set dimensions, ads or embeds that load late, and fonts that swap and change the text size.
How to measure your site properly
There are two kinds of data, and mixing them up causes most confusion.
Field data comes from real Chrome users visiting your site over the past 28 days. It's what Google uses. You'll see it at the top of PageSpeed Insights and in the Core Web Vitals report in Google Search Console, if your site has enough traffic.
Lab data is a simulated test run once, on a simulated device and network. It produces the famous 0 to 100 score. Useful for diagnosing problems, but the score changes from run to run and isn't what Google ranks on.
Also watch TTFB (time to first byte): how long your server takes to start answering. It isn't a Core Web Vital, but a slow server delays everything after it. Google's guidance is to aim for 0.8 seconds or less. If yours is much slower, look at your hosting first; our hosting guide explains what to check.
What actually makes websites slow
On most slow sites the problem isn't mysterious. It's a few heavy things the visitor never asked for.
Images
The most common culprit. A 4000-pixel photo straight from a camera, shown in a 400-pixel box on a phone, wastes megabytes. The fixes:
- Resize images to the size they're displayed, with smaller versions for phones.
- Use modern formats like WebP or AVIF, which are much lighter than JPEG or PNG at similar quality.
- Lazy-load images further down the page, so they load only when the visitor scrolls near them.
- Always set width and height, so the browser reserves the space and nothing jumps.
Fonts, especially Arabic ones
Arabic fonts can be heavy, because they carry many letter shapes. Load three families in four weights each, and the phone downloads a small library before showing text properly. Use one or two families, only the weights you need, subsets where possible, and let text show in a fallback font while the custom one loads.
Third-party scripts
Chat widgets, several ad pixels, heatmap tools, embedded maps and video players each add code from someone else's server. Individually small, together they are often the heaviest part of the page and the main cause of poor INP. Ask of each one: is someone actually using this data?
Server and code
A slow server, no caching, uncompressed files or a database query that runs on every page view will drag down everything else. Caching, compression and a CDN for static files are standard fixes. On bloated sites, the bigger gain comes from removing what isn't needed.
Does speed affect Google rankings?
Yes, but less than many sales pitches claim. Core Web Vitals are one of the signals Google's ranking systems use, as part of page experience. Relevance and helpful content still come first: a fast page with thin content won't outrank a slower page that answers the question better.
Where speed pays more directly is behaviour. Faster pages keep more visitors, and every paid click that bounces before the page loads is money spent for nothing. For ad traffic this matters a lot, as we explain in landing pages that convert ad traffic. The wider picture is in our practical guide to SEO in Egypt.
Common speed mistakes
Chasing a perfect 100. The lab score is a diagnostic tool. Passing Core Web Vitals on real visits matters far more than going from 92 to 100.
Testing only on desktop. Most of your visitors in Egypt and the Gulf are likely on phones. Mobile results are the ones to fix first.
Adding "just one more" script. Every marketing tool is small on its own. Review them every few months and remove what nobody uses.
Buying bigger hosting to fix heavy pages. A faster server won't make a 5 MB image lighter. Fix the page first, then judge the hosting.
Your speed checklist
- Field data in PageSpeed Insights or Search Console checked for mobile
- LCP at 2.5 seconds or less, INP at 200 ms or less, CLS at 0.1 or less
- Images resized, in WebP or AVIF, with width and height set
- Hero image loaded early, not lazy-loaded
- One or two font families, only the weights you use
- Every third-party script justified, and heavy ones delayed
- Caching and compression on, with a CDN for static files
- Server response (TTFB) around 0.8 seconds or less
- Tested on a real mid-range phone over mobile data
Questions people ask
Why does my PageSpeed score change every time I test?
The lab test runs on a simulated device and network, and small differences in server response and third-party scripts change the result. Look at trends and at the field data, not a single run.
My site has no field data. What does that mean?
Your site doesn't yet have enough Chrome visits for Google to report. Use lab tests and real-phone testing in the meantime.
Is a custom-coded site faster than a template?
Often, because it only loads what it uses, while many templates ship features you never turn on. But a custom site with huge images and ten scripts will still be slow. Discipline matters more than approach; see custom code vs ready-made templates.
Will a CDN fix a slow website?
It delivers images and files faster, especially to distant visitors. It won't fix a slow server, heavy scripts or oversized pages.
How often should I check my site's speed?
Monthly, and always after adding a new section, widget or tracking code.
Fast is a habit
A fast site isn't a one-off optimisation. It's a set of decisions: lighter images, fonts chosen with care, every script earning its place. Sites slow down as things are added, so keep watching the numbers.
If you want to know where your current site loses time, or you're planning a new one and want speed built in from the start, book a meeting with us.