Website speed and Core Web Vitals for Kuwait businesses

Most visits to a Kuwaiti business website arrive on a phone, often from an Instagram story or a WhatsApp link, frequently on mobile data in a car or a mall. If the page takes five seconds to show anything, a good share of those people are gone before your brand appears. That is the whole argument for speed, and it is a commercial argument before it is a technical one.

It is also a paid media argument. If you spend on ads and send that traffic to a slow page, you are paying full price for visits that never see the offer. Speed work is one of the few things that improves organic search, paid performance and the customer's impression of the brand at the same time.

Here is what the measurements mean in plain words, what usually causes the problem, how to measure it honestly, and what a realistic fix plan looks like.

Core Web Vitals without the jargon

Google publishes three metrics that describe how a page feels to a real person. They are worth knowing because they name the three ways a page annoys someone.

• Largest Contentful Paint. How long until the main thing on the screen appears, usually the hero image or the headline. Under about two and a half seconds is considered good. This is the one most Kuwaiti sites fail.
• Interaction to Next Paint. When someone taps a button or opens a menu, how long before the page visibly responds. Under about two tenths of a second is considered good. Heavy JavaScript is what breaks it.
• Cumulative Layout Shift. How much the page jumps around while loading. You know it as tapping a link and hitting an advert because the content moved. A score under about a tenth is considered good.

Two things about how these are judged. They are measured at the seventy fifth percentile, which means the metric describes your slower visits, not your average. And they are measured from real visitors, so a fast test on your office wifi proves very little.

What actually makes sites slow

After enough audits, the causes repeat. In rough order of how often we find them:

1. Images. The single biggest cause. A hero exported at four thousand pixels wide, product photos straight from a shoot, or a gallery of twenty full size images that all load at once. Serve modern formats, size images for how they are actually displayed, and load anything below the fold only when it is needed.
2. Fonts. Five weights of a Latin family plus an Arabic family, each blocking the first paint. Two weights, subset, in a modern format, with a sensible fallback while they load.
3. Third party scripts. Chat widgets, review badges, heat maps, three analytics tools, two pixels and a cookie banner. Each one is code from someone else's server that you cannot control. This is usually the fastest win available.
4. Page builders and plugin stacks. Sites assembled from a builder plus thirty plugins ship enormous amounts of CSS and JavaScript that the page never uses. Nothing is wrong with any single piece, the total is the problem.
5. Sliders and video backgrounds. A homepage carousel that autoplays four full width images is a large download for something most people never scroll past.
6. Slow server responses. Cheap shared hosting far from your audience, or no caching, so every visit is rebuilt from scratch. Serving from a CDN fixes a surprising amount of this.
7. Layout that has no reserved space. Images and embeds without dimensions, banners injected at the top, fonts that swap and reflow the page. All of it causes the page to jump.

How to measure it honestly

Two kinds of measurement exist, and confusing them is why teams argue about speed.

Lab data is a simulated test. Run your key pages through Google's PageSpeed Insights or a Lighthouse audit in Chrome, on the mobile setting. It is repeatable and it tells you what to fix, but the score is not a business metric. Do not chase a number to one hundred.

Field data is what real visitors experienced. PageSpeed Insights shows it at the top of the report when your site has enough traffic, and Search Console has a Core Web Vitals section that groups pages by problem. This is the data that reflects your actual customers, including the ones on a weak signal.

Then do the test that matters most and is skipped most often. Take a real phone, turn off wifi, open your site from a link in Instagram or WhatsApp so it opens in the in app browser, and try to buy something or send an enquiry. In app browsers behave differently from Safari and Chrome, and that is how a large share of your traffic actually arrives. Test in Arabic as well as English, since the Arabic version often carries different fonts and sometimes a different theme.

Measure a set of pages, not just the homepage. The homepage, a category or service page, a product or detail page, and the contact or checkout page. They usually have different problems, and the money is rarely on the homepage.

What a fix plan looks like

A speed project is not one job. It is a sequence, ordered by result per hour of work, and most sites see the majority of the gain in the first two steps.

Week one, the cheap wins

Compress and resize every image on the templates that matter, and serve modern formats. Set width and height on images so nothing jumps. Lazy load anything below the fold, and be careful not to lazy load the hero, which is a common mistake that makes the main metric worse. Audit third party scripts and remove what nobody reads. Cut the font stack to what the design actually uses.

Week two, the structural work

Put a CDN in front of the site and cache pages properly. Defer JavaScript that is not needed for the first screen. Replace the homepage carousel with a single strong image. Preload the hero image and the one font weight in the headline. Remove plugins whose only job is one small feature you can do without.

Then measure again, with the same tools, on the same pages

Give field data a few weeks to catch up, since it is based on a rolling window of real visits. Track enquiries and orders alongside the metrics, because that is the reason for the work. Set a check in the calendar every quarter, since sites get slower on their own as marketing tags accumulate.

When to stop fixing and rebuild

Optimisation has a floor, and some sites sit under it. Consider a rebuild when the site is a builder with dozens of plugins where every fix breaks something else, when the theme itself is unmaintained, when nobody can edit a page without a developer, when the Arabic version is a bolt on rather than a structure, or when you are heading for a redesign in the next year anyway.

The arithmetic is usually clear. If three months of optimisation costs a meaningful share of what a new site costs, and leaves you with the same brittle system, build the new one and design speed in. On a rebuild, the things that keep a site fast are decided early: a lean template, an image pipeline that resizes automatically, a strict rule about third party scripts, and a hosting setup with a CDN in front of it. It is far cheaper to hold that line from the start than to claw performance back later.

Frequently asked questions

Does site speed really affect Google rankings?

It is a factor, not the factor. Relevance and content decide most of it, and speed acts as a tiebreaker between similar pages. The bigger effect is commercial: fewer people leave, more people finish what they started.

What is a good PageSpeed score?

Aim to pass the three field metrics rather than to hit a specific score. A site that passes all three on real visits is in good shape even if the lab score is in the eighties.

Our site is fast on the office wifi. Is that enough?

No. Test on mobile data, on an older phone, through an in app browser. That is the experience most of your customers get, and it is the one the field metrics record.

How much does a speed project cost?

It depends on how the site was built. An audit with a prioritised fix list is a small piece of work. Implementation ranges from a few days on a well built site to something close to a rebuild on a heavy plugin stack, which is why the audit comes first.

We usually start with a short audit on four pages, one real phone test on mobile data, and a list ordered by what will move first. If the site is worth fixing we fix it, and if it is not we say so. Our websites and digital products work covers both paths, the Shopify side covers stores where the app stack is the cause, and if paid traffic is landing on slow pages, the performance marketing and SEO work is where that shows up in the numbers.