Page Speed Beyond CWV Compression Caching Cdn

Compression

Enable Brotli or, as a fallback, Gzip compression at the server or CDN level for all text-based assets including HTML, CSS, JavaScript and SVG; Brotli typically achieves 15-20% smaller payloads than Gzip at the same quality setting. Verify compression is actually active by checking the Content-Encoding response header, since many misconfigured servers silently serve uncompressed assets.

Caching headers

Set long max-age Cache-Control headers, often a year, on versioned static assets like fingerprinted CSS and JS bundles, since their filenames change whenever content changes, making stale caches impossible. HTML documents should use shorter cache lifetimes or a validation strategy with ETag or Last-Modified so users get updates promptly.

• Static assets (fingerprinted): Cache-Control: max-age=31536000, immutable
• HTML: short max-age with revalidation, or no-cache with ETag
• API responses: cache selectively based on data volatility

CDN placement and edge logic

A CDN caches content at points of presence geographically close to users, cutting the network round-trip that dominates TTFB for distant visitors. Modern CDNs also support edge functions that can run redirects, A/B tests or personalisation without a round trip to the origin server, which keeps TTFB low even for semi-dynamic content.

Image and font delivery

Serve images in modern formats (WebP, AVIF) at responsive sizes via srcset, and self-host critical fonts with font-display: swap or optional rather than relying on a third-party font host that adds an extra DNS lookup and connection.

Validating gains in RankAudit

Use RankAudit's waterfall comparison to run a before-and-after test after each infrastructure change, confirming the specific improvement in TTFB, payload size or resource count rather than assuming a config change worked.

Why this lesson matters

Neglecting these infrastructure-level optimisations often leads to persistent, difficult-to-diagnose Core Web Vitals issues, particularly with LCP and FID. For an e-commerce site, for instance, a slow server response time, even by a few hundred milliseconds, can translate directly into lost conversions. Users accustomed to instant gratification will abandon carts or navigate away if pages load sluggishly, impacting revenue and potentially incurring higher ad spend for traffic that doesn't convert. Getting these foundational elements right provides a stable, performant base that makes all other front-end optimisations more effective.

From a ranking perspective, search engines increasingly factor user experience into their algorithms. While specific CWV metrics are a direct signal, the underlying speed infrastructure contributes to a broader perception of site quality. A site consistently delivering content with low latency across various user conditions is more likely to be rewarded with better visibility. Conversely, a site struggling with server-side performance or inefficient resource delivery will find it challenging to compete, regardless of its content quality or backlink profile. This lesson empowers you to build that robust foundation.

Prioritising Server-Side Optimisations for TTFB Reduction

Time To First Byte (TTFB) is often the first bottleneck. It encompasses DNS lookup, server processing time, and the network round trip. While DNS and network are often handled by CDN, server processing time falls squarely on your infrastructure. This involves optimising database queries, reducing complex server-side computations, and ensuring your backend language/framework is efficient. For a WordPress site, this might mean auditing plugins that add significant overhead; for a custom application, it's about profiling application code for slow functions or external API calls that block rendering.

A common mistake is focusing exclusively on frontend JavaScript and CSS without addressing the server's workload. If your server takes 1.5 seconds to deliver the initial HTML, no amount of frontend optimisation will make the page load fast from a user's perspective. Identifying and remedying these server-side delays requires collaboration with developers and sysadmins, using server-side profiling tools. These optimisations are often complex but yield the most significant and fundamental improvements, acting as a force multiplier for all subsequent frontend efforts.

• Audit database queries for excessive join operations or missing indexes.
• Implement server-side caching (e.g., Redis, Varnish) for dynamic content.
• Minimise external API calls or execute them asynchronously where possible.
• Upgrade server hardware or scale resources to meet demand during peak times.

Do it now

To immediately identify your server's current performance baseline and potential bottlenecks, perform a detailed TTFB analysis. This metric is a strong indicator of the efficacy of your server-side optimisations and infrastructure choices, regardless of frontend code.

• Open RankAudit and navigate to a project or create a new one for your target site.
• Execute a 'Page Speed Audit' for your primary landing pages.
• Specifically examine the 'Time To First Byte' (TTFB) metric for each URL in the report.
• Cross-reference TTFB with the 'Server Response Time' in the detailed breakdown to pinpoint server-side delays.

Key takeaways

• ✓Confirm Brotli or Gzip compression is actually active via response headers
• ✓Set year-long cache lifetimes only on fingerprinted static assets
• ✓Use a CDN to cut network distance for distant visitors
• ✓Serve modern image formats and self-host critical fonts

Why this lesson matters

This lesson belongs to Core Web Vitals and Page Speed, the part of Technical SEO Excellence where the goal is: diagnose and resolve the specific rendering and interaction bottlenecks that drag down core web vitals.

Read it once, then do it straight away on a real site inside RankAudit. Nothing here is theory for its own sake — every step produces something you can show a client.

Do it now

1. 1Open RankAudit with sample data already loaded, so you are not stuck on setup.
2. 2Crawl a site and triage the issue list.
3. 3Use RankAudit's field and lab data views to trace each Core Web Vital back to the exact element or script causing it.