You've already implemented the basics: compression, image optimization, CDN, browser caching. Your Lighthouse score is respectable, but real-world performance still lags under certain conditions. This guide skips the 101-level advice and focuses on advanced, tactical optimizations that separate adequately fast sites from genuinely performant ones.
Server-Level Performance Tuning
HTTP/3 and QUIC Protocol
HTTP/3 eliminates head-of-line blocking at the transport layer by running over QUIC instead of TCP. For users on high-latency or lossy connections, the difference is measurable.
Enable HTTP/3 in your web server. For Nginx with OpenSSL QUIC support:
server {
listen 443 quic reuseport;
listen 443 ssl;
http3 on;
quic_retry on;
add_header Alt-Svc 'h3=":443"; ma=86400';
ssl_early_data on;
# Rest of your SSL config
}
For Apache with mod_h2, ensure you're running a version that supports HTTP/3 through a reverse proxy like Caddy or use a CDN that terminates HTTP/3 at the edge.
Monitor connection protocol distribution in your access logs and adjust the Alt-Svc header duration based on adoption rates.
TCP and Kernel Tuning
Default kernel parameters are conservative. For high-traffic sites, tune TCP settings to reduce latency.
Edit /etc/sysctl.conf:
# Increase TCP buffer sizes
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# Enable TCP Fast Open
net.ipv4.tcp_fastopen = 3
# Reduce TIME_WAIT socket accumulation
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_tw_reuse = 1
# BBR congestion control
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
Apply changes:
sudo sysctl -p
BBR congestion control significantly improves throughput on networks with variable latency. Verify it's active:
sysctl net.ipv4.tcp_congestion_control
Connection Pooling and Keep-Alive Optimization
Connection reuse eliminates handshake overhead. Fine-tune keep-alive settings based on your traffic patterns.
For Nginx:
keepalive_timeout 65;
keepalive_requests 1000;
upstream backend {
server 127.0.0.1:8080;
keepalive 32;
keepalive_requests 1000;
keepalive_timeout 60s;
}
For high-traffic sites, increase keepalive_requests to amortize connection costs across more requests. Monitor connection churn in your metrics.
Advanced Resource Prioritization
Fine-Grained Resource Hints
Resource hints tell browsers what to fetch before they parse the full document. Use them strategically, not indiscriminately.
Preconnect for critical third-party origins:
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example.com">
DNS-prefetch for origins you'll eventually need but not immediately:
<link rel="dns-prefetch" href="https://analytics.example.com">
Preload critical resources discovered late in parsing:
<link rel="preload" href="/fonts/primary.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/critical.css" as="style">
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
Avoid preloading more than 3-5 resources. Each preload competes with parser-driven requests and can delay actual rendering if overused.
Priority Hints and Fetch Priority
The fetchpriority attribute gives you explicit control over resource loading priority.
Boost critical above-the-fold images:
<img src="hero.webp" fetchpriority="high" alt="Hero">
De-prioritize below-the-fold content:
<img src="footer-logo.webp" fetchpriority="low" loading="lazy" alt="Logo">
For scripts, combine with async or defer strategically:
<script src="critical-analytics.js" fetchpriority="high"></script>
<script src="social-widgets.js" fetchpriority="low" async></script>
Critical Rendering Path Optimization
Eliminate Render-Blocking CSS
Inline critical CSS directly in the <head>, then load full stylesheets asynchronously.
Generate critical CSS using tools that analyze your actual above-the-fold content, not generic extraction:
<style>
/* Inline critical CSS here: layout, typography, hero */
body{margin:0;font-family:system-ui}
.hero{min-height:100vh}
</style>
<link rel="preload" href="/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/full.css"></noscript>
Keep inline critical CSS under 14KB (the TCP slow-start window) to ensure it arrives in the first round-trip.
Async and Defer Strategy
Misusing async and defer causes more problems than it solves.
Defer for scripts that depend on DOM or execution order:
<script src="jquery.js" defer></script>
<script src="app.js" defer></script>
Deferred scripts execute in document order after parsing completes.
Async for independent scripts with no dependencies:
<script src="analytics.js" async></script>
<script src="tracking-pixel.js" async></script>
Async scripts execute immediately when downloaded, in unpredictable order. Never use async for scripts that manipulate the DOM or depend on other scripts.
Early Hints (HTTP 103)
Early Hints allow the server to send Link headers before the full response is ready, enabling browsers to preconnect or preload while the server generates dynamic content.
Configure Cloudflare or Fastly to send Early Hints:
http2_push_preload on;
add_header Link "</critical.css>; rel=preload; as=style, </hero.webp>; rel=preload; as=image";
For dynamic applications with slow database queries, Early Hints can shave hundreds of milliseconds off perceived load time by parallelizing resource discovery with backend processing.
Database and Backend Optimization
Query Performance for Dynamic Content
Slow database queries destroy page speed. Profile every query in your critical path.
For MySQL/MariaDB, enable the slow query log temporarily:
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
Analyze with pt-query-digest:
pt-query-digest /var/log/mysql/slow.log | head -n 100
Common fixes: - Add composite indexes for multi-column WHERE clauses - Avoid SELECT * in favor of explicit column lists - Use covering indexes to satisfy queries entirely from the index - Denormalize heavily-read data to eliminate joins
Object Caching for WordPress
WordPress makes dozens of database queries per page load. Object caching eliminates most of them.
Install Redis:
sudo apt install redis-server
sudo systemctl enable redis-server
Install a Redis object cache plugin and verify it's active:
wp redis status
For high-traffic sites, tune Redis memory limits in /etc/redis/redis.conf:
maxmemory 2gb
maxmemory-policy allkeys-lru
Monitor cache hit rates:
redis-cli info stats | grep hit
A well-tuned object cache should achieve 95%+ hit rates for typical WordPress workloads.
Edge Computing and CDN Optimization
Edge Workers for Dynamic Content
Traditional CDNs cache static assets. Edge workers let you run code at CDN edge nodes, bringing dynamic logic closer to users.
Use edge workers to: - Serve personalized content without origin round-trips - Implement A/B tests at the edge - Rewrite URLs or inject headers based on geolocation - Generate dynamic images on-the-fly
Cloudflare Workers example:
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
const url = new URL(request.url)
if (url.pathname.startsWith('/api/')) {
return fetch(request)
}
// Serve from cache or origin
const cache = caches.default
let response = await cache.match(request)
if (!response) {
response = await fetch(request)
const headers = new Headers(response.headers)
headers.set('Cache-Control', 'public, max-age=3600')
response = new Response(response.body, { ...response, headers })
event.waitUntil(cache.put(request, response.clone()))
}
return response
}
Smart CDN Cache Warming
Cold caches force the first visitor to each edge location to wait for an origin fetch. Warm critical pages proactively.
Create a cache-warming script:
#!/bin/bash
# Warm top pages across CDN edge locations
URLS=(
"https://example.com/"
"https://example.com/top-post/"
"https://example.com/product/"
)
POPS=("lax" "jfk" "ams" "sin" "syd") # CDN PoP codes
for pop in "${POPS[@]}"; do
for url in "${URLS[@]}"; do
curl -sL -o /dev/null "$url" -H "CF-IPCountry: $pop"
done
done
Schedule this via cron after deployments or content updates.
Advanced Image Optimization
Adaptive Image Delivery
Serve image formats based on client capabilities, not guesswork.
Use the <picture> element with format negotiation:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Hero" width="1200" height="600">
</picture>
For server-side format selection, check the Accept header:
map $http_accept $webp_suffix {
default "";
"~*webp" ".webp";
}
map $http_accept $avif_suffix {
default $webp_suffix;
"~*avif" ".avif";
}
location ~ ^/images/(.+)\.(jpe?g|png)$ {
add_header Vary Accept;
try_files /images/$1.$2$avif_suffix /images/$1.$2$webp_suffix /images/$1.$2 =404;
}
Responsive Image Lazy Loading
Combine loading="lazy" with srcset for bandwidth savings:
<img
src="small.jpg"
srcset="small.jpg 400w, medium.jpg 800w, large.jpg 1200w"
sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
loading="lazy"
alt="Content image"
>
The sizes attribute is critical. It tells the browser the rendered width so it can select the optimal source before layout.
Monitoring and Continuous Optimization
Real User Monitoring (RUM)
Synthetic tests from Lighthouse or WebPageTest don't reflect real-world conditions. Collect field data from actual users.
Implement the Performance API:
window.addEventListener('load', () => {
const perfData = performance.getEntriesByType('navigation')[0]
const metrics = {
fcp: performance.getEntriesByName('first-contentful-paint')[0]?.startTime,
lcp: null, // Requires PerformanceObserver
cls: null, // Requires PerformanceObserver
ttfb: perfData.responseStart - perfData.requestStart,
domLoad: perfData.domContentLoadedEventEnd - perfData.fetchStart,
totalLoad: perfData.loadEventEnd - perfData.fetchStart
}
// Send to your analytics endpoint
navigator.sendBeacon('/api/metrics', JSON.stringify(metrics))
})
Segment metrics by connection type, device, and geography to identify optimization opportunities for specific user cohorts.
Performance Budgets and Regression Prevention
Set hard limits on resource sizes and timings. Fail builds that exceed budgets.
Example Lighthouse CI budget:
{
"budget": [
{
"resourceSizes": [
{"resourceType": "script", "budget": 250},
{"resourceType": "stylesheet", "budget": 50},
{"resourceType": "image", "budget": 500},
{"resourceType": "total", "budget": 1000}
],
"timings": [
{"metric": "first-contentful-paint", "budget": 2000},
{"metric": "interactive", "budget": 5000}
]
}
]
}
Integrate budget checks into CI:
lhci autorun --budgets-file=budget.json
Edge Cases and Special Scenarios
High-Latency Connections
Optimize for slow networks by reducing round-trips. Every request matters.
- Inline critical resources to eliminate requests entirely
- Use HTTP/2 Server Push judiciously for 1-2 critical assets
- Implement service workers to cache navigation responses
- Compress HTML aggressively; every byte counts on slow links
Mobile-Specific Optimization
Mobile devices have less CPU, memory, and bandwidth. Treat mobile as the default, not an afterthought.
- Reduce JavaScript execution time; mobile CPUs are slower
- Minimize layout shifts; mobile reflows are expensive
- Use
<meta name="viewport">correctly to prevent double-tap zoom delay - Test on actual low-end devices, not just DevTools throttling
Third-Party Script Management
Third-party scripts are performance killers. You can't optimize code you don't control, but you can limit damage.
Facade pattern: Replace heavy embeds with static previews until user interaction:
<div id="video-facade" onclick="loadRealVideo()">
<img src="thumbnail.jpg" alt="Video">
<button>Play Video</button>
</div>
<script>
function loadRealVideo() {
const script = document.createElement('script')
script.src = 'https://youtube.com/embed/xyz'
document.getElementById('video-facade').replaceWith(script)
}
</script>
This delays third-party JavaScript until absolutely necessary.
Conclusion
Advanced page speed optimization requires thinking beyond checklists. Server-level tuning, precise resource prioritization, edge computing, and real-user monitoring separate fast sites from truly performant ones. Focus on reducing round-trips, eliminating render-blocking resources, and optimizing the critical rendering path. Test real-world conditions, set performance budgets, and monitor continuously. Speed is not a one-time achievement; it's an ongoing discipline.