Most conversations about website speed go nowhere because nobody agrees what slow means. Somebody says the site feels sluggish, somebody else opens it and it seems fine, and the discussion ends without a decision.
That is a solved problem, and it has been for several years. Google publishes exactly what it measures, what counts as good, and, unusually for a search engine, its own scans of millions of real pages showing what actually goes wrong on them. That last part is valuable, because it tells you where to look before you have looked anywhere.
This article covers the three measures, what causes each of them to fail according to Google's own data, how to find out which one applies to you, and what to do in what order. No part of it requires you to write code, though some of the fixes will need somebody who can.
What slow actually costs you
Before the diagnosis, it is worth being clear about why this deserves attention at all, because "the site feels slow" is not a business case and it never wins an argument against a feature request.
The cost shows up in four places, and only one of them is search ranking.
People leave before the page appears. Somebody who taps a link and sees a blank screen for four seconds has already formed a view about your business, and a proportion of them go back to the search results and click the next result instead. This is the largest and least visible cost, because those visitors never appear in your funnel as anything except a bounce.
Conversion falls at every subsequent step. A slow product page reduces how many people reach the cart. A slow cart reduces how many reach checkout. The effect compounds through the funnel rather than being a single loss at the start, which is why sites with a speed problem often have a conversion problem that gets blamed on design or pricing.
Paid traffic costs more per outcome. If you are buying visits and losing a share of them to a slow page, you are paying full price for traffic that never sees your offer. This is the version of the cost that finance teams find easiest to understand, because it is a straightforward waste of a budget line that already exists.
Search ranking, last. Page experience is a signal among many rather than the deciding factor.
The reason to put ranking last is practical. If you justify performance work on ranking alone, the work gets deprioritised the moment somebody points out that a competitor with a slower site outranks you, which happens frequently and proves nothing. If you justify it on conversion and wasted advertising spend, the argument holds regardless of what any competitor is doing.
There is a related point worth making internally. Almost everybody who works on your website looks at it on a good laptop, on office broadband, with the page already cached from the last twenty times they opened it. That experience bears very little resemblance to a customer on a mid-range phone on mobile data, opening the page for the first time. The measurement tools below exist precisely because the people building a site are the worst-placed people to judge how fast it feels.
What is actually being measured
Three things, together called Core Web Vitals [1][2].
Largest Contentful Paint measures how long until the main content of the page appears. In practice this is usually the big image or headline at the top. Good is within 2.5 seconds of the page starting to load [1][3].
Interaction to Next Paint measures how quickly the page responds when somebody taps or clicks. Good is under 200 milliseconds, and Google sets 500 milliseconds as the poor threshold [1][3].
Cumulative Layout Shift measures how much things move around while the page loads. Good is under 0.1 [1][3].
Google also publishes a poor threshold of 4 seconds for loading, with a middle band between good and poor that needs improvement [3].
Each of the three corresponds to something a person actually experiences. Waiting for the page to appear. Tapping something and nothing happening. Reaching for a button that moves just as you get there. They were designed to be measured from real visits rather than from a test machine, which is why they reflect what your customers get rather than what your developer's laptop gets.
On ranking: page experience is one of many signals and it is not the dominant one. A fast page with weak content will not outrank a slow page that answers the question better. What speed reliably affects is whether people stay, which affects conversion directly. Treat ranking as the secondary benefit.
Where to look, in fifteen minutes
Two free tools, neither of which requires setup beyond what most businesses already have.
Google Search Console reports Core Web Vitals from real visits to your site over the previous month, grouped by page type. This is the authoritative view because it is your actual visitors on their actual phones.
PageSpeed Insights analyses a single page and shows both real-world data and a laboratory test with specific recommendations [4].
Start with Search Console to find out which pages are failing and on which measure, then use PageSpeed Insights on those specific pages to find out why.
One thing to understand before you start, because it causes a great deal of wasted argument. Field data and lab data frequently disagree [5].
Field data comes from real people on real connections. Lab data comes from a simulated test under controlled conditions. When they conflict, the field data is what Google uses and what your customers experience.
This is also why your score changes every time you run a test. A lab test simulates one visit; small variations produce different numbers. Chasing a single test score is unproductive. Use lab tests to identify what to fix, and field data to judge whether it worked.
Loading: it is almost always the images
Google's own analysis is unusually direct here. 73 per cent of mobile pages have an image as their largest element [6], which means that image is what the loading measure is timing.
So if your page feels slow, the image at the top of it is the first place to look and usually the biggest single win available.
Three things go wrong with it, and they are worth separating because the fixes differ.
The file is larger than it needs to be. A photograph straight from a camera or a stock library, uploaded without resizing, can be several megabytes. Serving a correctly sized image in a modern format frequently removes most of a page's weight with no visible difference at all.
The browser cannot find it early enough. This one is less obvious and very common. The browser reads your page and immediately starts downloading things it can see referenced. If your main image is only referenced inside JavaScript that runs after the page loads, the browser cannot see it in time. Google found that among pages where an image was the largest element, 35 per cent had image addresses that were not discoverable in the initial response [6].
The fix is to reference the image with an ordinary image tag in the page itself, or use a preload instruction telling the browser to fetch it immediately. Small change, disproportionate effect.
It has been told to load late. Lazy loading tells the browser not to download an image until the visitor scrolls near it. That is genuinely useful for images further down a page. On the main image at the top it is actively harmful, because you have instructed the browser to delay the one thing that determines your loading score.
Google also notes that only 15 per cent of eligible pages use the priority attribute that tells the browser which resource matters most [6]. Marking your main image as high priority, and removing any lazy-load instruction from it, is a two-line change.
Then there is the delay before anything arrives at all. This is where hosting and geography matter. A content delivery network keeps copies of your site in data centres around the world so a visitor is served from somewhere near them. Google found only 33 per cent of pages are served this way [6].
For a UAE business this is worth taking seriously, because a great many sites here run on hosting in Europe or North America. Every single request travels there and back before anything appears on screen. A content delivery network addresses the largest fixed delay in your page load without touching a line of your code. Our guide on hosting in the UAE covers the underlying choice.
A worked diagnosis
To make the sequence concrete, here is how this actually runs on a typical business site that has never been examined.
Search Console says the product pages are failing on loading, and the homepage is in the needs-improvement band. Everything else is fine. That already tells you where to spend the effort: product pages, and specifically the loading measure. Nothing else needs attention yet.
PageSpeed Insights on a product page shows the largest element is the main product photograph, arriving at 4.1 seconds. The lab test lists the image as the largest contentful paint element and flags that it is not preloaded.
Looking at the page itself, three things are true. The image is 2.4 megabytes, uploaded at full camera resolution and scaled down by the browser to fit a 600-pixel container. It is loaded by a gallery script rather than referenced directly in the page. And the gallery applies lazy loading to every image including the first one.
That is all three of the common image problems on one page, which is entirely normal.
The fixes, in order of effect. Serve the image at the size it is actually displayed, in a modern format, which takes it from 2.4 megabytes to perhaps 120 kilobytes. Reference it directly in the page so the browser finds it immediately. Remove the lazy-load instruction from the first image only, leaving it on the rest of the gallery.
The result is not marginal. The largest single item on the page shrank by roughly ninety-five per cent, and the browser now starts fetching it in the first few milliseconds instead of after a script runs. This is the shape of most first-pass performance work: a small number of specific changes to one template, applied across every product page at once.
What it did not require: a redesign, a hosting change, a new platform, or a rebuild. That matters, because all four of those get proposed in response to a slow site and none of them was the problem here.
Responsiveness: too much code
When a page feels unresponsive, the cause is almost always the same. The browser is busy running JavaScript and cannot respond to taps.
Google's framing is blunt: when responsiveness measures are poor, it is usually because the page is trying to do too much, and the main solution is removing unnecessary code to make lighter pages [6].
Note that this is a removal problem rather than an optimisation problem, which is unusual and which changes who can fix it.
The technical unit here is the long task: a piece of work occupying the browser for more than 50 milliseconds without pausing. During that time nothing the visitor does gets a response. A page full of long tasks feels sluggish even when it looks finished, which is exactly the frustration of tapping a button and watching nothing happen.
Where does all the code come from? Overwhelmingly from things added over years and never removed. An analytics tool, a chat widget, a heatmap recorder from a redesign two years ago, a tracking pixel from a campaign that ended, a plugin somebody installed to solve one specific problem.
Google's own recommendation includes reviewing plugins and widgets and removing those no longer used [6].
Find out what is actually running. Open your browser's developer tools on your own homepage and look at the network activity, or list every tag in your tag manager. Most businesses find several things nobody uses any more. Each one costs loading time, adds a third party handling your visitors' data, and contributes to the responsiveness problem. The removal decision is usually commercial rather than technical: somebody has to confirm nobody is relying on it.
Our guide on life after third-party cookies covers the same audit from a measurement angle, and our guide on app privacy covers why an unaudited third-party footprint is a disclosure problem as well as a speed one.
Layout shift: mostly unsized images
The most fixable of the three, and the most common cause is almost embarrassingly simple.
66 per cent of pages have at least one unsized image [6].
When an image has no stated dimensions, the browser does not know how much space to reserve. It lays out the page without the image, then shifts everything down when the image arrives. That is the jump you notice when you are halfway through reading a sentence.
The fix is to give every image a width and height in the markup, or the equivalent in your stylesheet. The browser reserves the correct space in advance and nothing moves. It applies everywhere, it is a small change, and on many sites it resolves most of the problem on its own.
Three other causes worth knowing:
Advertisements and embeds loading into space that was not reserved for them. Same problem, same fix: reserve the space.
Fonts that swap late. The page renders in a fallback font, the real font arrives, text changes size, and everything below reflows. This matters particularly for Arabic pages, where web fonts can be large. Our guide on right-to-left design covers the broader question; for performance specifically, load fonts deliberately rather than by default.
Animations that move things. Google notes that pages animating any property which can affect layout are 15 per cent less likely to have good layout shift scores [6]. Animating position or size causes reflow; animating a transform does not.
The free improvement most sites are missing
The back and forward cache keeps a page in memory when somebody navigates away, so pressing back restores it instantly rather than reloading it.
Google describes its introduction as responsible for the single biggest improvement in layout shift scores in the year it arrived [6], which makes sense: a restored page does no loading, so it does no shifting.
Certain code patterns prevent a page from being eligible, and most site owners have no idea whether theirs qualifies. Chrome's developer tools can tell you and will name the reason if not.
This is worth checking because it is a genuinely large improvement requiring no design change, and it benefits every returning visitor rather than only new ones.
The order to fix things in
Do not attempt everything. The gains are concentrated.
First, find out which measure you are failing, on which pages, using Search Console. There is no point optimising responsiveness if your problem is loading.
If loading is the problem, go straight to the main image on your most important page. Is it larger than it needs to be? Is it referenced in the page itself rather than hidden in JavaScript? Is it accidentally lazy-loaded? Those three checks take twenty minutes and address the most common failure on the most common page type.
Then consider a content delivery network, particularly if your hosting is far from your visitors.
If responsiveness is the problem, audit what is running and remove what nobody uses. This is usually the single largest win and it requires no development skill to identify, only authority to remove things.
If layout shift is the problem, add dimensions to images. Then look at fonts and embeds.
Then check back and forward cache eligibility, which is a small check with a large payoff.
On realistic expectations: on a site that has never been looked at, improvements are substantial, because the common problems are large and the fixes are standard. On a site already worked on, gains get smaller and more expensive. The first day of work usually delivers more than the following two weeks, which is an argument for starting rather than planning.
This is a fix, not a redesign
Worth saying clearly, because performance is frequently used to justify a rebuild that was wanted for other reasons.
Image handling, script removal, dimension attributes and caching are all changes within an existing site. None of them requires starting again.
A redesign can actually make performance worse, because a heavier theme and larger images undo whatever was gained. Our guide on website redesign covers measuring your current scores before a rebuild and treating them as a target the new site must beat.
If somebody proposes a rebuild on speed grounds, ask what specifically they would do differently. If the answer is a list of the fixes above, those can be applied to the site you already have.
Similarly, hosting is not usually the answer on its own. Hosting affects the time before anything arrives. It does nothing about images, scripts or layout shift. Upgrading a plan when the real problem is a four-megabyte image is a common and expensive misdiagnosis.
Where it goes wrong on the common platforms
The three measures are universal, but the causes cluster differently depending on what your site is built on. Knowing the pattern for your platform shortens the diagnosis considerably.
On WordPress, the usual cause is accumulation. Plugins are easy to install and nobody ever removes them, so a site that has been running for four years is frequently carrying a dozen that each add scripts and stylesheets to every page, including pages that do not use the plugin at all. Page builders compound this, because they load their entire framework everywhere regardless of what the page contains. The productive first move is not a caching plugin, which is what usually gets installed. It is a list of active plugins with a decision on each one about whether anybody still needs it.
On Shopify and similar hosted platforms, the platform itself is fast and the theme and apps are where the weight is. Each app installed adds code to the storefront, and uninstalling an app does not always remove the code it injected, which is worth checking directly rather than assuming. Themes vary enormously: two shops on the same platform selling the same products can differ by several seconds purely on theme choice. Product images uploaded at full resolution are the other reliable culprit, because merchandising teams upload what the photographer sent.
On custom builds, the problems are usually the opposite. Fewer third-party additions, but heavier application code, and frequently a page that renders nothing until a large bundle of JavaScript has downloaded and executed. That produces the specific pattern of a page that scores acceptably on loading in a laboratory test and badly in the field, because a real phone takes much longer to execute the same code than a test machine does. The fix here is code splitting and rendering the important content without waiting for the full bundle, which is development work rather than configuration.
Across all three, the single most common shared cause remains images that nobody resized. It is worth saying twice because it is that consistent across platforms, budgets and industries, and because it is the one thing a non-technical owner can check and largely fix without waiting for anybody.
What to ask whoever maintains your site
If you are not going to do this yourself, the quality of the conversation matters more than the technical detail. Four questions get you most of the way.
"What do our Core Web Vitals look like in Search Console, and which pages are failing?" This is the diagnostic question, and the answer tells you a great deal about who you are dealing with. Somebody who maintains websites professionally can answer it within a day. An answer in terms of a PageSpeed score out of 100 rather than the three measures suggests they are working from a laboratory test rather than real visits.
"What is the largest element on our main landing page, and how big is it?" Specific, checkable, and it goes straight to the most common problem. If the answer is a two-megabyte image, you have found the work.
"What third-party scripts are running, and does anybody still use each one?" This one frequently produces a list nobody has looked at in years. The follow-up matters more than the list: who has the authority to remove things from it.
"If we fix this, what stops it coming back in a year?" The answer should involve a limit and a recurring check rather than a promise to be careful. If there is no answer, you now know that whatever you pay for will decay, and you can decide accordingly.
Ask for the work to be quoted as specific changes with expected effect rather than as an open-ended optimisation retainer. Performance work has a clear shape: this image, that script, these dimensions. A quote that cannot name what will change is a quote for time rather than for an outcome. Our guide on writing a software brief covers the same principle applied more broadly.
Mobile first, genuinely
For most UAE businesses, mobile is where this matters.
Mobile devices have less processing power and more variable connections, so the same page performs worse on them, and Google's measurement reflects real conditions rather than ideal ones.
Check your own analytics for the split. If mobile dominates, test and optimise for mobile rather than testing on a desktop and assuming it transfers. It does not: the responsiveness measure in particular is much harsher on a mid-range phone than on a laptop.
Stopping it coming back
This is the part almost everybody skips, and it is why performance work has a reputation for not lasting.
Sites get slow again one tag at a time. A campaign adds a pixel. A new feature adds a library. Somebody uploads an image straight from a camera. Each is individually small and individually defensible, and after a year the site is where it started.
Two things prevent it.
A performance budget. A stated limit that any change must respect: a maximum page weight, or a target loading time. Without one, pages get heavier through a series of reasonable decisions and nobody is accountable for the accumulation. With one, the conversation changes from "can we add this" to "what comes off to make room".
A monthly check. Search Console, five minutes, attached to whatever monthly review already happens rather than as a new process. The purpose is noticing a decline while it is small.
And an owner. Site speed sits between marketing, who add tags and images, and development, who build pages. When nobody owns it, each side reasonably assumes the other is watching. Give it to whoever owns the website commercially, along with the monthly check as a standing task.
What to do today
Open Search Console and look at the Core Web Vitals report. Then run PageSpeed Insights on your homepage and your single most important landing page.
Fifteen minutes, no cost, no setup beyond an account you probably already have, and at the end of it you know which of the three measures you are failing, on which pages, and roughly why. That is the only useful starting point, and it is a genuinely different conversation from "the site feels slow".
If you want help afterwards, a focused performance review covering what is actually slow, why, and what to change in what order starts from around AED 2,500 with us. Implementing the changes is priced by scope and is frequently smaller than owners expect, because the common fixes are standard rather than bespoke. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- web.dev, Web Vitals
- Google Search Central, understanding Core Web Vitals and Google search results
- web.dev, how the Core Web Vitals metrics thresholds were defined
- Google, about PageSpeed Insights
- web.dev, why lab and field data can be different
- web.dev, the most effective ways to improve Core Web Vitals
- web.dev, optimise Core Web Vitals for business decision makers
- SKIMBOX, best web hosting in the UAE
- SKIMBOX, website redesign in Dubai
- SKIMBOX, right-to-left website design for Arabic
- SKIMBOX, life after third-party cookies
Thresholds and measurement methods are published by Google and are revised occasionally; the statistics quoted are from Google's own analysis of the web and reflect the period of that analysis. Check the linked pages for current figures.
