What makes a website fast?

In five layers, and any one can bottleneck the rest:

1. Server response. How long before the server sends the first byte.
2. Page weight. The total size of HTML, CSS, JavaScript, fonts and media.
3. Images and media. Format, dimensions and when they load.
4. Caching and delivery. Whether a ready-made page is served from near the visitor.
5. Rendering. What the browser has to download and run before it can show anything.

A fast server can't rescue a page carrying 6 MB of images. Lean code can't make up for an overloaded host on another continent. Most slow sites fail at the same few points: oversized images, scripts and styles loaded on every page whether needed or not, too many third-party tools, and hosting that's shared, oversold or far from the visitor.

Time to First Byte (TTFB). Nothing starts until the first byte arrives. Google's guidance treats 0.8 seconds or less as good. Slow hosting, uncached pages and heavy database queries all push it up.

Page weight. Every kilobyte has to travel over a mobile connection. Compression (Brotli or Gzip), modern image formats (WebP, AVIF), minified CSS and JavaScript, and fewer font files all cut it.

Caching and CDN. Caching stores a ready-to-serve version of a page so the server doesn't rebuild it on every visit. A CDN serves that version from a location close to the visitor. For a UAE audience, that means a CDN with edge locations in the Gulf, not only in Europe.

Render-blocking resources. Scripts and stylesheets that must load before anything appears. Deferring non-critical JavaScript, inlining the small amount of CSS needed for the first screen, and loading fonts without blocking text all let visible content appear first.

Third-party scripts. Chat widgets, tag managers, heatmaps, review badges and ad pixels each add weight and work for the browser. They are the most common reason a site that was fast at launch is slow a year later.

Use Google's Core Web Vitals, measured on real visitors:

• Largest Contentful Paint: 2.5 seconds or less.
• Interaction to Next Paint: 200 milliseconds or less. (INP replaced First Input Delay in March 2024.)
• Cumulative Layout Shift: 0.1 or less.

All three are judged at the 75th percentile of visits. Check the field data in Search Console's Core Web Vitals report or the top of PageSpeed Insights, not just the lab score. A site can score well in Lighthouse on a fast laptop and still be slow for real people on mid-range phones.

Use these criteria:

• Fix when the problems are assets and configuration: images, caching, a few heavy scripts, hosting. These are often days of work, not weeks.
• Rebuild when the weight is in the foundations: a page builder that outputs bloated markup on every page, a theme loading scripts you can't remove, or a plugin stack where removing one thing breaks three others.
• Rebuild when you're planning a redesign anyway. Bolting speed fixes onto a site you're replacing in six months is money spent twice.

• Hero image in WebP or AVIF, sized for its slot, not lazy-loaded, and marked high priority.
• All other images lazy-loaded with width and height set.
• Page caching on, with a CDN that has edge locations near your customers.
• TTFB of 0.8 seconds or less for key pages.
• No unused CSS or JavaScript loaded site-wide.
• Third-party scripts audited: each one has an owner and a reason.
• Fonts limited to the weights you use, loaded without blocking text.
• Key templates tested on a throttled mobile profile before every major release.

• Buying faster hosting first. It raises the ceiling but rarely fixes a heavy page.
• Installing a speed plugin on top of 30 other plugins. You're adding code to remove code.
• Lazy-loading the hero image. It delays the very element LCP measures.
• Uploading photos straight from the camera. A 5 MB image displayed at 400 pixels wide is wasted mobile data.
• Letting marketing tools pile up. Every pixel, widget and heatmap slows every visit, including the ones that would have converted.
• Testing only the homepage. Your service, listing and booking pages are where speed costs money.

A hypothetical example. Say you run an online furniture store. Product pages take five seconds to show the main image on mobile. The store uses a popular theme with a page builder, 28 plugins, a live chat widget, three tracking pixels and uncompressed product photos uploaded from the supplier.

A sensible order of work:

1. Convert product images to WebP, resize them for their slots, and preload the main product image.
2. Remove plugins that duplicate each other or are no longer used, and stop site-wide loading of scripts only needed at checkout.
3. Delay the chat widget until the visitor interacts or scrolls, and move tracking to server-side where possible.
4. Turn on full-page caching and a CDN with Gulf edge locations.
5. Re-test field data over the following four weeks.

If the page builder's markup is still the bottleneck after all that, that's the point to plan a rebuild, with evidence rather than a hunch.

We set a performance budget at the start of a build: a maximum page weight, a limit on third-party scripts, and target Core Web Vitals for each key template. Design works inside that budget. We choose hosting and CDN for where your customers are, and test on mid-range phone profiles, not just desktop.

We also look at what the scripts on your site are for. Often a chat widget, form plugin or tracking tool is doing a job that can run behind the scenes instead, for example sending form submissions straight to your CRM through an automation. The site gets lighter and the follow-up gets faster.