Website Speed: Why It Matters and How to Improve It

Website speed decides whether a visitor stays long enough to see your offer or leaves before the page finishes loading, and it's part of the page experience signals Google takes into account. To improve website speed, don't start by installing a plugin or buying pricier hosting. Start by measuring: find where the time goes, then fix the biggest causes first, which on most sites are images, scripts, fonts and server response. This article covers the metrics that matter, how to measure them, and what to fix in what order.

Why speed matters

A visitor who taps your ad or a search result gives you a few seconds before deciding. If the screen stays blank, the button jumps from under their finger, or the menu ignores their tap, they may head back to the results and pick a competitor. A slow page therefore wastes part of your ad budget before anyone sees the offer, which is why landing pages deserve special care, as measuring campaign results explains.

Think about your real audience's conditions too. Many visitors browse on mid-range phones, on mobile data whose quality varies from place to place, and sometimes from a server that is geographically far away. A site that feels fast on an office desktop with a wired connection can be painfully slow on a phone in a car.

As for search, Google counts the Core Web Vitals among its page experience signals. But speed alone won't lift a thin page above a more useful one; think of it as a condition for not losing the visitors you already have, not a ranking trick. The other technical factors are in technical SEO basics.

The Core Web Vitals

Google defines three metrics that reflect what visitors actually experience:

• LCP (Largest Contentful Paint): the time until the largest visible element on the first screen renders, usually the hero image or main heading. It answers "when does the visitor see the important content?"
• INP (Interaction to Next Paint): how quickly the page responds to interactions such as clicks, taps and typing, throughout the whole visit. It replaced an older metric called FID and answers "does the page respond when I touch it?"
• CLS (Cumulative Layout Shift): how much page elements move unexpectedly while loading. It answers "does the page stay still or does it jump?"

A page is assessed at the 75th percentile of its visits, meaning at least three quarters of visits should fall within the "good" range, and mobile and desktop are assessed separately. In practice, it isn't enough for the page to be fast on your new phone; what matters is the experience of most of your visitors.

How to measure: lab data and real-user data

There are two kinds of measurement, and each has a job:

• Field data (real users): collected from real visitors' browsers over the previous 28 days, and shown in PageSpeed Insights and in the Core Web Vitals report inside Google Search Console. It's the true reference, but it needs enough traffic, so a new or small site may not have any yet.
• Lab data: a simulated test on a set device and network, provided by Lighthouse in Chrome's developer tools and also shown in PageSpeed Insights. It's useful for diagnosing causes and trying fixes immediately. Because the test involves no real interaction, it can't measure INP directly and shows a related metric, Total Blocking Time (TBT), instead.

Measure templates, not just the home page: the home page, a service or product page, an ad landing page, and an article page if you publish content. Read the diagnostics section of the report, which names the specific image or script responsible. And don't chase a Lighthouse score of 100; the score is a useful lab indicator, but the goal is the visitor's experience.

Images: the biggest and quickest win

Images are one of the most common causes of slow business sites and stores, and fixing them doesn't require rebuilding anything:

• The right size: a 4,000-pixel camera photo has no place in a slot 800 pixels wide. Export images at roughly the size they're displayed, plus a double-size version for high-density screens.
• Modern formats: WebP and AVIF usually produce smaller files than JPEG and PNG at similar quality. Check browser support for your audience, or provide a fallback with the picture element.
• Compression: a medium-to-high export quality is usually enough for photos with no visible difference. Compare for yourself before settling on a setting.
• Responsive images: the srcset and sizes attributes let the browser pick the right file for the screen, so a phone doesn't download the desktop image.
• Lazy loading: setting the loading attribute to lazy defers images far below the first screen until the visitor scrolls near them. Don't apply it to the hero image at the top of the page, though: it's usually the LCP element itself, and delaying it slows LCP down.
• Priority: give the hero image high priority with the fetchpriority attribute, and set width and height on every image to prevent layout jumps.

<img src="hero-800.webp"
     srcset="hero-800.webp 800w, hero-1600.webp 1600w"
     sizes="(max-width: 800px) 100vw, 800px"
     width="800" height="450" fetchpriority="high"
     alt="Our team on the project site">

<img src="project-1.webp" width="600" height="400" loading="lazy"
     alt="Building facade after completion">

Video has its own rules. Avoid heavy autoplaying background video on the first screen on mobile, and use a poster image. If you embed a video from an external platform, show a thumbnail and load the full player only when it's clicked, because an embedded player pulls in a lot of script even if nobody presses play.

Fonts: beauty with a price tag

Every font family and weight is a separate file to download, and many Arabic fonts carry several forms for each letter, so their files can be larger than Latin equivalents. Practical rules:

• Stick to two families at most, and only the weights you actually use, such as regular and bold.
• Use WOFF2, the most compressed web font format.
• Show text immediately in a fallback font while the web font loads, using font-display set to swap.
• Preload only the main font that appears on the first screen, not every font.
• Subset the font file to the characters you need, if the font license allows it.
• Choose a fallback font close in size to your main font so text doesn't jump when the font swaps in.

Scripts and third-party tools

JavaScript is the usual culprit behind a poor INP. The browser runs scripts on a single main thread, and while the page is busy with a long task (any task over 50 milliseconds) the visitor's tap has to wait its turn. The usual heavyweights on business sites:

• Live chat widgets, ad pixels for several platforms, session recording and heatmap tools, and A/B testing tools.
• CMS plugins that each load their own scripts and styles on every page, even pages that don't use them.
• Whole libraries loaded for a small job, such as an image slider or a scroll effect.

Review your script list every quarter and ask of each one: who uses its data, and is it still needed? Remove what nobody uses, load the rest with defer or async where appropriate, and delay non-essential scripts until the visitor interacts or the page has finished loading. Gathering tags into a tag manager organizes them but doesn't remove their cost. On a content management system, the number and quality of plugins has a big effect on speed, as the guide to content management systems shows.

Server, caching and compression

Before the browser can do anything, it waits for the server's first response, measured as Time to First Byte (TTFB). A slow server delays everything after it:

• Hosting quality and location: crowded hosting, or hosting far from your audience, adds delay to every request. How to choose is covered in choosing hosting, a domain and an SSL certificate.
• Page caching: on a CMS, each page is assembled from the database on every visit; page caching stores a ready-made copy and serves it instantly.
• Browser caching: the Cache-Control header tells the browser how long to keep static files. Files whose names change with every release, for example with a short hash added to the name, can safely be cached for a year.
• A content delivery network (CDN): copies static files to servers spread around the world and serves them from the point nearest the visitor. Choose one with locations close to your audience in the Gulf and Egypt.
• Compression: enabling Brotli or gzip on the server for text files such as HTML, CSS and JavaScript shrinks them considerably. Images are already compressed by their format.
• Modern protocols: make sure your hosting supports HTTP/2 or HTTP/3, which handle many files in parallel more efficiently.

Cache-Control: public, max-age=31536000, immutable

That value suits only static files whose names change with each release, not HTML pages whose content changes.

Layout stability: stopping the jumps

The causes of a high CLS are few and well known: images and embeds without reserved dimensions, ads or promo bars injected above content after it loads, and fonts that change size when they replace the fallback. The fix: reserve each element's space in advance with width and height or the aspect-ratio property, show the cookie consent banner as an overlay rather than pushing content down, and never insert new elements above what the visitor is reading unless they asked for it.

A practical improvement plan, in order

1. Measure four key templates on mobile and record LCP, INP, CLS and the lab score as a baseline.
2. Fix images: sizes, formats, lazy loading below the first screen, and priority for the hero image.
3. Remove unused scripts and plugins, and defer the rest.
4. Trim fonts and set how they display.
5. Turn on caching, compression and a CDN, or move to better hosting if server response stays slow.
6. Reserve element dimensions to stabilize the layout.
7. Measure again, and watch real-user data in Search Console over the following weeks.

To stop things sliding back, set a performance budget that everyone who adds content follows. Illustrative example: the hero image stays within a few hundred kilobytes, no new third-party tool goes live without measuring its impact, and landing page LCP stays in the "good" range on mobile.

Common mistakes

• Lazy-loading the hero image, which delays the most important element on the page.
• Installing a speed plugin on top of dozens of plugins instead of removing what isn't needed.
• A heavy image slider at the top of the page that delays the content while most visitors only ever see the first slide.
• Testing only on an office computer and judging speed on the company network.
• Uploading camera photos straight from the content team without preparing them, which undoes every optimization.
• Optimizing the day before peak season instead of preparing well ahead of Ramadan and Eid campaigns.

Practical checklist

• Know your targets: LCP up to 2.5 s, INP up to 200 ms, CLS up to 0.1, for at least three quarters of visits.
• Use PageSpeed Insights and Lighthouse to diagnose, and the Search Console report for real-user data.
• Start with images, then third-party scripts, then fonts, then the server and caching.
• Reserve dimensions for every image and embed, and never inject content above what the visitor is reading.
• Set a performance budget and re-measure after every major change or new tool.
• Remember that speed is part of the whole mobile experience; review responsive web design alongside it, and see building your business website for the full project picture.