Optimasi Core Web Vitals 14 mnt baca

Optimasi LCP: Analisis 4 Sub-Parts dan Implementasi Praktis

Pelajari cara mengoptimasi LCP dengan membedah 4 sub-parts-nya: TTFB, Resource Load Delay, Resource Load Duration, dan Element Render Delay. Panduan lengkap dengan kode implementasi dan checklist praktis untuk Core Web Vitals 2026.

Editorial Team

Mengapa LCP Masih Jadi Metrik Core Web Vitals yang Paling Sering Gagal?

Kalau kamu sering mengecek skor PageSpeed Insights dan merasa frustrasi melihat angka LCP yang merah menyala — percayalah, kamu nggak sendirian. Data terbaru dari Chrome User Experience Report menunjukkan bahwa lebih dari 40% website di seluruh dunia masih gagal memenuhi ambang batas LCP Google. Ya, di tahun 2026 pun, ini tetap jadi masalah nomor satu.

Tapi kenapa sih LCP itu begitu sulit dioptimasi?

Jawabannya sebetulnya sederhana: kebanyakan developer cuma melihat angka akhir LCP tanpa memahami apa yang sebenarnya terjadi di balik layar. LCP bukan sekadar satu metrik tunggal — ia terdiri dari empat sub-parts yang masing-masing butuh strategi optimasi berbeda. Dan kalau kamu nggak tahu mana yang bermasalah, kamu cuma buang-buang waktu optimasi di tempat yang salah.

Di artikel ini, kita akan membedah LCP secara menyeluruh: mulai dari pemahaman mendalam tentang setiap sub-part, teknik diagnosis yang tepat, sampai implementasi kode yang bisa langsung kamu terapkan. Artikel ini juga melengkapi seri optimasi Core Web Vitals kami — setelah sebelumnya membahas INP (Interaction to Next Paint) dan Speculation Rules API.

Oke, langsung saja kita mulai.

Apa Itu LCP dan Kenapa Penting untuk SEO?

Largest Contentful Paint (LCP) mengukur waktu dari saat pengguna memulai loading halaman hingga elemen konten terbesar di viewport selesai di-render. Elemen ini bisa berupa gambar hero, blok teks besar, atau bahkan video poster.

Google mengklasifikasikan LCP ke dalam tiga kategori:

  • Good (Baik): ≤ 2,5 detik
  • Needs Improvement (Perlu Perbaikan): 2,5 – 4,0 detik
  • Poor (Buruk): > 4,0 detik

Nah, yang perlu kamu pahami — di tahun 2026, Google sudah menjadikan performa sebagai hard ranking factor. Ini bukan lagi sinyal lunak yang bisa diabaikan. Website yang gagal memenuhi ambang batas Core Web Vitals mengalami penurunan visibilitas organik yang terukur. Studi kasus Vodafone yang didokumentasikan Google menunjukkan bahwa peningkatan LCP sebesar 31% menghasilkan kenaikan penjualan sebesar 5%.

Jadi, optimasi LCP bukan cuma soal skor hijau di Lighthouse — ini soal revenue dan ranking yang nyata.

Memahami 4 Sub-Parts LCP: Kunci Diagnosis yang Tepat

Ini bagian yang paling sering diabaikan, dan jujur saja, ini juga bagian paling penting dari seluruh artikel ini. LCP sebenarnya terdiri dari empat fase berbeda, dan masing-masing memerlukan pendekatan optimasi yang sangat berbeda.

Mengetahui sub-part mana yang paling bermasalah bisa menghemat waktu kamu — banyak sekali.

1. Time to First Byte (TTFB)

TTFB mengukur waktu dari saat browser mengirim request hingga menerima byte pertama dari server. Fase ini mencakup DNS lookup, koneksi TCP/TLS, dan pemrosesan server.

Fakta mengejutkan: menurut data web.dev, situs dengan LCP buruk rata-rata menghabiskan 2,27 detik hanya untuk TTFB — hampir seluruh budget 2,5 detik habis di sini saja! Kalau TTFB kamu sudah tinggi, optimasi di area lain praktis sia-sia. Ibaratnya memoles bodi mobil yang mesinnya rusak.

2. Resource Load Delay

Ini waktu yang terbuang sebelum browser mulai mengunduh resource LCP (biasanya gambar). Perhatikan — ini bukan waktu download-nya, tapi waktu browser "menemukan" bahwa resource tersebut perlu diunduh.

Data menunjukkan bahwa median situs dengan LCP buruk menghabiskan hampir empat kali lebih lama menunggu download dimulai dibanding waktu download itu sendiri — sekitar 1,3 detik antara TTFB dan request gambar. Itu lebih dari setengah budget LCP yang terbuang percuma, hanya karena browser belum tahu kalau gambar itu ada!

Penyebab umumnya:

  • Gambar LCP menggunakan CSS background-image (nggak bisa ditemukan preload scanner)
  • Client-side rendering — elemen LCP baru muncul setelah JavaScript dieksekusi
  • Gambar LCP di-lazy load (kesalahan fatal yang sangat umum!)
  • HTML terlalu besar sehingga gambar baru ditemukan setelah beberapa round-trip

3. Resource Load Duration

Ini waktu aktual untuk mengunduh resource LCP — gambar, video, atau font. Fase ini sangat dipengaruhi oleh ukuran file dan kondisi jaringan.

Menariknya (dan ini sering bikin kaget developer), banyak developer terlalu fokus pada fase ini — kompres gambar, ganti format, optimasi sana-sini — padahal Resource Load Delay sering kali jadi bottleneck yang jauh lebih besar. Jadi pastikan kamu cek sub-part yang benar sebelum mulai optimasi.

4. Element Render Delay

Fase terakhir: waktu dari selesainya download resource hingga elemen benar-benar di-paint di layar. Ini bukan masalah jaringan — ini masalah main thread.

Penyebab utamanya:

  • Stylesheet besar yang masih loading (CSS bersifat render-blocking secara default)
  • Chain @import dalam CSS yang memperpanjang waktu blocking
  • JavaScript yang mendominasi main thread dan mencegah browser melakukan paint

Google merekomendasikan agar Resource Load Delay dan Element Render Delay masing-masing hanya menyumbang kurang dari 10% dari total waktu LCP. Kalau lebih dari itu, kamu tahu di mana harus fokus.

Cara Mengidentifikasi Elemen dan Sub-Part LCP yang Bermasalah

Sebelum mulai optimasi, kamu harus tahu persis apa elemen LCP di halaman kamu dan sub-part mana yang jadi bottleneck. Jangan asal tebak — diagnosa dulu, baru obati.

Menggunakan Chrome DevTools

Buka Chrome DevTools, masuk ke tab Performance, dan rekam loading halaman. Setelah selesai, cari entry "Largest Contentful Paint" di timeline. Klik untuk melihat detail elemen LCP beserta breakdown sub-parts-nya.

Kamu juga bisa pakai JavaScript API untuk mengidentifikasi elemen LCP secara programatis:

// Identifikasi elemen LCP menggunakan PerformanceObserver
const lcpObserver = new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();
  const lastEntry = entries[entries.length - 1];

  console.log('LCP Element:', lastEntry.element);
  console.log('LCP Time:', lastEntry.startTime, 'ms');
  console.log('LCP Size:', lastEntry.size);
  console.log('LCP URL:', lastEntry.url || 'Text node');

  // Breakdown sub-parts (jika tersedia)
  if (lastEntry.url) {
    const ttfb = performance.getEntriesByType('navigation')[0].responseStart;
    const resourceEntry = performance.getEntriesByName(lastEntry.url)[0];

    if (resourceEntry) {
      console.log('--- Sub-Parts Breakdown ---');
      console.log('TTFB:', ttfb.toFixed(0), 'ms');
      console.log('Resource Load Delay:',
        (resourceEntry.requestStart - ttfb).toFixed(0), 'ms');
      console.log('Resource Load Duration:',
        (resourceEntry.responseEnd - resourceEntry.requestStart).toFixed(0), 'ms');
      console.log('Element Render Delay:',
        (lastEntry.startTime - resourceEntry.responseEnd).toFixed(0), 'ms');
    }
  }
});

lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });

Menggunakan Lighthouse dan PageSpeed Insights

Lighthouse menampilkan elemen LCP beserta rincian sub-part dalam diagnostik "Largest Contentful Paint element". PageSpeed Insights memberikan data lapangan (field data) dari Chrome User Experience Report yang menunjukkan performa LCP di dunia nyata — dan ini yang benar-benar penting karena data inilah yang dipakai Google untuk ranking.

Optimasi Sub-Part 1: Memperbaiki TTFB

TTFB adalah fondasi dari seluruh optimasi LCP. Kalau fondasinya buruk, semua optimasi di atasnya jadi kurang efektif. Jadi kita mulai dari sini.

Implementasi CDN

CDN menyajikan konten dari server terdekat dengan pengguna. Kalau pengguna di Jakarta mengakses server di Virginia, latensi bolak-balik bisa menambah ratusan milidetik. Itu waktu yang terbuang cuma karena jarak fisik.

# Contoh konfigurasi Nginx untuk CDN caching
location ~* \.(jpg|jpeg|png|gif|webp|avif|svg|css|js)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    add_header CDN-Cache-Status $upstream_cache_status;
}

# Untuk HTML - cache lebih pendek dengan stale-while-revalidate
location / {
    add_header Cache-Control "public, max-age=60, stale-while-revalidate=86400";
}

Server-Side Caching

Cache yang dikonfigurasi dengan baik bisa memangkas TTFB dari 2 detik menjadi di bawah 100ms. Serius, perbedaannya bisa sedramatis itu.

# Contoh Redis caching untuk response HTML (Node.js/Express)
const redis = require('redis');
const client = redis.createClient();

async function cachedResponse(req, res, next) {
  const cacheKey = `page:${req.originalUrl}`;

  try {
    const cached = await client.get(cacheKey);
    if (cached) {
      res.set('X-Cache', 'HIT');
      return res.send(cached);
    }
  } catch (err) {
    // Cache miss - lanjutkan ke handler berikutnya
  }

  // Override res.send untuk menyimpan ke cache
  const originalSend = res.send.bind(res);
  res.send = async (body) => {
    await client.set(cacheKey, body, { EX: 300 }); // Cache 5 menit
    res.set('X-Cache', 'MISS');
    originalSend(body);
  };

  next();
}

Menghilangkan Redirect Berlebihan

Setiap redirect menambahkan satu round-trip penuh ke waktu TTFB. Redirect umum yang harus diminimalkan:

  • http:// → https:// (konfigurasi HSTS untuk menghindari ini)
  • example.com → www.example.com (pilih satu dan konsisten)
  • Redirect marketing tracker yang berantai
# HSTS header untuk menghilangkan redirect HTTP ke HTTPS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Optimasi Sub-Part 2: Menghilangkan Resource Load Delay

Ini sub-part yang paling sering jadi bottleneck tersembunyi — dan kabar baiknya, ini juga yang paling mudah diperbaiki. Strateginya simpel: pastikan URL resource LCP bisa ditemukan oleh preload scanner.

Gunakan fetchpriority="high" pada Gambar LCP

Secara default, gambar dimuat dengan prioritas rendah oleh browser. Baru setelah layout selesai, browser menaikkan prioritas gambar yang terlihat di viewport — tapi pada titik itu, sudah terlambat.

<!-- SALAH: Gambar LCP tanpa priority hint -->
<img src="hero-banner.webp" alt="Hero Banner">

<!-- BENAR: Gambar LCP dengan fetchpriority -->
<img src="hero-banner.webp"
     fetchpriority="high"
     width="1200"
     height="600"
     alt="Hero Banner">

Data dari studi kasus Google menunjukkan bahwa fetchpriority="high" bisa meningkatkan LCP dari 2,6 detik menjadi 1,9 detik. Etsy mencatat peningkatan 4%, dan beberapa situs melaporkan peningkatan hingga 20-30%. Cuma satu atribut HTML, dan hasilnya bisa sebesar itu.

Peringatan penting: Jangan berlebihan menggunakan fetchpriority="high". Kalau semua resource diprioritaskan tinggi, nggak ada yang benar-benar prioritas. Gunakan hanya untuk 1-2 elemen paling kritis.

Preload untuk CSS Background Image

Kalau elemen LCP kamu menggunakan CSS background-image, browser nggak bisa menemukannya lewat preload scanner. Solusinya: gunakan <link rel="preload">.

<head>
  <!-- Preload gambar background yang jadi elemen LCP -->
  <link rel="preload"
        as="image"
        href="/images/hero-bg.avif"
        type="image/avif"
        fetchpriority="high">

  <!-- Dengan responsive preload untuk berbagai ukuran layar -->
  <link rel="preload"
        as="image"
        href="/images/hero-mobile.webp"
        type="image/webp"
        media="(max-width: 768px)"
        fetchpriority="high">
  <link rel="preload"
        as="image"
        href="/images/hero-desktop.webp"
        type="image/webp"
        media="(min-width: 769px)"
        fetchpriority="high">
</head>

Jangan Pernah Lazy-Load Elemen LCP!

Ini kesalahan yang sangat umum dan sangat fatal. Saya sudah melihat ini di puluhan website yang kami audit — developer secara otomatis menambahkan loading="lazy" ke semua gambar, termasuk gambar hero. Data dari Chrome UX Report menunjukkan bahwa situs yang melakukan lazy-loading pada elemen LCP mengalami LCP 35% lebih lambat.

<!-- SALAH: Lazy loading pada gambar hero (LCP element) -->
<img src="hero.webp" loading="lazy" alt="Hero">

<!-- BENAR: Eager loading + fetchpriority pada gambar hero -->
<img src="hero.webp"
     loading="eager"
     fetchpriority="high"
     decoding="async"
     width="1200"
     height="600"
     alt="Hero">

<!-- Lazy loading HANYA untuk gambar di bawah fold -->
<img src="product-thumbnail.webp"
     loading="lazy"
     decoding="async"
     width="400"
     height="300"
     alt="Product">

Optimasi Sub-Part 3: Memperkecil Resource Load Duration

Oke, setelah memastikan resource LCP ditemukan lebih awal, langkah selanjutnya adalah memperkecil ukuran file yang harus diunduh. Bagian ini mungkin yang paling familiar buat kebanyakan developer.

Gunakan Format Gambar Modern: AVIF dan WebP

Angka-angka ini berbicara sendiri:

  • AVIF: Hingga 60% lebih kecil dari JPEG dengan kualitas visual yang setara
  • WebP: 25-34% lebih kecil dari JPEG dengan kualitas yang sama
  • WebP lossless: 26% lebih kecil dari PNG

Gunakan elemen <picture> untuk menyajikan format terbaik yang didukung browser:

<picture>
  <!-- AVIF: format paling efisien (dukungan browser terus bertambah) -->
  <source srcset="hero.avif" type="image/avif">

  <!-- WebP: fallback dengan dukungan yang sangat luas -->
  <source srcset="hero.webp" type="image/webp">

  <!-- JPEG: fallback terakhir untuk browser lama -->
  <img src="hero.jpg"
       fetchpriority="high"
       width="1200"
       height="600"
       alt="Hero Banner"
       decoding="async">
</picture>

Responsive Images dengan srcset

Jangan paksa pengguna mobile mengunduh gambar berukuran desktop — itu pemborosan bandwidth yang nggak perlu. Gunakan srcset untuk menyajikan ukuran yang tepat:

<img srcset="hero-400w.webp 400w,
             hero-800w.webp 800w,
             hero-1200w.webp 1200w,
             hero-1600w.webp 1600w"
     sizes="(max-width: 768px) 100vw,
            (max-width: 1200px) 80vw,
            1200px"
     src="hero-1200w.webp"
     fetchpriority="high"
     width="1200"
     height="600"
     alt="Hero Banner"
     decoding="async">

Kompresi Agresif Tanpa Mengorbankan Kualitas

Untuk gambar hero, kualitas 75-80% biasanya nggak bisa dibedakan mata dari 100%, tapi ukuran filenya bisa turun drastis. Ini salah satu quick win yang paling gampang diterapkan.

# Menggunakan Sharp (Node.js) untuk konversi batch
const sharp = require('sharp');

async function optimizeHeroImage(inputPath, outputDir) {
  const image = sharp(inputPath);
  const metadata = await image.metadata();

  // Generate AVIF
  await image
    .resize(1200, 600, { fit: 'cover' })
    .avif({ quality: 75, effort: 6 })
    .toFile(`${outputDir}/hero.avif`);

  // Generate WebP
  await image
    .resize(1200, 600, { fit: 'cover' })
    .webp({ quality: 80, effort: 6 })
    .toFile(`${outputDir}/hero.webp`);

  // Generate responsive sizes
  const widths = [400, 800, 1200, 1600];
  for (const w of widths) {
    const h = Math.round((w / metadata.width) * metadata.height);
    await image
      .resize(w, h, { fit: 'cover' })
      .webp({ quality: 80 })
      .toFile(`${outputDir}/hero-${w}w.webp`);
  }
}

optimizeHeroImage('./original-hero.jpg', './public/images');

Targetkan ukuran file di bawah 100KB untuk gambar hero. Dengan AVIF di kualitas 80%, gambar 1MB bisa menjadi hanya 46KB — penghematan 95%!

Optimasi Sub-Part 4: Mengurangi Element Render Delay

Resource sudah diunduh, tapi browser masih belum menampilkannya? Itu berarti main thread terlalu sibuk. Mari kita perbaiki.

Inline Critical CSS

CSS bersifat render-blocking secara default. Browser nggak akan mem-paint piksel apa pun sampai semua CSS di <head> selesai diunduh dan di-parse. Solusinya: inline CSS kritis yang dibutuhkan untuk above-the-fold content.

<head>
  <!-- Critical CSS di-inline langsung -->
  <style>
    /* Hanya CSS yang diperlukan untuk above-the-fold */
    .hero { position: relative; width: 100%; aspect-ratio: 2/1; }
    .hero img { width: 100%; height: 100%; object-fit: cover; }
    .hero-title { position: absolute; bottom: 2rem; left: 2rem;
                  color: white; font-size: clamp(1.5rem, 4vw, 3rem); }
    /* ... minimal CSS lainnya untuk above-the-fold ... */
  </style>

  <!-- CSS non-kritis dimuat secara async -->
  <link rel="preload" href="/css/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/main.css"></noscript>
</head>

Hindari CSS @import Chain

Setiap @import dalam CSS menciptakan request berantai yang memperpanjang waktu blocking. Ini salah satu anti-pattern yang masih sering ditemui di banyak codebase:

/* SALAH: Chain @import yang memperlambat rendering */
/* main.css */
@import url('reset.css');
@import url('typography.css');
@import url('layout.css');

/* BENAR: Gunakan link tag terpisah di HTML */
/* Semua file diunduh secara paralel */
<!-- Load semua CSS secara paralel, bukan berantai -->
<link rel="stylesheet" href="/css/reset.css">
<link rel="stylesheet" href="/css/typography.css">
<link rel="stylesheet" href="/css/layout.css">

Defer JavaScript Non-Kritis

JavaScript yang berjalan di main thread bisa menunda paint. Pastikan script non-kritis nggak menghalangi rendering:

<!-- Script analytics, chat widget, dll. WAJIB di-defer -->
<script src="/js/analytics.js" defer></script>
<script src="/js/chat-widget.js" defer></script>

<!-- Atau gunakan dynamic import untuk loading yang lebih terkontrol -->
<script type="module">
  // Load chat widget setelah halaman selesai loading
  window.addEventListener('load', async () => {
    const { initChat } = await import('/js/chat-widget.js');
    initChat();
  });
</script>

Strategi Bonus: Eliminasi LCP dengan Speculation Rules API

Untuk navigasi antar halaman, ada satu teknik yang bisa mengeliminasi LCP hampir sepenuhnya: Speculation Rules API. Dengan melakukan prerender halaman tujuan, semua empat sub-parts LCP — TTFB, Resource Load Delay, Resource Load Duration, Element Render Delay — secara efektif menjadi mendekati nol dari perspektif pengguna. Kedengarannya terlalu bagus? Memang begitulah kenyataannya.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Kami sudah membahas Speculation Rules API secara lengkap di artikel sebelumnya. Teknik ini sangat efektif untuk multi-page applications dan bisa mengurangi LCP dari 3,1 detik menjadi 0,4 detik untuk navigasi berikutnya. Worth checking out kalau kamu belum baca.

Template HTML Optimal untuk LCP Terbaik

Berikut template lengkap yang menggabungkan semua teknik optimasi yang sudah kita bahas. Kamu bisa pakai ini sebagai starting point untuk proyek baru atau sebagai referensi saat mengaudit halaman yang sudah ada:

<!DOCTYPE html>
<html lang="id">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <!-- 1. HSTS untuk menghilangkan redirect HTTP -->
  <!-- (dikonfigurasi di server, bukan di HTML) -->

  <!-- 2. Preconnect ke CDN/origin gambar -->
  <link rel="preconnect" href="https://cdn.example.com" crossorigin>

  <!-- 3. Preload gambar LCP (untuk CSS background) -->
  <link rel="preload" as="image" href="/images/hero.avif"
        type="image/avif" fetchpriority="high">

  <!-- 4. Critical CSS inline -->
  <style>
    *, *::before, *::after { box-sizing: border-box; margin: 0; }
    .hero { position: relative; width: 100%; aspect-ratio: 2/1; }
    .hero img { width: 100%; height: 100%; object-fit: cover; display: block; }
  </style>

  <!-- 5. Non-critical CSS async -->
  <link rel="preload" href="/css/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/main.css"></noscript>

  <title>Halaman dengan LCP Optimal</title>
</head>
<body>
  <!-- 6. Elemen LCP: gambar hero dengan fetchpriority -->
  <section class="hero">
    <picture>
      <source srcset="/images/hero.avif" type="image/avif">
      <source srcset="/images/hero.webp" type="image/webp">
      <img src="/images/hero.jpg"
           fetchpriority="high"
           loading="eager"
           decoding="async"
           width="1200"
           height="600"
           alt="Deskripsi gambar hero">
    </picture>
  </section>

  <!-- Konten utama -->
  <main>
    <!-- Gambar di bawah fold: lazy load -->
    <img src="/images/content.webp"
         loading="lazy"
         decoding="async"
         width="800" height="400"
         alt="Konten">
  </main>

  <!-- 7. JavaScript non-kritis di-defer -->
  <script src="/js/app.js" defer></script>
  <script src="/js/analytics.js" defer></script>

  <!-- 8. Speculation Rules untuk navigasi instan -->
  <script type="speculationrules">
  {
    "prerender": [{
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }]
  }
  </script>
</body>
</html>

Checklist Optimasi LCP 2026

Gunakan checklist ini untuk memastikan kamu sudah mengoptimasi semua aspek LCP. Saya sarankan untuk bookmark halaman ini dan cek ulang setiap kali kamu meluncurkan halaman baru:

  1. TTFB < 800ms: Gunakan CDN, aktifkan server caching, hilangkan redirect berlebihan
  2. Resource Load Delay < 10% dari total LCP: Pastikan gambar LCP bisa ditemukan preload scanner, gunakan fetchpriority="high", jangan lazy-load elemen LCP
  3. Resource Load Duration minimal: Konversi ke AVIF/WebP, gunakan responsive images, targetkan < 100KB per gambar hero
  4. Element Render Delay < 10% dari total LCP: Inline critical CSS, hindari CSS @import chain, defer JavaScript non-kritis
  5. Ukur sebelum dan sesudah: Gunakan PageSpeed Insights, Lighthouse, atau DebugBear untuk memverifikasi peningkatan
  6. Monitor data lapangan: Cek Chrome User Experience Report untuk data real-user, bukan hanya lab data

Kesalahan Umum yang Harus Dihindari

Dari pengalaman kami mengoptimasi ratusan website, berikut kesalahan yang paling sering kami temui (dan yang paling bikin geleng-geleng kepala):

  • Lazy-loading gambar hero: Ini kesalahan paling fatal. Gambar LCP TIDAK BOLEH di-lazy load. Titik.
  • Overuse fetchpriority="high": Kalau semua resource diberi prioritas tinggi, nggak ada yang benar-benar prioritas
  • Mengabaikan TTFB: Semua optimasi frontend sia-sia kalau server response time sudah 3+ detik
  • Hanya fokus pada kompresi gambar: Resource Load Delay sering kali jadi bottleneck yang lebih besar daripada ukuran file
  • Menggunakan CSS background-image untuk hero tanpa preload: Preload scanner nggak bisa menemukan URL di CSS
  • Terlalu banyak third-party script di head: Analytics, A/B testing, tag manager — semua ini bisa memblokir rendering kalau nggak di-defer

FAQ: Pertanyaan yang Sering Diajukan tentang LCP

Apa perbedaan antara LCP dan FCP (First Contentful Paint)?

FCP mengukur waktu hingga elemen pertama (apa pun itu) di-render di layar, termasuk teks kecil atau ikon loading. LCP mengukur waktu hingga elemen konten terbesar di viewport selesai di-render. Sederhananya: FCP memberikan gambaran "kapan sesuatu mulai muncul", sedangkan LCP menunjukkan "kapan konten utama sudah terlihat". Keduanya penting, tapi LCP lebih berkorelasi dengan persepsi pengguna tentang kecepatan loading.

Apakah LCP hanya berlaku untuk gambar?

Nggak! LCP bisa berupa elemen apa pun yang menjadi konten terbesar di viewport saat loading. Ini bisa berupa gambar (<img>), video poster (<video>), elemen dengan CSS background-image, atau blok teks besar seperti heading (<h1>) atau paragraf (<p>). Kalau LCP kamu berupa teks, maka hanya ada dua sub-parts yang relevan: TTFB dan Render Delay (tanpa Resource Load Delay dan Resource Load Duration).

Berapa skor LCP yang ideal di tahun 2026?

Ambang batas resmi Google tetap ≤ 2,5 detik untuk kategori "Good". Namun secara jujur, banyak pakar SEO dan web performance merekomendasikan untuk menargetkan di bawah 2 detik agar tetap kompetitif di 2026. Google terus memperketat standar Core Web Vitals, jadi lebih baik punya margin. Website dengan LCP di bawah 1,5 detik punya keunggulan signifikan dalam ranking dan user experience.

Mengapa skor LCP saya berbeda di Lighthouse dan data lapangan (CrUX)?

Ini pertanyaan yang sangat bagus dan sering bikin bingung. Lighthouse menjalankan tes di lingkungan lab dengan kondisi terkontrol (koneksi jaringan tertentu, perangkat simulasi), sedangkan data lapangan dari Chrome User Experience Report (CrUX) mencerminkan pengalaman pengguna nyata dengan berbagai kondisi jaringan, perangkat, dan lokasi geografis. Perbedaan ini normal — fokuslah pada data lapangan karena itulah yang digunakan Google untuk ranking. Gunakan Lighthouse untuk diagnosis dan debugging.

Apakah menggunakan framework JavaScript seperti React atau Next.js memperburuk LCP?

Tergantung konfigurasinya. Client-side rendering (CSR) murni bisa sangat memperburuk LCP karena elemen LCP baru muncul setelah JavaScript bundle diunduh dan dieksekusi. Solusinya: gunakan Server-Side Rendering (SSR) atau Static Site Generation (SSG) yang tersedia di Next.js, Nuxt, Astro, dan framework modern lainnya. Dengan SSR/SSG, HTML sudah berisi elemen LCP sejak awal, sehingga browser bisa mulai merender tanpa menunggu JavaScript. Jadi bukan framework-nya yang jadi masalah — tapi bagaimana kamu menggunakannya.

Tentang Penulis Editorial Team

Our team of expert writers and editors.

Artikel Terkait