Website Performance Best Practices: 12 Ways to Boost Speed

Imagine clicking onto a website and waiting… and waiting only to abandon it for a faster competitor. In a digital age where attention spans are measured in seconds, website performance is not simply a technical detail; it’s a direct driver of customer trust, search visibility, and business growth. Studies consistently show that even a one-second delay in page load can dramatically increase bounce rates and erode potential revenue. For small businesses, especially those in Surrey and the surrounding UK areas, poor site speed can mean the difference between a new enquiry and a lost opportunity.

But how fast is fast enough? Industry benchmarks suggest that pages should load in under three seconds ideally closer to two. Anything slower, and you risk falling behind in both Google search rankings and user satisfaction. The good news is that boosting website speed isn’t reserved for large enterprises with dedicated IT teams. With the right knowledge and practical tools, any business can transform a sluggish site into a sleek, high-converting asset.

This article lays out a clear, actionable roadmap to help you assess, optimise, and future-proof your website’s performance. You’ll discover twelve essential best practices each explained with real-world examples, simple code snippets, and tool recommendations covering everything from initial speed testing to advanced image, code, and server optimisations. Whether you’re handling your own site or partnering with an expert like GFC Tech, these steps will empower you to deliver a faster, more engaging experience for every visitor.

Ready to see what a high-performing website can do for your business? Let’s get started.

1. Measure and Benchmark Your Website Performance

Before you can speed things up, you need a clear snapshot of current performance. Establishing a baseline helps you identify problem areas, set realistic goals and track the impact of each optimisation. A balanced approach uses both controlled lab tests which simulate standard conditions and real-user monitoring (RUM) to reveal how live visitors actually experience your pages. By combining these methods, small businesses gain a comprehensive view of site health and can avoid chasing optimisations that won’t move the needle.

Start by defining a testing cadence: run synthetic tests weekly or after major deployments, and keep RUM dashboards running continuously. Compare results against industry benchmarks—generally, sites should aim for a load time under three seconds, with core metrics like Largest Contentful Paint (LCP) at or below 2.5 s. Ongoing measurement doesn’t just catch regressions; it also uncovers trends over time, ensuring your performance remains competitive as you add new features or content.

1.1 Key Performance Indicators and Core Web Vitals

Google’s Core Web Vitals are now central to both user experience and search ranking. They cover three dimensions:

• Largest Contentful Paint (LCP): How long it takes to render the page’s largest visible element. Aim for ≤ 2.5 s.
• First Input Delay (FID): The delay before the page responds to a user’s first interaction. A good target is < 100 ms.
• Cumulative Layout Shift (CLS): A measure of unexpected layout shifts, scored as a unitless value (≤ 0.1 is ideal).

These metrics offer a shorthand for page speed and stability, and you can learn more about integrating them into a broader SEO strategy in our guide on technical SEO and Core Web Vitals. If you’re comfortable digging into specs, the W3C’s LCP spec provides a technical deep-dive. By tracking these KPIs, you set quantifiable objectives and can prioritise the fixes that will benefit both visitors and search visibility.

1.2 Using Google PageSpeed Insights and Lighthouse

Google PageSpeed Insights is the quickest way to get both lab data and an estimate of real-world performance. Just enter your URL and you’ll receive:

• A Performance score (0–100) for mobile and desktop.
• Opportunities (e.g. “Reduce unused CSS”) with estimated savings.
• Diagnostics that flag potential issues like large JavaScript bundles or inefficient fonts.

For more granular control, open Chrome DevTools and run a Lighthouse audit under the Performance panel. Lighthouse surfaces render-blocking resources, long tasks, and CPU/memory load, alongside accessibility and best-practice checks. Both tools are free, require no installation, and can even be automated via CI/CD pipelines to enforce performance budgets on every build.

1.3 Other Diagnostic Tools and Real-User Monitoring

While Google’s tooling is a great starting point, it pays to diversify:

• GTmetrix and WebPageTest let you test from multiple locations, compare protocols (HTTP/2 vs HTTP/1.1) and visualise waterfall charts.
• SpeedCurve combines synthetic tests with real-user metrics to show performance trends alongside business KPIs like bounce rate.
• Real-User Monitoring (RUM) platforms such as New Relic Browser or Google’s Chrome User Experience Report capture actual visitor data, including geographic variations, device types and network conditions.

Synthetic tests are invaluable for pinpointing specific bottlenecks under consistent conditions. RUM fills in the gaps by surfacing issues only your actual customers might face. Together, they ensure you’re optimising for both peak performance and real-world reliability.

2. Set Clear Performance Budgets for Speed

Once you have a baseline, it’s vital to put constraints in place that keep performance on track. A performance budget is a set of limits such as total page weight, number of requests or JavaScript bundle size that a page must stay under. By agreeing on these thresholds up front, teams can prevent feature creep, avoid surprise regressions and ensure every new addition earns its place.

Budgets turn abstract goals (like “make it faster”) into concrete targets: for example, capping total page weight at 500 KB or allowing no more than 50 network requests. When everyone from developers to content editors knows these limits, it’s easier to spot when an optimisation is needed and to prioritise work that drives the most impact. Let’s look at how to choose and track the right metrics for your site.

2.1 Why Performance Budgets Matter

Performance budgets act like financial budgets for speed. Without them, it’s all too easy for pages to balloon with large images, multiple tracking scripts or hefty third-party widgets. Some real-world examples:

Performance Budget Example:
  Total page weight: 500 KB
  Max HTTP requests: 50
  JavaScript bundle: 150 KB

When a page exceeds these limits:

• Load times climb, eroding user patience.
• Bounce rates tick up, sending visitors elsewhere.
• SEO rankings may suffer, since Google favours faster sites.

A clear budget keeps new features lean, ensuring every line of code and each asset serves a purpose.

2.2 Creating Actionable KPIs and Metrics

Picking the right metrics is key ideally no more than three to five core indicators that map directly to performance and business goals.

For most small business websites, useful KPIs include:

• Largest Contentful Paint (LCP): Keep under 2.5 s.
• Total JavaScript size: Target < 150 KB.
• Time to First Byte (TTFB): Aim for < 200 ms.
• Number of HTTP requests: Limit to < 50.
• Cumulative Layout Shift (CLS): Score ≤ 0.1.

Once you’ve chosen your KPIs, set up simple dashboards and alerts whether in Google Analytics, SpeedCurve or an internal tool so that stakeholders are notified immediately when a budget is breached.

2.3 Tracking and Iterating on Your Budget

Performance isn’t a one-and-done task. As you add content, features or marketing campaigns, budgets must be revisited. Incorporate budget checks into your build process with tools like webpack’s performance settings or the bundlesize plugin. Every pull request can report on asset sizes, halting merges that push you over the line.

Regularly review your thresholds perhaps quarterly to reflect changes in design, audience or device trends. If mobile devices become a larger share of traffic, you may need to tighten budgets further. Conversely, if a new feature is mission-critical, you might adjust other budgets to compensate. The key is an ongoing dialogue between developers, content creators and business owners to keep performance front and centre.

3. Optimise and Compress Images

Images are often the single largest contributor to page weight sometimes accounting for more than half of the total download size. Without careful optimisation, high-resolution photos, graphics and logos can bog down load times, especially on mobile networks. Striking the right balance between visual quality and speedy delivery means choosing the best format, compressing effectively and serving only what each device needs.

3.1 Choosing the Right Format and Compression Tools

Not all image formats are created equal. Legacy formats like JPEG and PNG remain ubiquitous, but modern alternatives deliver much leaner files:

• JPEG: Well-suited to photographs, offering adjustable lossy compression.
• PNG: Ideal for screenshots, icons or images requiring transparency but often large.
• WebP: Google’s format, typically 25–35% smaller than equivalent JPEG or PNG without noticeable quality loss.
• AVIF: A newer codec that can outperform WebP, though browser support is still catching up.

For a deeper look at how image optimisation ties into mobile-friendly design, see our guide on technical SEO and mobile performance.

Compression tools vary from hands-on to automated:

• TinyPNG: An intuitive web interface for PNGs and JPEGs, balancing quality and file size.
• ImageOptim: A macOS utility that strips metadata and applies lossless compression at scale.
• Squoosh: A browser-based tool by Google, supporting WebP, AVIF and granular quality settings.

3.2 Implementing Responsive Images (srcset and sizes)

A desktop display doesn’t need the same heavy asset that a smartphone screen does. Responsive images empower browsers to select the optimal file:

<img
  src="images/hero-800.jpg"
  srcset="
    images/hero-400.jpg 400w,
    images/hero-800.jpg 800w,
    images/hero-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Collaborative team meeting"
/>

Here, screens under 600px load the 400px-wide image, while larger viewports use up to 1200px. The sizes attribute declares expected display width, preventing oversize downloads and shaving precious milliseconds off mobile load times.

3.3 Automating Image Optimisation in Build and CMS

Manually compressing every upload is unsustainable. Automate image optimisation to keep file sizes consistent:

• Build Pipelines: Add gulp-imagemin or webpack’s imagemin-loader to your asset pipeline so images are optimised before deployment.
• CMS Plugins: WordPress sites can leverage the Optimus plugin for both lossless and lossy compression, with optional WebP conversion on upload.

Incorporating these steps into your routine ensures every image stays within your performance budget, letting you focus on stunning visuals without sacrificing speed.

4. Minify and Bundle CSS, JavaScript and HTML

Reducing the size and number of your site’s assets is one of the quickest wins you can score for page speed. Minification strips out unnecessary characters like comments, whitespace and debug statements while bundling combines multiple files into fewer network requests. Together, they shrink download sizes and cut round-trip times. However, the optimal strategy depends on your server protocol: HTTP/1.1 favours bundling, whereas HTTP/2’s multiplexing can handle many small assets in parallel. Let’s look at how to strike the right balance.

4.1 Benefits of Minification

Minification works by removing everything that a browser doesn’t need to execute code:

• Stripping comments, line breaks and extra spaces
• Eliminating dead code or unused functions
• Shortening variable names where possible

For instance, a JavaScript bundle that starts at 120 KB can often drop to around 80 KB once minified a one-third reduction that translates directly into faster downloads, especially on slower connections. You can minify CSS, JavaScript and even HTML to ensure every kilobyte contributes to user experience, not bulk.

4.2 Bundling vs HTTP/2 Multiplexing

Under HTTP/1.1, each file requires its own request, so combining your CSS into a single file and your JavaScript into a couple of bundles can dramatically reduce latency. Conversely, HTTP/2 allows browsers to fetch multiple assets over one connection simultaneously. In that world, breaking your code into logical, cacheable chunks often yields better efficiency users only download the pieces they need. A hybrid approach detects protocol support: bundle aggressively for HTTP/1.1 clients, but serve smaller modules when HTTP/2 is available.

4.3 Tools and Plugins for Minification and Bundling

Modern build tools automate these tasks seamlessly:

• JavaScript: Terser or UglifyJS to compress and mangle scripts
• CSS: cssnano or clean-css to strip out redundant rules
• Build orchestrators: webpack, Gulp or Parcel to define minification and bundling pipelines

By integrating these into your development workflow whether via npm scripts or CI/CD you ensure every deployment delivers lean, performant assets without extra effort. If you’re running a WordPress site, check out our guide on how to speed up a WordPress website for tailored optimisations, including minification and bundling best practices.

5. Eliminate Render-Blocking Resources

Browsers halt page rendering when they encounter CSS or JavaScript that must load before anything else can appear. These render-blocking resources delay First Contentful Paint (FCP) and frustrate users eager to see content. By shifting non-critical code out of the initial load path and bringing essential styles and scripts forward you can significantly improve perceived performance.

Implementing these optimisations requires a blend of simple HTML tweaks and build-time tooling. Let’s explore three practical techniques to tame render-blocking resources without sacrificing functionality or maintainability.

5.1 Deferring and Asynchronous Loading of JavaScript

By default, <script> tags block parsing until the script is fetched and executed. Two attributes async and defer help you control that behaviour:

• async downloads the script without blocking HTML parsing, then pauses rendering to execute it immediately.
• defer also downloads in parallel, but waits until the document has been parsed before running.

Use async for independent scripts (e.g. analytics), and defer for scripts that rely on the full DOM:

<!-- Independent analytics: fetch and run when ready -->
<script async src="https://example.com/analytics.js"></script>

<!-- Application logic: execute after parsing -->
<script defer src="/js/main.bundle.js"></script>

If you have inline scripts that initialise critical features, consider wrapping them in a small loader function and placing it at the end of <body>, so the browser can paint page structure before handling logic.

5.2 Inlining Critical CSS

Critical CSS consists of the minimal styles needed to render above-the-fold content. By inlining these rules directly into the <head>, you avoid an extra round trip to fetch an external stylesheet:

<head>
  <style>
    /* Critical CSS: basic layout, typography, header */
    body { margin: 0; font-family: sans-serif; }
    header { background: #004080; color: #fff; padding: 1rem; }
    .hero { display: flex; align-items: center; justify-content: center; }
  </style>
  <link rel="stylesheet" href="/css/main.css">
</head>

To automate extraction of critical rules, tools like the critical npm package or Penthouse can crawl your pages, isolate above-the-fold selectors and generate an inline stylesheet. This way, you maintain a full external CSS bundle for the rest of the site while ensuring a fast initial render.

5.3 Preloading Key Assets for Above-the-Fold

Even when you defer non-critical resources, some files remain essential for the first render such as hero images, web fonts or icon sets. Preloading signals the browser to prioritise these assets:

<!-- Preload hero image -->
<link rel="preload" as="image" href="/images/hero-1200.jpg">

<!-- Preload web font -->
<link rel="preload" href="/fonts/Roboto.woff2" as="font" type="font/woff2" crossorigin>

For resources you’ll likely need later such as below-the-fold images or next-page scripts use rel="prefetch" to instruct the browser to fetch them during idle time:

<link rel="prefetch" as="script" href="/js/gallery.js">

Balancing preload and prefetch ensures critical assets arrive as soon as possible without starving the main thread. Together with deferred scripts and inlined CSS, these techniques dramatically reduce the time it takes for a user to see and interact with your content.

6. Leverage Browser Caching and Server-Side Caching

Caching is a cornerstone of website performance best practices. By storing copies of assets closer to your users or on their devices, you cut down on redundant network requests and shave precious milliseconds off each page load. For small businesses, even modest caching gains can translate into noticeably snappier pages and reduced hosting costs. In this section, we’ll cover how to configure cache headers, how CDNs layer their own caching, and when to employ server-side strategies like reverse-proxy and application caching.

6.1 Configuring HTTP Cache Headers

HTTP cache headers tell browsers how long they can reuse a resource without re-fetching it from your server. The most important header is Cache-Control, which supports directives such as:

• max-age=<seconds>
  Specifies how long (in seconds) a resource is fresh.
• public
  Marks the response as cacheable by any cache (browser or intermediary).
• immutable
  Indicates the resource won’t change, so the browser needn’t re-validate even after expiry.

A typical header might look like this:

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

For legacy clients, you can include an Expires header as a fallback:

Expires: Wed, 21 Oct 2025 07:28:00 GMT

Most web servers allow you to configure these headers via .htaccess (Apache) or nginx.conf. By setting long TTLs on static assets images, fonts, JavaScript bundles you ensure repeat visitors load these files from their local cache, significantly speeding up subsequent page views.

6.2 CDN Caching Layers

A Content Delivery Network (CDN) operates a global network of edge servers that cache your content nearer to users. There are two main models:

• Pull Zone: The CDN fetches assets from your origin server on the first request, then serves them to subsequent visitors from the edge cache.
• Push Zone: You upload assets directly to the CDN, bypassing the origin for most requests.

Edge servers honour your HTTP cache headers but may also provide custom TTL settings in their dashboard. When you update a resource say, a CSS file you’ll need to purge or invalidate the cached version to ensure users receive the newest copy. Common strategies include:

• Cache-busting filenames: Append a version or hash, e.g. main.1a2b3c.css.
• Programmatic purges: Use your CDN’s API to invalidate specific URLs after deployment.

By combining long-lived headers with a disciplined purge process, you get the benefit of aggressive caching without serving stale assets.

6.3 Server-Side Caching Strategies

Beyond browser and CDN layers, server-side caching further accelerates dynamic sites by offloading work from your origin. Two popular approaches are:

1. Reverse-Proxy Caching
   Tools like Varnish sit in front of your web server and cache full HTTP responses. When configured correctly, Varnish can deliver cached pages in microseconds, bypassing PHP or application logic entirely.
2. Application-Level Caching
   Caching systems such as Redis or Memcached store fragments or full page outputs in memory. Many CMS platforms and frameworks offer extensions to leverage these caches:
   • WordPress: Plugins like WP Super Cache or W3 Total Cache can generate static HTML versions of dynamic pages.
   • Drupal: Modules such as Boost or built-in page and entity caching reduce database queries on each request.

Server-side caches generally require careful invalidation policies clearing or re-generating cached entries when content changes but the payoff is dramatic: less CPU load, faster TTFB (Time to First Byte) and a more resilient site under traffic spikes.

By layering browser caching, CDN edge caching and server-side caches, you create a multi-tiered defence against slow load times. Each request becomes lighter, and your infrastructure is freed to handle more users with the same resources.

7. Use a Content Delivery Network (CDN) to Reduce Latency

Even the most finely tuned website will feel sluggish if its assets have to travel halfway around the world. A Content Delivery Network (CDN) solves this by caching copies of your static files images, stylesheets, scripts on servers (PoPs) located near your visitors. When someone requests a page, the CDN serves those resources from the nearest edge server, slashing round-trip times and improving Time to First Byte (TTFB). The result is a faster, more consistent experience for users, whether they’re in Guildford, Glasgow or Geneva.

CDNs aren’t just about speed. They also offload traffic from your origin server, helping you handle spikes without costly infrastructure upgrades. Many providers include built-in optimisation features automated image compression, HTTP/2 support, Brotli or Gzip compression and security services such as DDoS protection or Web Application Firewalls (WAF). For small businesses, a CDN can be a cost-effective way to boost performance and reliability without increasing your day-to-day maintenance.

7.1 How CDNs Work and Key Components

At its core, a CDN consists of:

• Points of Presence (PoPs): Geographically distributed servers that cache your assets.
• Edge Servers: PoPs that respond to user requests instead of your origin.
• Origin Server: The central host of your website, contacted only on cache misses or purges.
• Cache Rules: Configurations that determine how long files stay at the edge, often based on HTTP headers or custom TTLs.

When a visitor requests a resource, DNS routing sends them to the optimal PoP. If the edge server has a fresh copy, it delivers instantly; otherwise it fetches from the origin, caches it, then serves future visitors.

7.2 Choosing the Right CDN

Picking a CDN means weighing coverage, features and price:

• Geographic Reach: Look for PoPs near your target audience. A UK-focused business may prioritise strong European nodes.
• Protocol and Security Support: Ensure HTTP/2 (and ideally HTTP/3) compatibility, SSL certificates and DDoS protection.
• Purge and Invalidation: A flexible API or dashboard lets you clear cached files after an update, guaranteeing visitors see the latest content.
• Pricing Model: Pay-as-you-go versus flat-rate plans can have a big impact on cost predictability as traffic grows.

Many CDNs offer free tiers or trials experiment with a couple to see which delivers the best performance in your key regions.

7.3 Monitoring CDN Performance

A CDN is only as good as its fastest edge. Keep an eye on performance by:

• Ping/Traceroute Tests: Tools like KeyCDN’s Ping Test or traceroute can reveal network latency to various PoPs.
• Synthetic Tests: Run regular tests via WebPageTest or GTmetrix from multiple locations to compare load times with and without the CDN.
• Real-User Metrics: RUM platforms (e.g. Google Analytics’ site speed reports) will show whether latency improvements translate into a better experience for your actual visitors.

By combining synthetic and RUM data, you’ll spot misconfigured cache rules, regional gaps or DNS slowdowns allowing you to tweak settings and maintain optimal delivery worldwide.

8. Reduce Server Response Time (Improve TTFB)

Time to First Byte (TTFB) measures how long it takes for a browser to receive the first chunk of data after requesting a page. It’s a combination of network latency (DNS lookup, TCP/TLS handshake) and server-side processing (application logic, database queries). Lowering TTFB means visitors see content sooner and search engines take notice. Let’s explore how to trim both sides of the equation.

8.1 Optimising Your Hosting Environment

Your choice of hosting has a direct impact on TTFB. Shared hosting plans may be budget-friendly, but resources like CPU and RAM are often throttled, leading to slow response times. For a noticeable improvement:

• Move to SSD-backed servers. Solid-state drives dramatically reduce file read/write times compared with spinning disks.
• Choose a VPS or dedicated instance. Guaranteed CPU cores and memory ensure consistent performance under load.
• Consider managed hosting. Providers tailor server stacks (PHP, database, caching) for your CMS, keeping software up to date and tuned.
• Upgrade your runtime. PHP 7+ delivers significant speed gains over PHP 5.6; HHVM can yield further improvements for heavy-traffic sites.

Even a small uplift in server hardware or a jump to a modern PHP version can shave tens of milliseconds off your TTFB.

8.2 Tuning Backend Infrastructure

Once your server hardware is in order, focus on the application layer:

• Database indexing. Analyse your most common queries and ensure columns used in WHERE, JOIN and ORDER BY clauses are indexed. Proper indexes can cut query time from hundreds of milliseconds to a few.
• Query optimisation. Enable your database’s slow-query log and look for operations that scan large tables. Break complex joins into simpler steps or cache lookup results where possible.
• Connection pooling. Persistent connections (for instance via PgBouncer or MySQL’s thread pooling) reduce the overhead of opening new connections on each request.
• In-memory caching. Use Redis or Memcached to store frequent lookups, session data or rendered fragments, bypassing the database entirely for those requests.
• Profiling tools. Tools like New Relic, Query Monitor (for WordPress) or the MySQL Tuner script highlight bottlenecks in real time, letting you target the slowest components.

By systematically profiling and refining data access and offloading repeat operations to a cache you’ll see measurable reductions in server-side processing time.

8.3 Continuous Monitoring of TTFB

Optimisation isn’t a one-off task. To ensure your TTFB remains within acceptable bounds:

• Synthetic testing. Automate regular requests (using WebPageTest, GTmetrix or a simple curl script) from key regions and record TTFB values.
• Real-User Monitoring (RUM). Leverage Google Analytics’ Site Speed reports or a dedicated RUM tool to capture actual visitor experiences, broken down by device, geography and network.
• Define targets and alerts. A good rule of thumb is to aim for TTFB under 200 ms. Configure alerts in your monitoring platform so that any spike caused by a code deploy, plugin update or traffic surge triggers an investigation.

This blend of synthetic and real-user metrics keeps you aware of regressions before they hurt conversions or rankings. Regular reviews ensure that as your site grows, your infrastructure and code remain as responsive as day one.

9. Enable Gzip or Brotli Compression

Text assets HTML, CSS, JavaScript and even JSON tend to compress extremely well. By enabling server-side compression, you can reduce file sizes by up to 70–80%, cutting bandwidth and speeding up downloads. Modern browsers automatically negotiate the best supported algorithm, so your server just needs to advertise Gzip or the newer Brotli format. Let’s look at how to configure both and ensure they’re working correctly.

9.1 Configuring Compression in Apache and Nginx

On Apache (with mod_deflate and optionally mod_brotli), add the following to your .htaccess or server config:

<IfModule mod_deflate.c>
  # Compress common text-based assets
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE font/ttf
  AddOutputFilterByType DEFLATE font/otf
  AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

<IfModule mod_brotli.c>
  # Enable Brotli compression for the same asset types
  AddOutputFilterByType BROTLI_COMPRESS text/plain
  AddOutputFilterByType BROTLI_COMPRESS text/html
  AddOutputFilterByType BROTLI_COMPRESS text/css
  AddOutputFilterByType BROTLI_COMPRESS application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json
  AddOutputFilterByType BROTLI_COMPRESS application/xml
  AddOutputFilterByType BROTLI_COMPRESS font/ttf
  AddOutputFilterByType BROTLI_COMPRESS font/otf
  AddOutputFilterByType BROTLI_COMPRESS image/svg+xml
</IfModule>

For Nginx, enable Gzip and Brotli modules in your nginx.conf:

http {
  # Gzip settings
  gzip on;
  gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml;
  gzip_comp_level 5;
  gzip_min_length 1024;
  gzip_vary on;

  # Brotli settings (if compiled with ngx_brotli)
  brotli on;
  brotli_types text/plain text/css application/javascript application/json application/xml image/svg+xml;
  brotli_comp_level 4;
  brotli_min_length 1024;

  server {
    # ...
  }
}

9.2 Choosing Compression Levels and Trade-Offs

Compression levels range from 1 (fast, less compression) to 9 (slow, maximum compression). Higher levels shrink files more but consume extra CPU time:

• Gzip levels 4–6 often hit the sweet spot up to 60% reduction with moderate CPU cost.
• Brotli at level 4–5 commonly outperforms Gzip, though higher Brotli levels (7–11) can incur noticeable encoding delays.

If your server is under heavy load, lean toward lower levels. For static files rarely updated, you might pre-compress at build time using higher settings, then serve the pre-compressed artifacts without on-the-fly encoding.

9.3 Verifying Compression Is Active

After configuring, double-check that browsers receive compressed responses:

1. Browser DevTools: In Chrome’s Network tab, inspect a request’s Response Headers. Look for:
   • Content-Encoding: gzip or Content-Encoding: br
2. Command line:

   curl -I https://yourdomain.com | grep -i content-encoding
   

3. Online testers: Sites like [gzipwtf.com] or similar tools will report compression status.

If you’re seeing uncompressed assets, ensure your cache layers (CDN, reverse proxy) aren’t stripping headers, and that compression modules are enabled and loaded in your server stack. Once active, Gzip and Brotli will become silent workhorses shrinking payloads and shaving precious milliseconds off every page load.

10. Adopt HTTP/2 and HTTP/3 Protocols

Upgrading from HTTP/1.1 to HTTP/2 and soon HTTP/3 can deliver substantial performance gains without changing your application code. These modern protocols tackle the inefficiencies of traditional request–response cycles, reducing latency and improving resource utilisation. By layering HTTP/2 or HTTP/3 on top of your existing TLS setup, you unlock features like multiplexed streams, header compression and faster handshakes, all of which translate into snappier page loads and a smoother user experience.

10.1 Advantages of HTTP/2

HTTP/2 introduces a number of features designed to eliminate common bottlenecks:

• Multiplexing: Multiple requests and responses share a single TCP connection concurrently, removing the head-of-line blocking present in HTTP/1.1.
• Header Compression: HPACK reduces the size of HTTP headers, which can account for a significant portion of each request’s payload.
• Server Push: The server can proactively send resources (CSS, scripts) anticipated by the client, cutting out extra round trips.
• Stream Prioritisation: Clients can signal which resources are most important, allowing the server to allocate bandwidth accordingly.

In practice, these improvements can reduce page load times by up to 30 % on resource-heavy sites. Even without bundling or minification changes, simply enabling HTTP/2 often yields an immediate speed boost.

10.2 Enabling HTTP/2 on Your Server

HTTP/2 requires a secure connection (TLS 1.2 or later), so ensure you’ve got a valid SSL certificate in place. Configuration differs by web server:

Apache (with mod_http2 enabled):

# Enable HTTP/2 alongside HTTP/1.1
Protocols h2 http/1.1

<VirtualHost *:443>
  SSLEngine on
  SSLCertificateFile    /etc/ssl/certs/yourdomain.crt
  SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

  # Other SSL settings…
</VirtualHost>

Nginx (version 1.9.5+):

server {
  listen 443 ssl http2;
  server_name yourdomain.co.uk;

  ssl_certificate     /etc/ssl/certs/yourdomain.crt;
  ssl_certificate_key /etc/ssl/private/yourdomain.key;

  # Other SSL and server settings…
}

After restarting your server, verify support with command-line tools or online testers. For example:

curl -I --http2 https://yourdomain.co.uk

A successful upgrade will show HTTP/2 200 in the response.

10.3 Overview of HTTP/3 (QUIC)

HTTP/3 builds on UDP via the QUIC transport layer, further reducing latency and improving connection resilience:

• Faster Handshakes: QUIC can combine the TLS and transport handshake, allowing data to flow in as few as one round trip.
• Improved Loss Recovery: Since each QUIC stream is independent, packet loss in one stream doesn’t block others.
• Built-In Encryption: QUIC mandates encryption, simplifying configuration by design.

Support for HTTP/3 is growing among major browsers and CDN providers. To adopt HTTP/3, check if your hosting or CDN offers QUIC support often just a toggle in the dashboard and run the same curl command with --http3 to confirm:

curl -I --http3 https://yourdomain.co.uk

By embracing HTTP/2 and HTTP/3, you prepare your site for the next phase of web performance, ensuring faster, more reliable connections for every visitor.

11. Optimise Web Fonts for Performance

Web fonts add personality and brand consistency to a site, but they can also become a performance bottleneck. Each custom font file requires a separate request, and until the font loads, text may appear invisible or with a fallback, causing layout shifts. By refining which fonts you use, how you load them and when you rely on native alternatives, you can strike the right balance between aesthetics and speed.

11.1 Reducing Font Families and Character Sets

Every additional font family, weight or style multiplies the number of files the browser needs to fetch. Start by auditing which fonts are truly essential. Do you need both light, regular, semi-bold and bold? Could you combine italic with the regular file if it’s small? Eliminating unused weights instantly cuts kilobytes and requests.

Subsetting takes this further. Tools like Font Squirrel’s Webfont Generator or Glyphhanger let you strip out unused characters perhaps you only need basic Latin letters, digits and punctuation. A full font file might be 200 KB, whereas a subsetted WOFF2 file containing only your brand’s characters could be under 50 KB. Less data means quicker downloads, especially on mobile networks.

11.2 Preload and Preconnect for Fonts

To ensure the browser prioritises your critical font files, use preload in the document head. This hints to the browser that these assets are needed as soon as possible:

<link
  rel="preload"
  as="font"
  href="/fonts/YourFont.woff2"
  type="font/woff2"
  crossorigin
>

If you’re pulling fonts from a third-party host such as Google Fonts establish an early connection with preconnect. This step resolves DNS, sets up the TCP handshake and negotiates TLS before the request is issued, saving valuable milliseconds:

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Combining preconnect with preload helps deliver your chosen typeface swiftly, minimising flash-of-invisible-text (FOIT) or layout shifts.

11.3 Fallback to System Fonts

No matter how well tuned, custom fonts can fail to load for reasons beyond your control network restrictions, ad-blockers or browser bugs. A solid fallback strategy ensures legible text appears immediately, avoiding blank spaces that frustrate users.

Define a font stack that ends with system-native fonts, for example:

body {
  font-family: 'YourCustomFont', -apple-system, BlinkMacSystemFont,
               'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif;
}

This sequence uses the custom font first, then gracefully degrades to the fastest-loading, pre-installed fonts on Apple, Windows or Android devices. In many cases, the visual difference is minimal, but the performance gain is immediate no network request, no delay.

By trimming down font families, preloading critical files and smartly falling back to system typefaces, you can maintain brand consistency without sacrificing the fast, stable experience your visitors expect.

12. Clean Up Redirects and Fix Broken Links

Redirects and missing links might seem harmless at first after all, they get users (and search engines) to the right page eventually. In reality, each redirect adds an extra HTTP round-trip and increases server work, slowing down page loads and wasting bandwidth. Likewise, broken links (404 errors) not only frustrate visitors but can also consume resources if your server handles them inefficiently. A lean link structure ensures that every click leads directly to its destination, improving both performance and user satisfaction.

Regular maintenance pruning obsolete redirects and fixing or replacing dead links should be part of your site’s health routine. Let’s explore how redirect chains impact speed, how to spot unnecessary redirects and what to do about link rot.

12.1 Impact of Redirect Chains on Load Time

A simple 301 redirect can take anywhere from 100 ms to 300 ms depending on network conditions and server response. When redirects chain together, the delays add up:

• First redirect (A → B): ~200 ms
• Second redirect (B → C): ~180 ms
• Final request (C → resource): ~200 ms

In this example, visitors wait nearly 600 ms before the actual content begins to load. Multiply that by multiple assets (images, CSS, scripts) and you risk pushing your pages well beyond acceptable load times. Beyond the user’s browser, every redirect also uses CPU and memory on both origin and proxy servers, which can strain resources under load.

12.2 Identifying and Removing Unnecessary Redirects

The first step is to audit your site’s redirect rules and live URLs:

• Google Search Console’s Coverage report flags redirects and soft 404s in your crawl.
• Screaming Frog SEO Spider can crawl your entire site, listing chains, loops and redirect status codes.
• Online tools like Redirect Path (browser extension) show redirect chains in real time as you browse.

Once you have a list, decide which redirects are still needed. For pages you’ve permanently moved, consolidate chains into a single 301 from the original URL directly to the final location. Remove legacy rules that no longer match any incoming links. And if you use versioned filenames (for cache busting), automate the process so each deploy generates fresh URLs rather than layering new redirects on top of old ones.

12.3 Handling 404s and Link Rot

Broken links aren’t just an SEO nuisance they break the user journey. To keep your site tidy:

• Schedule periodic link audits with tools like Screaming Frog or the Online Broken Link Checker.
• Leverage Google Analytics or RUM data to identify URLs that trigger 404 errors most frequently.
• Where appropriate, configure fallback rules: for example, sending /old-blog-post to the nearest category page rather than a generic 404.

For large sites, consider a custom 404 page that offers search, recent posts or a site map guiding visitors back on track rather than leaving them at a dead end. Ultimately, fixing or redirecting broken links ensures that every visitor request is handled gracefully, cutting unnecessary server work and delivering a smoother experience from click to content.

Putting Website Speed into Action

Speed isn’t a one-off checkbox it’s an ongoing conversation between your site, your visitors and your business goals. By measuring performance and setting clear budgets, you lay the groundwork for continuous improvement. From there, quick wins like compressing images, enabling Gzip or Brotli and minifying code can deliver immediate gains without a full technical overhaul. As confidence grows, you can tackle advanced optimisations: inlining critical CSS, adopting HTTP/2 or HTTP/3, and fine-tuning your server stack for sub-200 ms TTFB.

Each of the twelve best practices we’ve covered plays a specific role in the journey:

• Establish a baseline with lab tests and real-user monitoring
• Define performance budgets to keep features lean
• Optimise and automate image compression
• Minify and bundle assets according to protocol
• Eliminate render-blocking CSS and JavaScript
• Layer browser, CDN and server-side caching
• Leverage a global CDN to reduce latency
• Tune hosting and backend for faster response times
• Enable on-the-fly compression with Gzip/Brotli
• Upgrade to HTTP/2/3 for multiplexing and quicker handshakes
• Streamline web fonts and fall back to system stacks
• Prune redirect chains and repair broken links

Remember, small changes compound. A handful of micro-optimisations can shave off seconds, directly boosting user satisfaction, conversion rates and SEO performance. Start by prioritising items that align with your current resources whether you’re a solo business owner or part of a growing team and layer in more sophisticated tactics over time.

If you’d like to accelerate your progress or simply hand off the heavy lifting, consider partnering with GFC Tech. Our Surrey-based specialists can audit your site, implement targeted optimisations and monitor performance so you can focus on what you do best: running your business. Get in touch with our team at GFC Tech to explore how we can help you deliver a faster, more engaging experience for every visitor.