Most LCP fixes you'll find assume you control the codebase. But plenty of support tickets I handled came from site owners running off-the-shelf platforms—WooCommerce, Joomla, forum software—where rewriting JavaScript or refactoring components wasn't on the table. The good news: you can shave seconds off Largest Contentful Paint by tuning the server, CDN, and origin response without a single line of frontend code.
This guide walks through eight server-level changes that consistently move the needle on core web vitals optimization. All of them work whether you're running cPanel shared hosting, a VPS with Nginx, or a cloud instance fronted by Cloudflare.
Why LCP matters at the server layer
Largest Contentful Paint measures how long it takes for the biggest above-the-fold element—usually a hero image, heading block, or video thumbnail—to render. Google weights LCP heavily in page experience scoring, and slow LCP tanks both rankings and conversions.
Most developers think LCP is purely a frontend problem. It's not. Time to First Byte (TTFB) and resource delivery both feed directly into LCP. If your origin takes 800 ms to send the HTML, or your CDN serves a 2 MB uncompressed JPEG, no amount of React lazy-loading will fix it.
Server changes hit the earlier part of the waterfall. They buy you time before the browser even starts parsing.
1. Enable HTTP/2 or HTTP/3
HTTP/1.1 opens one TCP connection per domain and queues requests in sequence. HTTP/2 multiplexes dozens of files over a single connection; HTTP/3 does the same over QUIC, which recovers faster from packet loss.
Check your protocol:
curl -I --http2 https://example.com
If you see HTTP/1.1 in the response, your server isn't negotiating HTTP/2. For Apache on cPanel, enable mod_http2 in EasyApache:
/scripts/easyapache --enable-http2
For Nginx, add to your server block:
listen 443 ssl http2;
listen [::]:443 ssl http2;
Cloudflare, Fastly, and BunnyCDN enable HTTP/2 and HTTP/3 by default, but double-check your origin supports it or you'll force protocol downgrades.
2. Serve early hints (103 status)
Early Hints is an HTTP 103 response that tells the browser to preconnect or preload critical resources while the server is still building the HTML. Cloudflare and Fastly support it; you can also configure Nginx.
For Cloudflare, toggle it under Speed → Optimization → Early Hints. No origin config required—Cloudflare parses your <link rel="preload"> tags and sends a 103 before the 200.
For Nginx, use the add_header directive inside a location block:
location / {
add_header Link "</style.css>; rel=preload; as=style" always;
add_header Link "</hero.webp>; rel=preload; as=image" always;
return 200;
}
In practice, Early Hints shaves 100–300 ms off LCP when your hero image or critical CSS lives on the same origin. It won't help if those assets are already on a separate CDN domain—preconnect there instead.
3. Compress images at the origin or edge
Uncompressed PNGs and oversized JPEGs are the fastest way to blow LCP. A 3 MB hero image will delay render even on a gigabit connection.
Automatic image compression at the edge:
- Cloudflare Polish: Speed → Optimization → turn on Lossless or Lossy. Polish converts JPEG/PNG to WebP on the fly for supporting browsers.
- BunnyCDN Optimizer: enabled per pull zone; converts and resizes automatically.
- Fastly Image Optimizer: same idea, URL parameter-based transforms.
If you're not using a CDN with built-in optimization, compress at the origin. Install jpegoptim and optipng on your VPS:
sudo apt install jpegoptim optipng
find /var/www/html/wp-content/uploads -type f -name '*.jpg' -exec jpegoptim --max=85 --strip-all {} \;
find /var/www/html/wp-content/uploads -type f -name '*.png' -exec optipng -o5 {} \;
Run that after each bulk upload, or hook it into your deployment pipeline. An 85 quality JPEG is visually identical to 100 but half the bytes.
4. Configure aggressive edge caching
Every round trip to your origin adds latency. Edge caching serves static assets—and sometimes entire HTML pages—from a POP near the visitor.
For HTML caching on Cloudflare, create a page rule:
- URL:
example.com/* - Cache Level: Cache Everything
- Edge Cache TTL: 2 hours
- Browser Cache TTL: 30 minutes
This works for mostly static sites. If you have user-specific content, use Vary headers or bypass caching for logged-in users.
For Nginx with a local cache:
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
server {
location / {
proxy_cache my_cache;
proxy_cache_valid 200 60m;
proxy_pass http://backend;
}
}
Check what's hitting the cache:
tail -f /var/log/nginx/access.log | grep HIT
A cache hit ratio above 80% means most requests never touch your origin.
5. Minify HTML at the edge or in the server config
Whitespace in HTML adds kilobytes. Doesn't sound like much, but on a 3G connection those bytes delay parse start.
Cloudflare Auto Minify (Speed → Optimization) strips whitespace, comments, and inline JavaScript. Turn it on for HTML, CSS, and JS.
For Nginx without a CDN, use ngx_http_sub_filter_module or a Lua script. The simplest approach is a post-processing filter with sed in your app pipeline, but that gets messy fast. Better to handle it at the CDN layer if you have one.
6. Prefetch DNS and preconnect to third-party domains
If your LCP element loads from a different origin—a CDN subdomain, Google Fonts, a video host—the browser has to resolve DNS, open a TCP connection, and negotiate TLS before the first byte arrives. That's 200–500 ms of dead time.
Add these tags inside <head>, either in your theme's header.php or via a plugin:
<link rel="dns-prefetch" href="//cdn.example.com">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
dns-prefetch resolves the domain early. preconnect does that plus opens the connection. Use preconnect for domains you know will serve critical resources; use dns-prefetch for everything else.
Don't go overboard. Preconnecting to ten domains wastes sockets and slows the page. Stick to two or three that serve above-the-fold assets.
7. Upgrade PHP and enable OPcache
Slow server-side execution delays TTFB, which delays everything downstream. WordPress on PHP 7.4 is twice as slow as PHP 8.1, and without OPcache every request recompiles the same scripts.
Check your current version:
php -v
In cPanel, go to MultiPHP Manager and select PHP 8.1 or 8.2 for your domain. If you're on a VPS, install it manually:
sudo apt install php8.2-fpm php8.2-opcache
sudo systemctl restart php8.2-fpm
Verify OPcache is active:
php -i | grep opcache.enable
You want opcache.enable => On. If it's off, edit /etc/php/8.2/fpm/php.ini:
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
Restart PHP-FPM and TTFB should drop by half.
8. Lazy-load off-screen images at the server or CDN
Browsers now support native lazy loading with loading="lazy", but if your CMS doesn't add that attribute automatically, you can inject it at the edge.
Cloudflare Workers example:
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
const response = await fetch(request)
let html = await response.text()
html = html.replace(/<img /g, '<img loading="lazy" ')
return new Response(html, {
headers: response.headers
})
}
Deploy that worker on your zone, and every <img> tag gets loading="lazy" added on the fly. This won't fix your LCP image—never lazy-load the hero—but it prevents below-the-fold images from competing for bandwidth during initial render.
For WordPress without touching theme files, use a plugin like "Lazy Load by WP Rocket" or add a filter in functions.php:
function add_lazy_load($content) {
return str_replace('<img ', '<img loading="lazy" ', $content);
}
add_filter('the_content', 'add_lazy_load');
Just exclude the featured image or any above-the-fold hero element.
What to test after making changes
Run PageSpeed Insights or WebPageTest with a slow 3G profile. LCP should drop below 2.5 seconds; anything above 4 seconds is failing.
Check these specific metrics:
- TTFB: under 600 ms on a fast connection, under 1.2 s on 3G.
- Largest Contentful Paint: under 2.5 s.
- Cumulative Layout Shift: under 0.1 (not covered here, but compression and caching help indirectly).
Use curl to verify headers:
curl -I https://example.com
Look for HTTP/2, cf-cache-status: HIT, and content-encoding: br or gzip. If you see MISS every time, your cache isn't working.
Compare before and after with Chrome DevTools Network tab. Filter by Img and sort by size. Your hero image should be under 200 KB and served as WebP or AVIF.
How long until I see ranking changes?
Google recrawls pages on different schedules. High-traffic pages get recrawled daily; low-traffic ones might wait weeks. Use Search Console to request re-indexing after you've verified the fixes in PageSpeed Insights.
Do these fixes help mobile more than desktop?
Yes. Mobile networks have higher latency and slower throughput, so every millisecond of TTFB and every kilobyte of compression matters more. Desktop users on fiber might not notice the difference, but mobile users on 4G will.
Can I use all eight fixes at once?
Absolutely. They don't conflict. Start with the ones that need zero code—HTTP/2, CDN caching, edge compression—then move to OPcache and Early Hints if you have access to server config.
Will this break my site?
Early Hints, HTTP/2, and OPcache are safe. Aggressive HTML caching can cause problems if you have user-specific content or frequent updates; test with a short TTL first. Image compression at 85 quality is visually lossless, but if you're paranoid, keep backups.
What to check first
Core web vitals optimization doesn't require a frontend rewrite. Start with protocol upgrades—HTTP/2 costs nothing and helps immediately. Add edge caching and image compression next; those two alone can cut LCP in half. If you still have headroom, layer in Early Hints, OPcache, and DNS prefetching.
Run the tests, compare waterfalls, and fix the slowest resources first. Server-side changes compound. Do them all and you'll see double-digit improvements without touching a single React component.