Website speed is one of those topics where store owners hear two extreme stories. One says a slow store is invisible on Google. The other says speed barely matters as long as the products are good. Neither is accurate, and acting on either one wastes money.
This guide gives you the version that holds up. You will learn what Google actually measures (the three Core Web Vitals and their official thresholds), how to check website speed with Google’s free tools, which fixes give the biggest wins on Salla, Zid and Shopify stores, and how much page speed really affects SEO, in Google’s own words.
Every threshold and quote below comes from official Google pages (web.dev, Google Search Central and Search Console Help) or platform help centres, as checked in October 2026. These pages are updated from time to time, so follow the links before making a big decision.
Why website speed matters for an online store
A shopper who taps an ad or a search result expects to see the product almost immediately. Every second of blank screen is a chance to change their mind and swipe back to Instagram or Snapchat. The longer and slower the path from landing page to checkout, the more places people drop out.
You will not find a “you lose X% per second” figure in this article. Those numbers vary hugely between stores and categories, and there is no official figure that applies to your store. What decides the real cost of a slow page is your traffic source, your visitors’ devices, your price point, and how committed visitors already are to your brand.
What Shopify says on its own help pages is useful here: optimising web performance “can enhance your customers’ shopping experience” and supports discoverability and conversion. In general terms, we usually see the same pattern: slow stores lose part of their paid traffic before a single product view is recorded.
Website speed and your ad spend
If you run Snapchat, TikTok or Google Ads, you pay for the click whether or not the page loads in time. Poor website speed on a landing page quietly raises your real cost per sale. That is why it helps to look at speed alongside your true return, as explained in our guide to ROAS.
Slow checkout pages are also a common reason for abandoned carts. If your abandonment rate is high, read our abandoned cart recovery guide as well, because speed is only one part of that problem.
Core Web Vitals: Google’s official thresholds
Google measures page experience, including website speed, with three core metrics. Each one answers a question your visitor asks without thinking about it: has the content appeared, did the page react when I tapped, and did things jump around under my thumb?
LCP: how fast does the main content appear?
Largest Contentful Paint measures the time until the largest visible element in the first screen has rendered. On a store, that is usually the hero banner or the main product photo. According to web.dev, LCP should occur within 2.5 seconds of the page starting to load.
INP: how quickly does the page respond?
Interaction to Next Paint measures how quickly the page responds to taps, clicks and key presses throughout the visit, such as “Add to cart” or opening the size selector. The official target is 200 milliseconds or less. INP became a stable Core Web Vital in 2024, replacing First Input Delay (FID).
CLS: does the layout stay still?
Cumulative Layout Shift measures unexpected movement of elements on the page. The classic example: you reach for the “Buy now” button and it drops down because a promo bar loaded above it. The official target is 0.1 or less.
The official thresholds in one table
These ranges come from Google’s PageSpeed Insights documentation (October 2026). They are assessed at the 75th percentile of real visits, with mobile and desktop reported separately:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (loading) | up to 2.5 s | 2.5 s to 4 s | over 4 s |
| INP (responsiveness) | up to 200 ms | 200 ms to 500 ms | over 500 ms |
| CLS (visual stability) | up to 0.1 | 0.1 to 0.25 | over 0.25 |
The 75th percentile means at least three quarters of page visits need a “good” experience. A page passes the assessment only when all three metrics meet that bar, as described on the Web Vitals page on web.dev.
How to check website speed with Google’s tools
Before you change anything, you need a website speed baseline: a measurement you can return to after every fix. The best tools to start with are free and come from Google: PageSpeed Insights for individual pages and the Core Web Vitals report in Search Console for the whole site.
Running a website speed test in PageSpeed Insights
- Open PageSpeed Insights and paste the full URL of the page, not just your domain.
- Test at least three templates: the home page, a busy collection or category page, and a best-selling product page.
- Start with the mobile tab. It is the closest match to how most Gulf shoppers will see your store.
- Read the top section first: is there real-user data, and does the page pass the Core Web Vitals assessment?
- Then look at the diagnostics, especially which element is flagged as the LCP element, and at the suggested opportunities.
- Record the results in a simple sheet with the date, so you compare against numbers rather than memory.
Field data vs lab data
This is where most people get confused. PageSpeed Insights shows two kinds of data, and the PageSpeed Insights documentation explains that each has a different job:
| Aspect | Field data | Lab data |
|---|---|---|
| Source | Chrome User Experience Report (CrUX), real visitors | Lighthouse simulation on a set device and network |
| Time period | Previous 28 days | The moment you ran the test |
| Best for | Judging the website speed your visitors actually experience | Debugging and testing website speed fixes |
| How quickly it changes | Slowly, it is a rolling month | Instantly, every run |
The score out of 100 that everyone screenshots is the lab Performance score. Per the same documentation, 90 or above is good, 50 to 89 needs improvement, and below 50 is poor. It is a diagnostic, not what your shoppers live through, so do not make it your only target.
The Core Web Vitals report in Search Console
If your store is verified in Search Console, the Core Web Vitals report shows field data from CrUX across the site. According to Search Console Help, it groups similar URLs together, labels each group Good, Need improvement or Poor based on its worst metric, and reports mobile and desktop separately.
After a fix, click Start Tracking to begin a 28-day monitoring session. If you see no data at all, do not panic. Groups without enough real-user data are left out, which is common for new or low-traffic stores. Use lab data in the meantime.
How to improve website speed: the biggest wins for stores
Do not try to fix every item PageSpeed Insights lists at once; website speed work pays off fastest when you start with the heaviest causes. On most online stores, the bulk of the slowness comes from a short list of causes: images, apps and scripts, fonts, and hosting. Work through them in that order.
1. Images: WebP and the right sizes
Images are where most stores can improve website speed fastest. Google’s image SEO guidelines note that images are often the largest contributor to page size. Google Search supports WebP and AVIF, so there is no reason to upload heavy PNG files of photographed products.
- Upload images close to the size they are displayed at, not straight from the camera.
- Use WebP or AVIF for photos, with sensible compression that keeps product detail.
- Do not lazy-load the hero banner or main product photo. That is usually your LCP element. Use loading=”lazy” only for images below the first screen.
- Always set width and height on images so the browser reserves the space and the layout does not jump.
- Cut the home page slider down. One strong banner is faster than six heavy slides.
web.dev also suggests fetchpriority=”high” on the likely LCP image, but only on one or two images, because overusing it cancels the effect.
2. Website speed on Salla, Zid and Shopify: apps and scripts
Every app you add, from discount pop-ups and spin wheels to reviews widgets and live chat, may add scripts the browser must download and run. That can hurt LCP and INP at the same time.
The Shopify help page on improving performance is direct about it: review your installed apps and remove any that are not essential for sales. It also warns that uninstalling an app does not automatically remove its code from your theme. The same principle applies on Salla and Zid: every add-on that shows something on the storefront has a performance cost.
- List every app that is visible to shoppers and ask whether it drove real sales in the last 90 days.
- Audit your tag manager and remove duplicate or unused pixels and tags.
- Do not run two chat tools or two pop-up tools at the same time.
- After removing an app, test the page again to confirm its code has gone from the theme.
Tracking pixels matter and we are not asking you to remove them. But the same pixel firing twice through two different apps is common, and it slows the page while distorting your numbers. Setting tracking up properly is a separate topic, covered in our conversion tracking guide.
3. Fonts: a hidden website speed cost for Arabic stores
Arabic fonts are usually heavier than Latin ones because they carry more letter forms, and bilingual stores often load two families in several weights each. The web.dev font best practices recommend:
- Use WOFF2 only.
- Limit the number of families and weights. Two weights of one family is enough for most stores.
- Use font-display so text appears quickly instead of staying invisible.
- Preload only the most important font, not every font.
- Subset fonts so the browser downloads only the characters the page needs.
As web.dev puts it, the fastest font to deliver is a font that is not requested in the first place.
4. Hosting, time to first byte and website speed
Time to First Byte (TTFB) is how long the browser waits for the first byte of the page. web.dev suggests most sites should aim for 0.8 seconds or less. TTFB is not a Core Web Vital, but it adds directly to LCP.
On hosted platforms such as Salla, Zid and Shopify, hosting is largely handled by the platform, so your levers are the theme, apps and images. On WordPress or a custom build, cheap shared hosting is a common cause of slowness, as the web.dev guide to optimising TTFB points out.
Also avoid redirect chains, such as http to https to www to a trailing-slash URL. Each hop adds time before the real load even starts. Give advertisers and newsletter tools the final URL directly.
5. Caching and a CDN for better website speed
A content delivery network (CDN) keeps copies of your files on servers closer to your visitors. If your server is in Europe and your customers are in Riyadh and Dubai, distance alone adds time. web.dev notes that users far from your origin server may still see high TTFB in the field even if the server itself is quick.
- Cache static files (images, fonts, CSS and JS) for a long time.
- Cache public HTML pages at the edge where you can, even briefly.
- Never cache personal pages such as the cart or customer account.
- When testing, remember that caching can hide a slow backend, so also test with the cache bypassed.
6. Layout stability: stop the jumping
CLS problems on stores are repetitive: images without dimensions, a promo bar that appears after load, banners that push content down, and fonts that swap after the text has shown. The fix, according to the web.dev guide to CLS, is to reserve space in advance for anything that loads late, and to show notices over the content rather than inside it.
7. Responsiveness to taps
If the page appears quickly but “Add to cart” lags, the problem is INP. The most common cause is too much JavaScript keeping the browser busy, and on stores most of it comes from third-party apps. That is why the app clean-up in step 2 often improves INP more than any other change.
Website speed optimization by platform: what you control
Where your responsibility starts and ends depends on the platform. Treat this as a general guide; platform features change, so check your platform’s help centre before editing anything:
| Area | Salla and Zid | Shopify | WordPress or custom |
|---|---|---|---|
| Hosting and CDN | Mostly handled by the platform | Handled by the platform | Fully your responsibility |
| Theme | Choose and customise within platform options | Choose a theme and edit its code | Full control |
| Apps and plugins | From the platform’s app store | From the Shopify App Store | Plugins or custom code |
| Images | Your job: size and format on upload | Your job: size and format on upload | Fully your job |
| Fonts | Within theme settings | Theme settings or code | Full control |
If you are still choosing a platform, our Salla vs Zid vs Shopify comparison covers the wider decision. Speed is one factor there, not the only one.
Mobile first: what this means in the Gulf
In general terms, a large share of store traffic in the UAE, Saudi Arabia and Kuwait arrives on phones, especially from Snapchat, TikTok and Instagram ads. Google also works from your mobile site. Its mobile-first indexing documentation says: “Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.”
Practical website speed tips for Gulf stores
- Test website speed on a mid-range phone, not your newest one. Your customers do not all carry flagship devices.
- Run a website speed check several weeks before Ramadan, White Friday and national day campaigns, not on launch day.
- Seasonal campaigns add banners, countdown timers and offer pop-ups. Measure their impact before they go live.
- If your store runs in Arabic and English, do not load both full font sets on every page.
- If you sell through WhatsApp marketing, make sure the links you send open a light page directly, not a chain of redirects.
If your business also depends on local SEO and Google Maps, fast mobile pages matter there too, because those visitors are almost always on a phone and in a hurry.
How much does page speed affect SEO?
This is where the hype is loudest. Here is the accurate picture from Google’s page experience documentation on Search Central:
- Google says “Core Web Vitals are used by our ranking systems.”
- It also says: “There is no single signal” for page experience.
- It states that Google Search “always seeks to show the most relevant content, even if the page experience is sub-par.”
- And it advises site owners not to focus on only one or two aspects of page experience.
The takeaway: website speed is one signal among many. A fast page with thin content will not beat a slightly slower page that answers the searcher better. But between two pages of similar relevance and quality, the better experience is a real advantage, on top of its direct effect on conversion.
So treat speed as part of the technical phase of your SEO plan, not the whole plan. For the full sequence, from technical fixes to category pages and then content, see our 90-day e-commerce SEO plan. If you are comparing agency quotes, SEO cost is a separate question we cover elsewhere.
Common website speed mistakes and how to fix them
Chasing a perfect 100
The mistake: spending weeks pushing the lab score from 85 to 100. The fix: focus on passing all three metrics in field data for the pages that sell, then move on to content and conversion.
Testing only the home page
The mistake: judging the whole store’s website speed by its home page. The fix: most ad and search traffic lands on product and category pages, so test those first.
Adding an app for every problem
The mistake: solving each issue with another app, including “speed booster” apps. The fix: every app must justify itself with sales or data you actually use.
Lazy-loading the hero image
The mistake: turning on lazy loading for every image. The fix: exclude the first-screen image, because lazy-loading it directly hurts LCP, as the web.dev LCP guide explains.
Measuring once and forgetting
The mistake: treating website speed as a one-off job at launch. The fix: every new theme, app or seasonal campaign can slow the store. Measure monthly and before every big season.
Website speed checklist
- Tested the home, category and product pages in PageSpeed Insights on mobile.
- Recorded field results for LCP, INP and CLS with the date.
- Reviewed the Search Console Core Web Vitals report for mobile and desktop.
- Converted product photos and banners to WebP at their display sizes.
- Excluded the first-screen image from lazy loading.
- Set dimensions on all images and banners and reserved space for late elements.
- Removed unnecessary apps and confirmed their code is gone, often the biggest single website speed gain.
- Cleaned duplicate pixels out of the tag manager.
- Reduced fonts to one family in two weights, in WOFF2.
- Checked ad links for redirect chains.
- Enabled caching and a CDN if the site is self-hosted.
- Scheduled a test several weeks before Ramadan and White Friday.
Start with the pages that sell, with mobile, and with field data. A green lab score is a diagnostic tool, not the goal.
Conclusion
For most stores, improving website speed is not a technical miracle. It is measurement and discipline: lighter images, fewer apps, simpler fonts and suitable hosting. Speed serves sales first and SEO second, as one signal among many. If you want a full review of your store’s performance and design, see our web design and development service or get in touch.
FAQ
How do I check website speed for free?
Open PageSpeed Insights at pagespeed.web.dev, paste the page URL and choose the mobile tab. Real-user data appears at the top when Google has enough of it, with lab results and suggestions below. To monitor the whole site, use the Core Web Vitals report in Search Console.
What is a good page load speed?
Using Google’s official thresholds as of October 2026: the largest element (LCP) should appear within 2.5 seconds, interactions (INP) should respond in 200 milliseconds or less, and layout shift (CLS) should stay at 0.1 or less, for at least three quarters of visits.
What is the best website speed test tool?
Start with Google’s own tools: PageSpeed Insights for quick checks and debugging, and Search Console for site-wide field data. Chrome DevTools helps with deeper debugging. For website speed, the best tool is the one you use regularly and compare over time.
Why does my website speed score change every time I test?
Lab data is measured in a single run and is affected by server and network conditions at that moment. Run several tests and look at the overall picture. Field data covers the previous 28 days, so it changes slowly.
How much does page speed affect SEO?
Less than many people claim. Google says Core Web Vitals are used by its ranking systems, but also that there is no single signal and that the most relevant content is shown even when page experience is sub-par. Good website speed helps when your content is already strong.
Why is the Core Web Vitals report empty in Search Console?
Usually because the site is new or traffic is too low to build CrUX data. According to Search Console Help, groups without enough data are left out of the report. Use lab data in PageSpeed Insights until traffic builds up.
Do I need a developer to improve website speed on Salla, Zid or Shopify?
Much of the work needs no code: compressing images, removing unnecessary apps, simplifying the home page and trimming fonts. Editing theme code, cleaning up leftover app code, or tuning hosting on a self-hosted site is where a developer helps.
