Core Web Vitals Optimization: Advanced Techniques to Fix Your LCP & FCP (For Real This Time)

By Mr. Nun September 04, 2026 Post a Comment

Okay so, let me be honest with you for a sec. A few months back, I was helping a friend of mine — she runs this cute little online batik shop out of Yogyakarta — and her website was taking like forever to load. I'm talking 7, 8 seconds before anything meaningful showed up on screen. And she was losing sales because of it. Like, real money just... evaporating.

That moment kinda hit me, you know? Because I've been deep in the web performance rabbit hole for years now, and yet here was someone I actually care about, struggling with the exact same Core Web Vitals issues that plague thousands of small businesses. Especially here in Indonesia, where internet speeds can be... well, let's just say "inconsistent" 😅

So I sat down, rolled up my sleeves, and fixed her site. LCP went from 7.2 seconds to 1.8 seconds. FCP dropped from 4.1 to under a second. And her conversion rate? Jumped 34% in the first month.

I'm sharing everything I learned — every single technique, tool, and little trick — right here. No gatekeeping. No fluffy theory. Just the stuff that actually works when you're staring at a red Lighthouse score at 11 PM and wondering why your website performance is being so stubborn.

Quick Refresher: What Are Core Web Vitals Again?

Look, I know you probably already know this, but let's make sure we're on the same page before diving into the advanced stuff. Core Web Vitals are basically Google's way of measuring whether your website feels good to a real human being. Not just a crawler. A person sitting in a café in Jakarta, trying to browse your site on their mid-range Android phone with spotty 4G.

There are three main metrics:

LCP (Largest Contentful Paint) — How fast the biggest visible element loads. Think hero images, big text blocks, video thumbnails. Target: under 2.5 seconds.
FCP (First Contentful Paint) — When the first bit of content actually appears on screen. Could be text, an image, a canvas element. Target: under 1.8 seconds.
CLS (Cumulative Layout Shift) — How much your layout jumps around. We're not focusing on this today, but don't ignore it, okay?

Google uses these as ranking signals. So if your page speed optimization is lacking, you're not just annoying your visitors — you're basically telling Google, "Hey, maybe don't rank me so high." And nobody wants that.

Understanding LCP: Why Your Hero Section Is So Slow

Alright, let's get into the meaty stuff. LCP is probably the metric that gives most developers and site owners the biggest headache. And honestly? I get it. Because there are so many things that can slow it down, and they're not always obvious.

The Largest Contentful Paint measures when the largest content element in the viewport finishes rendering. This is usually a hero image, a big headline, or a background video. And here's the thing — it's not just about file size. It's about the entire loading chain.

The LCP Loading Chain (This Is Where Most People Get It Wrong)

So here's what actually happens when someone hits your URL:

DNS lookup happens
TCP connection is established
TLS handshake (if HTTPS, wich you should definitely be using)
Server processes the request and sends back HTML
Browser starts parsing HTML
Critical resources get discovered and requested
CSS gets loaded and parsed
The LCP element gets downloaded and rendered

See that? There are like 8 steps before your visitor sees anything meaningful. And each one adds latency. If your server is hosted in Singapore but most of your users are in Surabaya, that's already an extra 40-60ms per request. Multiply that across multiple requests and suddenly you're losing half a second before the browser even starts rendering.

Advanced LCP Technique #1: Fix Your Server Response Time (TTFB)

Time to First Byte is the foundation. If your server takes 800ms just to start sending HTML, everything downstream suffers. I've seen Indonesian sites — even pretty popular ones like some local news portals — with TTFB over 1.5 seconds. That's... not great.

Here's what actually helps:

Use a CDN with edge servers close to your audience. If your users are mostly in Indonesia, make sure your CDN has PoPs in Jakarta or Singapore. Cloudflare and AWS CloudFront both have decent coverage in Southeast Asia.
Enable HTTP/2 or HTTP/3. Multiplexing is your friend. It lets the browser download multiple resources simultaneously instead of queueing them up one by one.
Implement full-page caching. If you're running WordPress (and like 40% of Indonesian websites do), use something like WP Rocket or LiteSpeed Cache. Configure it to serve cached HTML so your server doesn't have to regenerate every page on every request.
Upgrade your hosting. I know, I know. Nobody wants to hear "just pay more for better hosting." But if you're on a shared $2/month plan and getting 20,000 visitors a month, your server is literally gasping for air. Move to a VPS or managed hosting. Your LCP will thank you.

Advanced LCP Technique #2: Image Optimization That Actually Works

Okay this is a big one. Like, really big. In my experience, unoptimized images are the number one cause of slow Largest Contentful Paint. And I don't just mean "compress your JPGs." I mean a full optimization strategy.

Here's my go-to checklist:

Serve modern formats. WebP and AVIF are significantly smaller than JPEG or PNG for the same visual quality. AVIF especially is incredible — we're talking 50-70% smaller files. Use a <picture> element with fallbacks so older browsers don't break.

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Beautiful batik collection" width="1200" height="630" fetchpriority="high">
</picture>

Use fetchpriority="high" on your LCP image. This tells the browser, "Hey, this image is super important, load it first." It sounds small but it can shave 200-400ms off your LCP. I've tested this on multiple projects and it consistently helps.

Preload the LCP image. Add a preload hint in your <head> so the browser starts downloading it before it even parses the HTML where the image is referenced.

<link rel="preload" as="image" href="/images/hero.avif" fetchpriority="high">

Set explicit width and height. This prevents layout shift and helps the browser allocate space before the image loads. Small thing, big impact on percieved performance.

Don't lazy load your LCP element. I see this mistake all the time. People slap loading="lazy" on everything, including the hero image. Please don't do this. Lazy loading your LCP image literally tells the browser to deprioritize it. That's the opposite of what you want.

Advanced LCP Technique #3: Eliminate Render-Blocking Resources

Render-blocking CSS and JavaScript are like that one friend who holds up the entire group because they take forever to get ready. The browser can't render anything until it's finished parsing all the critical CSS. And if you've got 300KB of CSS in your <head>, well... your users are waiting.

The fix? Inline your critical CSS. Extract only the styles needed for above-the-fold content and put them directly in a <style> tag. Then load the rest asynchronously.

Tools like critical (the npm package) or PurgeCSS can automate this. If you're using Next.js or Astro, they handle a lot of this out of the box, wich is one reason I really like those frameworks for performance-critical projects.

FCP Optimization: Getting That First Pixel on Screen Faster

Now, FCP is a slightly different beast. While LCP cares about the largest element, FCP just wants anything to show up. A single paragraph of text counts. A tiny icon counts. The goal is to get something visible as fast as possible so the user knows the page is loading.

And honestly, FCP is where a lot of sites leave easy wins on the table.

Advanced FCP Technique #1: Critical Rendering Path Optimization

The critical rendering path is the sequence of steps the browser takes to go from receiving HTML to painting pixels. Every unnecessary step here delays your First Contentful Paint.

To optimize it:

Minimize critical resources. Reduce the number of CSS and JS files that must load before first paint. Defer non-essential scripts. Use defer or async attributes liberally.
Reduce critical bytes. Minify everything. Remove unused CSS. I once audited a site where 78% of the CSS was unused. Seventy-eight percent! We cut it down and FCP improved by 600ms.
Minimize round trips. Every request-response cycle adds latency. Combine files where possible, use HTTP/2 server push, or just reduce the total number of critical resources.

Advanced FCP Technique #2: Font Loading Strategy

Oh, fonts. The silent killer of FCP. I can't tell you how many sites I've seen where the text doesn't appear for 2-3 seconds because the browser is waiting for a custom font file to download.

The default behavior is called FOIT — Flash of Invisible Text. The browser hides all text until the font loads. And if that font file is 200KB and on a slow connection... yeah. Your users are staring at a blank white screen.

Here's how to fix it:

Use font-display: swap. This tells the browser to show text immediately with a fallback font, then swap to your custom font once it loads. There might be a tiny visual shift, but at least users can start reading.

@font-face {
  font-family: 'MyCustomFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: swap;
}

Subset your fonts. If your site is in English, you don't need Cyrillic or Greek characters in your font file. Subsetting can reduce font file sizes by 60-80%. For Indonesian sites, you mostly need Latin characters plus maybe some special characters. Tools like Glyphhanger or fonttools can help you subset automatically.

Preload your most critical font file. Just one. The one used for your main body text or headline. Don't preload every weight and variant.

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

Advanced FCP Technique #3: Optimize Your HTML Delivery

This one is kinda underrated, honestly. The size and structure of your HTML document itself matters for FCP.

Keep your initial HTML under 14KB (that's the typical initial TCP congestion window). If your HTML is 50KB, the browser needs multiple round trips just to receive it.
Put critical content early in the document. Don't make the browser parse 200 lines of navigation markup before it gets to the actual content.
Use server-side rendering (SSR) or static generation where possible. Client-side rendered apps often have terrible FCP because the browser has to download, parse, and execute JavaScript before any content appears.

I learned this the hard way working on a React project for a Jakarta-based startup. Their FCP was over 4 seconds because everything was client-rendered. We migrated to Next.js with static generation and FCP dropped to 0.8 seconds. Same content, same design. Just... faster. It was kinda magical, honestly.

Measuring and Monitoring: You Can't Fix What You Don't Measure

Okay so you've made some changes. Amazing. But how do you know if they actually worked? You need data. Real data. Not just "it feels faster."

Lab vs. Field Data (Both Matter)

Lab data is what you get from tools like Lighthouse, PageSpeed Insights, or WebPageTest. It's collected in a controlled environment. Great for debugging and finding specific bottlenecks.

Field data (also called Real User Monitoring or RUM) comes from actual visitors. Chrome's CrUX report, Google Search Console's Core Web Vitals report, or tools like SpeedCurve and Calibre give you this. It reflects real-world conditions — slow phones, bad connections, users in rural Kalimantan with 3G.

You need both. Lab data helps you diagnose problems. Field data tells you if your fixes actually helped real people. Don't optimize for Lighthouse scores alone. Optimize for your users.

My Favorite Tools for Web Performance Monitoring

PageSpeed Insights — Free, gives both lab and field data, and suggests specific fixes. I use it weekly.
WebPageTest — More detailed waterfall charts. You can test from different locations, including ones close to Indonesia.
Lighthouse CI — Automate performance budgets in your CI/CD pipeline. If a deploy makes LCP worse, it fails the build. Chef's kiss.
Chrome DevTools Performance tab — For deep-diving into specific rendering issues.

And if you want something that just quietly monitors your site and alerts you when Core Web Vitals regress, look into Calibre or SpeedCurve. They're not free, but if your site generates revenue, the investment is honestly a no-brainer.

Common Mistakes I See (Please Don't Do These)

After auditing dozens of websites — Indonesian e-commerce sites, blogs, corporate pages, you name it — here are the mistakes I keep seeing over and over:

1. Adding a "Speed Optimization" Plugin and Calling It a Day

Look, I'm not saying plugins like WP Rocket or Autoptimize are bad. They're great. But they're not magic. If your hosting is terrible, your images are 5MB each, and you've got 47 third-party scripts loading, a plugin isn't gonna save you. Performance optimization is a holistic thing. It's not one switch you flip.

2. Ignoring Mobile Performance

Over 85% of internet traffic in Indonesia comes from mobile devices. And most of those are mid-range Android phones with limited RAM. If you're testing your site on a MacBook Pro with fiber internet and saying "it loads fast," you're not testing the right thing. Use throttling in DevTools. Test on a real budget phone. Feel the pain your users feel.

3. Chasing a Perfect 100 Lighthouse Score

I get it, the green number is satisfying. But a 100 Lighthouse score doesn't always mean a fast real-world experience. And a 75 doesn't always mean your site is slow. Focus on the actual metrics — LCP under 2.5s, FCP under 1.8s — and on your field data. The score is a guide, not the destination.

4. Forgetting About Third-Party Scripts

Analytics tags, chat widgets, ad scripts, social media embeds, A/B testing tools... they all add weight. I audited a site last month that had 19 third-party scripts. Nineteen! The page was 4.2MB and LCP was over 6 seconds. We cut it down to 6 essential scripts and LCP dropped to 2.1 seconds. Sometimes the best optimization is just... removing stuff.

Putting It All Together: A Real-World Example

Remember my friend's batik shop I mentioned at the beginning? Let me walk you through what we actually did, step by step:

Moved hosting from a cheap shared server in the US to a managed WordPress host with a data center in Singapore. TTFB went from 1.4s to 280ms.
Converted all product images from JPEG to WebP, added explicit dimensions, and set fetchpriority="high" on the hero image. Saved about 60% on image payload.
Inlined critical CSS (about 3KB) and deferred the rest. Removed 2 unused CSS files entirely.
Switched font loading to font-display: swap and subsetted the font to Latin characters only. Saved 140KB.
Removed 4 unnecessary plugins and their associated scripts. The site went from 89 requests to 34.
Added a preload hint for the hero image and the main font file.

Total time spent: about 2 days. Result: LCP went from 7.2s → 1.8s. FCP from 4.1s → 0.9s. Bounce rate dropped 22%. And most importantly, her sales went up. Like, actually went up. That's the whole point, right? It's not about the numbers. It's about the people on the other side of the screen having a better experience.

Conclusion: Your Next Steps (Yes, Actually Do Them)

Okay, I've thrown a lot of information at you. So let me make this simple. Here's what I want you to do, starting today:

This week:

Run your site through PageSpeed Insights. Note your LCP and FCP scores.
Identify your LCP element. Is it an image? A text block? A video?
Check your TTFB. If it's over 600ms, that's your first problem to fix.

This month:

Optimize your images. Convert to WebP/AVIF, add dimensions, preload the LCP image.
Audit your CSS. Inline critical styles, defer the rest, remove unused rules.
Fix your font loading strategy. Use font-display: swap and subset your fonts.
Cut unnecessary third-party scripts. Be ruthless.

Ongoing:

Set up continuous monitoring. Use Lighthouse CI or a RUM tool.
Check Core Web Vitals in Google Search Console monthly.
Every time you add a new feature or script, ask: "Will this hurt my loading time?"

Web performance isn't a one-time project. It's a practice. A habit. Like brushing your teeth, but for your website. And honestly? Once you get into the rhythm of it, it becomes kinda fun. There's something really satisfying about watching those numbers drop and knowing your users are having a smoother experience.

You've got this. Go make your site fast. Your users — especially the ones browsing on a $150 Android phone in a small town in Jawa Tengah — will thank you for it. 🤍

Found this helpful? Share it with that one friend who keeps complaining about their slow website. You know the one.

PikTekno