Your search rankings depend on Core Web Vitals now. Google made that clear when they rolled page experience into ranking signals, and the weight keeps increasing. The good news is that most failures happen server-side, and you can fix them without touching frontend code.
I've worked hundreds of support tickets where site owners panic over red CWV scores in Search Console. The usual culprit? Misconfigured hosting, no CDN, or a database that's been slowly dying for months. Here are eight server and infrastructure changes that move the needle.
Why server config matters for Core Web Vitals
Core Web Vitals measure real user experience through three metrics: Largest Contentful Paint (LCP) tracks how fast your main content loads, First Input Delay (FID) measures interactivity, and Cumulative Layout Shift (CLS) catches visual stability problems. Most site owners think this is a frontend problem and start optimizing JavaScript. Wrong move.
Server response time feeds directly into LCP. If your TTFB is slow, everything downstream suffers. A CDN can mask some of this, but if your origin server takes two seconds to generate HTML, you're starting from a hole. FID depends on how quickly the browser can execute code, which means fewer render-blocking resources from the server. CLS often comes from images without dimensions or ads injected by server-side scripts.
The server controls all of it.
Fix 1: Enable HTTP/2 or HTTP/3 on your web server
HTTP/2 multiplexes requests over a single connection instead of opening six separate TCP streams like HTTP/1.1 does. This reduces connection overhead and speeds up resource loading, which directly improves LCP. HTTP/3 takes it further by running over QUIC, which handles packet loss better and cuts handshake time.
Most modern web servers support HTTP/2 by default if you have an SSL certificate installed. Check your current protocol:
curl -I --http2 https://yourdomain.com
If you see HTTP/2 200 in the response, you're good. If not, enable it in your web server config.
For Apache with mod_http2:
Protocols h2 h2c http/1.1
For Nginx:
listen 443 ssl http2;
HTTP/3 requires more setup because it runs over UDP. Cloudflare enables it automatically for proxied domains. On origin servers, Nginx has experimental support in recent versions, but I'd wait unless you're running a custom stack.
Fix 2: Set up aggressive server-side caching
Every dynamic page generation burns CPU and delays TTFB. If your CMS regenerates the same homepage HTML for every visitor, you're wasting time that could go toward a faster LCP. Server-side caching stores the rendered HTML and serves it directly from memory or disk.
For WordPress on Apache, install a page cache plugin that writes static HTML files. The server bypasses PHP entirely and serves the cached file.
For Nginx, use fastcgi_cache to store PHP responses:
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_cache_valid 200 60m;
Then in your location block:
location ~ \.php$ {
fastcgi_cache WORDPRESS;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
# rest of fastcgi config
}
This cuts TTFB from hundreds of milliseconds to under fifty. That's a direct LCP win.
Fix 3: Configure your CDN to cache HTML
Most CDN setups only cache images, CSS, and JavaScript. HTML stays dynamic, which means every page load hits your origin server. This is fine if your server is fast, but why take the risk?
Configure your CDN to cache HTML for logged-out users. Cloudflare calls this "Cache Everything," and you set it with a page rule. For other CDNs, look for cache level or cache behavior settings.
Set a reasonable TTL based on how often your content changes. A blog can cache HTML for an hour. An e-commerce site might need five minutes. Use cache tags or purge APIs to invalidate specific pages when you publish updates.
The result is that most visitors hit the CDN edge instead of your origin, which improves TTFB globally and helps LCP for users far from your server.
Fix 4: Optimize images at the CDN edge
Large images are the top LCP killer. A hero image that's three megabytes will always load slowly, no matter how fast your server is. CDN-based image optimization resizes, compresses, and converts images to modern formats like WebP or AVIF on the fly.
Cloudflare offers this through their Polish feature and image resizing API. Other CDNs have similar services (Cloudinary, Fastly image optimization, Akamai Image Manager). The CDN intercepts image requests, processes them, caches the result, and serves optimized versions to browsers that support them.
You can also self-host this with Nginx and the ngx_http_image_filter_module:
location ~* \.(jpg|jpeg|png)$ {
image_filter resize 800 600;
image_filter_jpeg_quality 85;
}
But CDN-based solutions handle format negotiation better and offload the processing from your server.
What if your LCP is still slow?
Check your database. I've seen LCP problems trace back to a WordPress database with a posts table carrying ten million revisions. The query to fetch recent posts was taking seconds. Run OPTIMIZE TABLE on large tables and clean up transients.
Another common issue is third-party scripts injected server-side. Ad networks, analytics tags, and social widgets added to your PHP template slow down HTML generation. Move them to a tag manager and load them asynchronously.
Fix 5: Preconnect and preload critical resources
The browser can't start downloading fonts, CSS, or JavaScript until it parses the HTML and discovers the resource URLs. By then, precious milliseconds are gone. The server can tell the browser to open connections and fetch resources early using HTTP headers or HTML tags.
Add Link headers to your server config for critical resources:
add_header Link "</path/to/font.woff2>; rel=preload; as=font; crossorigin";
add_header Link "<https://fonts.googleapis.com>; rel=preconnect";
Preconnect opens the TCP and TLS handshake to third-party domains before the browser needs them. Preload fetches specific resources early. This cuts render time and helps LCP by getting your CSS and fonts loaded faster.
Don't overuse preload. The browser has a limited connection budget, and preloading too many resources can backfire. Stick to the one or two assets that block your LCP element.
Fix 6: Enable text compression globally
Uncompressed HTML, CSS, and JavaScript waste bandwidth and delay rendering. Gzip compression has been standard for years, but Brotli compression is better. It produces smaller files at comparable speed.
Enable Brotli on Nginx:
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml text/javascript;
For Apache with mod_brotli:
AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript application/javascript
If Brotli isn't available, Gzip is still worth enabling. Check compression with:
curl -H "Accept-Encoding: br" -I https://yourdomain.com
Look for content-encoding: br in the response headers. Smaller payloads mean faster LCP.
Fix 7: Reduce TTFB with a lightweight server stack
TTFB is the time from request to first byte of response. Slow TTFB kills LCP because nothing can render until the HTML arrives. Heavy application frameworks, unoptimized databases, and low-spec VPS plans all push TTFB higher.
Profile your server response time. For WordPress, use Query Monitor to see slow database queries. For custom apps, enable slow query logging on MySQL:
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
Then check /var/log/mysql/slow.log for queries taking over half a second. Add indexes or rewrite them.
If you're on shared hosting and TTFB is consistently over three hundred milliseconds, upgrade to a VPS with more CPU and RAM. Shared hosting oversells resources, and you'll never get consistent performance.
For VPS users, switch from Apache with mod_php to Nginx with PHP-FPM. PHP-FPM manages worker processes more efficiently and handles concurrent requests better. I've seen TTFB drop by half after this change.
Fix 8: Set correct cache headers and avoid layout shifts
CLS happens when elements move after the page loads. The most common server-side cause is images and iframes without explicit dimensions. When the browser encounters an <img> tag without width and height attributes, it reserves zero space, then reflows the layout once the image loads.
Modern CMSs can inject width and height automatically, but older templates don't. Audit your HTML output and fix missing dimensions.
Another CLS source is web fonts loading late and swapping with the fallback font. Use font-display: swap in your CSS, but also serve fonts from your own domain or CDN instead of Google Fonts, so you can set long cache headers. Preload them as shown earlier to speed up delivery.
Cache headers control whether the browser reuses resources or fetches them again. Set long expiry times on static assets:
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
This prevents unnecessary refetches and keeps layout stable on repeat visits.
Monitoring and verifying your changes
After making these changes, measure the impact. Use Google PageSpeed Insights to get lab data and real user CWV scores from the Chrome User Experience Report. The lab data updates immediately, but CrUX data takes about a month to reflect real traffic.
For server-level monitoring, log TTFB and cache hit rates. In Nginx:
log_format performance '$remote_addr - $upstream_response_time - $request_time - $status';
access_log /var/log/nginx/performance.log performance;
Parse the logs to track average response time over time. Watch for spikes that correlate with traffic or batch jobs.
Run real browser tests from multiple geographic locations using WebPageTest. This shows how your changes affect LCP and FID for users far from your server. If you're serving global traffic without a CDN, expect worse scores from distant regions.
FAQ
Do I need a CDN if my server is fast?
Yes, because latency increases with distance. Even a fast server in New York will have slow TTFB for users in Australia. A CDN puts cached content closer to every visitor.
Can I fix Core Web Vitals without touching the frontend?
You can fix most LCP and TTFB problems. FID and CLS often need JavaScript and HTML changes, but server optimizations still help.
Will HTTP/3 make a big difference?
Not as big as HTTP/2 did. The improvement is noticeable on unreliable networks, but on fast connections the gain is small. Prioritize other fixes first.
How do I know which fix to start with?
Run PageSpeed Insights and check the failing metrics. If LCP is slow, focus on TTFB, caching, and image optimization. If CLS is bad, fix image dimensions and font loading first.
Where to focus first
Start with TTFB and caching. If your server takes more than two hundred milliseconds to generate a response, everything downstream suffers. Enable page caching, configure your CDN to cache HTML, and profile slow database queries. Then move to image optimization and resource preloading. Those four changes will lift most sites into the green.
FID is rarely a server problem unless you're injecting heavy third-party scripts in your HTML. Move those to async loading. CLS needs both server and frontend work, but getting image dimensions right is a server template fix.
Measure before and after. Core Web Vitals move slowly in Search Console because they're based on rolling 28-day averages. Give your changes a month to show up in real data, and don't panic if lab scores improve but CrUX scores lag.
The server controls more than you think.