How to Improve Website Speed

Most slow websites are slow for a handful of ordinary reasons: oversized images, too many third-party scripts, heavy fonts, bloated plugins and hosting that is far from your visitors. To improve website speed, measure first, fix the biggest problem on your most important pages, then work down a short list.

Measure before you change anything

Run your homepage and two or three commercially important pages, such as a key service page and your contact page, through Google’s PageSpeed Insights. Look at the mobile results first. Phones have less processing power than laptops and patchier connections, so mobile is the tougher test.

Field data and lab data

PageSpeed Insights shows two kinds of result.

• Field data comes from the Chrome UX Report: real Chrome users visiting your site over a rolling 28-day period. This is what Google uses to assess Core Web Vitals. Smaller sites may not have enough traffic for field data to appear.
• Lab data comes from Lighthouse, a simulated test on one device and connection. It is good for diagnosing problems and checking a fix straight away, but scores vary between runs.

Don’t chase a lab score of 100. Use the lab report to find problems and the field data to judge progress, bearing in mind that field data takes weeks to reflect a fix.

The three Core Web Vitals

Metric	What it measures	“Good” threshold
Largest Contentful Paint (LCP)	How quickly the main content, often the hero image or headline, appears	2.5 seconds or less
Interaction to Next Paint (INP)	How quickly the page responds to taps, clicks and key presses	200 milliseconds or less
Cumulative Layout Shift (CLS)	How much the layout jumps around while the page loads	0.1 or less

Google assesses each metric at the 75th percentile, so at least three out of four real visits need to fall within the “good” threshold. The metrics are explained in detail on web.dev.

Fix your images first

Images are usually the heaviest part of a page, which makes them the quickest win.

• Use modern formats. AVIF and WebP files are much smaller than JPEG or PNG at similar visual quality, and current versions of the major browsers support both.
• Size images for where they appear. A 5,000-pixel photo straight from a property shoot does not belong in a 400-pixel card. Export at sensible dimensions, compress, and use srcset and sizes so phones download a smaller file than large desktop screens.
• Lazy-load images below the fold. Add loading="lazy" so images further down only load as a visitor scrolls towards them.
• Prioritise the hero image. Never lazy-load the large image at the top of the page. Make it a real <img> element in the HTML (not a background added later by a script) and add fetchpriority="high" so the browser requests it early. This can make a noticeable difference to LCP.
• Always set width and height, or a CSS aspect-ratio, so the browser reserves space before the image arrives.

Video needs the same care. Compress hero videos heavily and give them a poster image. For YouTube or Vimeo embeds, show a thumbnail and only load the player when someone taps play.

Load fonts carefully

Every font weight and style is a separate file. A bilingual site with English and Arabic families in several weights can easily download more font data than it needs.

• Use only the weights you actually use, often regular, semi-bold and bold.
• Serve fonts as WOFF2 and host them yourself where the licence allows.
• Use unicode-range or separate files so English pages don’t download Arabic glyphs, and the other way round.
• Add font-display: swap so text appears straight away in a fallback font, and choose a fallback with similar proportions to limit the shift when your font loads.
• Preload only the one or two fonts used above the fold.

Audit third-party scripts and chat widgets

Analytics, tag managers, heatmaps, ad pixels, review widgets, booking tools and live chat all have to be downloaded and run on your visitor’s phone. They are a common cause of poor INP, because they keep the browser busy when someone taps.

List everything that loads, using your browser’s developer tools or the PageSpeed Insights report, and ask of each item who uses it and when they last looked at the data. Then:

• Remove pixels and tools left over from old campaigns and free trials.
• Load non-essential scripts with defer, or after the page has finished loading.
• Review your tag manager, where old tags quietly pile up.
• Load chat widgets only when someone taps the chat button. If your customers prefer WhatsApp anyway, a plain click-to-chat link may do the same job at almost no cost to speed.

Check hosting, CDN and caching

If your server is slow to respond, everything else waits, so check the server response time, often shown as Time to First Byte (TTFB).

• Location matters. If your customers are in the UAE and your server is on another continent, every request travels further. Host closer to your audience, or use a content delivery network (CDN) to serve files from locations nearer to visitors.
• Cache pages so the server doesn’t rebuild every page for every visitor.
• Cache static files in the browser. Give images, CSS and JavaScript long cache lifetimes, with versioned file names so updates still reach people.
• Turn on compression (Brotli or gzip), and make sure your host supports HTTP/2 or HTTP/3.

WordPress: watch the plugins

WordPress can be fast, but it is easy to slow down. The number of plugins matters less than what each one loads. Common culprits include:

• Plugins doing overlapping jobs, such as two SEO plugins or three slider plugins.
• Heavy page builders that load large CSS and JavaScript files on every page.
• Plugins that load their assets sitewide when they are only needed on one page.
• An out-of-date theme or PHP version.

Use one well-configured caching setup, delete deactivated plugins and test speed after adding any new one. Our guide to WordPress vs custom website development covers the wider trade-offs.

Reduce JavaScript weight

JavaScript is expensive on phones. It has to be downloaded, parsed and executed, and while the browser is busy running it, the page can’t respond to taps.

• Remove libraries nothing uses any more, and animation libraries added for a single effect.
• Question sliders and carousels. They are often heavy, and anything after the first slide is easy to miss.
• Split code so each page loads only what it needs.
• Break long-running scripts into smaller tasks so the page stays responsive.

Stop the layout from jumping

Layout shift is when content moves after it first appears, so people tap the wrong thing or lose their place. The usual causes are:

• Images, videos and iframes without dimensions.
• Cookie notices, promotion bars or brochure banners that push the page down after it loads. Show them as overlays, or reserve the space from the start.
• Embedded maps, social posts and review widgets that resize once they load.
• Web fonts that swap in with very different proportions from the fallback.

A prioritised checklist

1. Test your key pages on mobile in PageSpeed Insights and note LCP, INP and CLS.
2. Make the hero image a properly sized AVIF or WebP <img> with fetchpriority="high" and no lazy loading.
3. Resize, convert and compress other images, and lazy-load those below the fold.
4. Remove unused third-party scripts and delay the rest, including chat widgets.
5. Check server response time, and set up page caching, compression and a CDN.
6. On WordPress, remove overlapping plugins and update PHP and your theme.
7. Trim fonts to the weights and character sets you use.
8. Cut and defer JavaScript.
9. Reserve space for banners, embeds and anything else that loads late.
10. Re-test, then check field data again over the following weeks.

If every fix feels like fighting the theme or page builder, the platform itself may be the problem, and it is worth reading about when to redesign your website.

Next steps

If your site is slow and you’d like help, our website development page explains how we build with performance in mind. You can also send us your site address and we’ll tell you where we would start.