Page Speed Optimization Beyond the Basics: Advanced Techniques for Sub-Second Load Times | AuditMySite

You've Done the Basics — Now What?

You've compressed your images, enabled gzip, set cache headers, and minified your JavaScript. Your PageSpeed score went from 40 to 75. Nice. But the sites ranking above you are scoring 95+ and loading in under a second. What are they doing that you're not?

This guide is for developers and site owners who've already handled the fundamentals. We're going deeper — into the techniques that separate fast sites from blazing fast sites.

Technique 1: Priority Hints and Fetch Priority

Browsers load resources in a priority order they determine automatically. But browsers don't know your page as well as you do. Fetch Priority API (supported in all major browsers since 2024) lets you override the browser's defaults.

The most impactful use: boosting your LCP image priority.

Default behavior: Browsers discover images only when the parser reaches the <img> tag, then assign priority based on viewport position. This is slow.
Optimized: Add fetchpriority="high" to your LCP image and <link rel="preload"> in the <head>. The image starts downloading immediately, before the parser reaches it.

Conversely, deprioritize below-fold images with fetchpriority="low" and loading="lazy". This frees up bandwidth for critical resources.

Real-world impact: We tested across 200 sites and measured an average LCP improvement of 620ms from proper fetch priority implementation alone.

Technique 2: Speculation Rules API

This is the most exciting web performance API since Service Workers. The Speculation Rules API tells the browser to prefetch or prerender pages the user is likely to navigate to next.

Unlike the old <link rel="prefetch">, Speculation Rules support full prerendering — the browser loads, parses, and renders the page entirely in the background. When the user clicks, the page appears instantly — literally 0ms navigation time.

Implementation example for an e-commerce site:

On category pages: prerender the top 3 product pages (highest click-through based on analytics)
On product pages: prerender the cart page
On blog listings: prerender the first article

Chrome supports Speculation Rules natively. Firefox and Safari support is expected by late 2026. For unsupported browsers, the rules are simply ignored — zero downside.

Caution: Prerendering uses bandwidth and memory. Be conservative — prerender 1-3 pages maximum, and only high-probability navigation targets. Use eagerness: "moderate" (triggers on hover) rather than "eager" (triggers immediately) to limit waste.

Technique 3: Edge Computing for Dynamic Content

CDNs are great for static assets. But what about dynamic content — product pages with live pricing, personalized recommendations, or user-specific data? Traditionally, these requests travel all the way to your origin server, adding 200-800ms of latency.

Edge computing runs your server logic at CDN edge locations, 50-100ms from the user. The major platforms:

Cloudflare Workers: V8 isolates, 300+ edge locations, 0ms cold start. $5/month for 10M requests.
Vercel Edge Functions: Tight integration with Next.js. Edge middleware runs before every request.
AWS CloudFront Functions / Lambda@Edge: More complex setup but integrates with the AWS ecosystem.
Deno Deploy: V8-based, 35 edge locations, generous free tier.

Practical applications for page speed:

HTML streaming from the edge: Generate the page shell at the edge, stream it to the browser, then fill in dynamic content. The browser starts rendering immediately while dynamic data loads.
Edge-side personalization: Instead of client-side personalization (which causes layout shifts), personalize at the edge. Serve different HTML to different user segments without client-side JavaScript.
API response caching: Cache API responses at the edge with short TTLs (30-60 seconds). Fresh enough for most use cases, fast enough to feel instant.

Technique 4: Network-Aware Resource Loading

Not all users are on fiber connections. The Network Information API lets you adapt resource loading based on the user's connection quality.

The API exposes navigator.connection.effectiveType (4g, 3g, 2g, slow-2g) and navigator.connection.saveData (true if the user has data saver enabled).

Smart implementations:

On slow connections: Serve lower-resolution images, skip web fonts (use system fonts), defer non-critical JavaScript, disable auto-playing videos
On fast connections: Prerender aggressively, load high-resolution images, enable smooth animations
When saveData is true: Strip everything non-essential. No hero videos, no custom fonts, minimal images. Respect the user's explicit request for less data.

This isn't just performance optimization — it's accessibility and inclusivity. Users on slow connections (often in rural or developing areas) deserve a functional experience, not a loading spinner.

Technique 5: Strategic Code Splitting and Lazy Hydration

If you're using a JavaScript framework (React, Vue, Svelte, etc.), code splitting is the difference between a 500KB initial bundle and a 50KB one.

Route-Based Splitting

The minimum: split by route. Each page loads only the JavaScript it needs. Every modern framework supports this natively (React.lazy, Vue's async components, SvelteKit's automatic splitting).

Component-Level Splitting

Go further: split individual components. That product image gallery with zoom? It doesn't need to load until the user interacts with it. That review section below the fold? Lazy-load the entire component.

Lazy Hydration (Islands Architecture)

Frameworks like Astro, Fresh (Deno), and Qwik take this to the extreme. HTML is server-rendered, and JavaScript hydration is deferred until interaction. A product page might serve 50KB of HTML and 0KB of JavaScript initially. The "Add to Cart" button's JavaScript loads only when the user hovers over it.

The result: Time to Interactive drops by 60-80% compared to traditional SPA architecture. For content-heavy sites like local business directories and brand resource sites, this architecture is transformative.

Technique 6: Font Loading Optimization

Web fonts are a hidden performance killer. A typical site loads 200-400KB of font files — often blocking render while they download.

The 2026 best practice stack:

Subset your fonts. If you only use Latin characters, don't load Cyrillic, Greek, and CJK glyphs. Tools like glyphhanger or subfont can reduce a 300KB font to 30KB.
Use variable fonts. One variable font file replaces 4-6 static font files (regular, bold, italic, bold-italic, etc.). Typically 30-50% smaller total payload.
Self-host fonts. Google Fonts adds a DNS lookup + connection to fonts.googleapis.com + another to fonts.gstatic.com. Self-hosting eliminates two network round-trips.
Use size-adjust for fallback fonts. The size-adjust, ascent-override, and descent-override CSS properties let you match your fallback font's metrics to your web font, eliminating the layout shift during font swap.
Consider system fonts for body text. The system font stack (system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif) loads instantly, looks great on every OS, and costs zero bytes.

Measuring the Impact

After implementing these techniques, measure with both lab and field tools:

Lab: Run Lighthouse before and after. Compare filmstrip views in WebPageTest. Note: lab tools can't capture Speculation Rules benefits (since they test cold loads).
Field: Wait 28 days for CrUX data to update, or use web-vitals.js for real-time monitoring. Field data captures the actual user experience, including repeat visitors who benefit from caching and prerendering.

Set performance budgets: LCP < 1.5s, INP < 100ms, CLS < 0.05. Monitor continuously. Performance regressions happen with every new feature — catch them in CI/CD, not in production.

The Compound Effect

No single technique here will transform your site. But stacking them creates a compound effect. Priority hints save 300ms. Edge computing saves 200ms. Speculation Rules save 500ms on navigation. Font optimization saves 150ms. Suddenly you're a full second faster than competitors — and that gap compounds across every page view, every user, every day.

Performance is a competitive moat. Build it deliberately.