LCP optimizacija u 2026: Kako ubrzati Largest Contentful Paint kroz 4 ključne faze

Uvod: Zašto LCP i dalje ostaje najvažnija metrika web performansi

Largest Contentful Paint (LCP) mjeri koliko brzo se učitava najveći vidljivi element na stranici — bila to hero slika, naslov ili video. Google smatra LCP jednom od tri ključne Core Web Vitals metrike, a prag je prilično jasan: ispod 2,5 sekundi za "dobru" ocjenu. Sve iznad 4 sekunde? To je "loše" i direktno vam ruši SEO rangiranje.

Prema HTTP Archive Web Almanac istraživanju, samo 59% mobilnih stranica globalno postiže dobru LCP ocjenu. Dakle, gotovo polovica weba još uvijek ne ispunjava Googleov standard — a tu leži vaša prilika za konkurentsku prednost.

Ali evo ključne stvari koju većina developera propušta: LCP nije jedna monolitna metrika.

Google je LCP podijelio na četiri podfaze, i svaka zahtijeva potpuno drugačiji pristup optimizaciji. Optimizirati krivu fazu znači — iskreno — baciti vrijeme u vjetar. Vidio sam timove koji tjednima rade na kompresiji slika dok im pravi problem sjedi u TTFB-u. Frustrirajuće.

U ovom vodiču ćemo rastaviti LCP na dijelove, dijagnosticirati koja faza uzrokuje probleme na vašim stranicama, i primijeniti konkretne popravke s radnim kodom za svaku fazu. Krenimo.

Anatomija LCP-a: 4 podfaze koje morate razumjeti

Svako LCP mjerenje sastoji se od četiri uzastopne faze. Razumijevanje ove raščlambe je ključno jer vas štedi od nasumičnog optimiziranja — umjesto toga, ciljate točno ono što je usko grlo.

1. Time to First Byte (TTFB)

Vrijeme od početka navigacije do primitka prvog bajta HTML dokumenta sa servera. Obuhvaća DNS rezoluciju, TCP/TLS uspostavu veze i serversku obradu zahtjeva. Ovo je temeljna faza — ako je TTFB spor, sve ostalo kasni.

Prema CrUX podacima, barem polovica stranica s lošim LCP-om ima p75 TTFB od 2.270 milisekundi. To samo po sebi gotovo garantira da LCP neće pasti ispod praga od 2,5 sekundi. Ozbiljno.

2. Resource Load Delay (kašnjenje učitavanja resursa)

Vrijeme između završetka TTFB-a i trenutka kada preglednik započne preuzimanje LCP resursa. Ovo nije vrijeme preuzimanja — ovo je koliko dugo preglednik čeka prije nego uopće shvati da LCP resurs postoji.

I tu dolazi iznenađujući podatak. Analiza stvarnih korisničkih podataka pokazuje da medijalna stranica s lošim LCP-om čeka gotovo četiri puta dulje na početak preuzimanja LCP slike nego što samo preuzimanje traje — otprilike 1,3 sekunde između TTFB-a i zahtjeva za sliku. To je više od polovice LCP budžeta od 2,5 sekundi potrošeno samo na čekanje. Čekanje!

3. Resource Load Duration (trajanje učitavanja resursa)

Koliko dugo traje samo preuzimanje LCP resursa (slike, fonta ili videa). Ova faza ovisi o veličini datoteke i mrežnim uvjetima.

Zanimljivo je da u mnogim stvarnim slučajevima gdje je Resource Load Delay dominantni problem, samo preuzimanje čini manje od 10% ukupnog LCP rezultata. Dakle, veličina datoteke često uopće nije pravi krivac.

4. Element Render Delay (kašnjenje iscrtavanja elementa)

Vrijeme od završetka preuzimanja LCP resursa do trenutka kada je LCP element stvarno vidljiv na zaslonu. Google preporučuje da ova faza čini oko 10% ukupnog LCP budžeta.

No, u jednom laboratorijskom testu koji simulira sporu mobilnu vezu, od ukupnih 4,66 sekundi LCP-a, Render Delay je činio 3,23 sekunde — 69% ukupnog vremena. Blokiranje iscrtavanja je tihi ubojica performansi, i jako ga je lako previdjeti.

Poseban slučaj: tekstualni LCP elementi

Ako je LCP element tekstualni čvor (npr. <h1> renderiran sistemskim fontom), tada LCP ima samo dvije podfaze: TTFB i Render Delay. Resource Load Delay i Resource Load Duration su nula jer nema resursa za preuzimanje. Jednostavno — ali to ne znači da je optimizacija trivijalna.

Korak 1: Dijagnosticiranje vašeg LCP uskog grla

Prije nego što počnete optimizirati, morate znati što optimizirati. Ovo je korak koji mnogi preskaču, a onda se čude zašto im promjene ne donose rezultate.

Mjerenje LCP podfaza u pregledniku

Koristeći Performance Observer API i Navigation Timing, možete precizno izmjeriti svaku podfazu. Evo koda koji to radi:

// Mjerenje LCP podfaza
function measureLCPSubparts() {
  const lcpObserver = new PerformanceObserver((list) => {
    const entries = list.getEntries();
    const lcpEntry = entries[entries.length - 1];

    const navEntry = performance.getEntriesByType('navigation')[0];

    // 1. TTFB
    const ttfb = navEntry.responseStart - navEntry.startTime;

    // 2. Resource Load Delay
    let resourceLoadDelay = 0;
    let resourceLoadDuration = 0;

    if (lcpEntry.url) {
      // LCP element ima resurs (slika/video)
      const lcpResource = performance.getEntriesByType('resource')
        .find(r => r.name === lcpEntry.url);

      if (lcpResource) {
        resourceLoadDelay = lcpResource.requestStart - navEntry.responseStart;
        resourceLoadDuration = lcpResource.responseEnd - lcpResource.requestStart;
      }
    }

    // 3. Element Render Delay
    const renderDelay = lcpEntry.startTime - (
      lcpEntry.url
        ? performance.getEntriesByType('resource')
            .find(r => r.name === lcpEntry.url)?.responseEnd || navEntry.responseEnd
        : navEntry.responseEnd
    );

    console.log('=== LCP Podfaze ===');
    console.log('TTFB:', ttfb.toFixed(0), 'ms');
    console.log('Resource Load Delay:', resourceLoadDelay.toFixed(0), 'ms');
    console.log('Resource Load Duration:', resourceLoadDuration.toFixed(0), 'ms');
    console.log('Element Render Delay:', renderDelay.toFixed(0), 'ms');
    console.log('Ukupni LCP:', lcpEntry.startTime.toFixed(0), 'ms');
    console.log('LCP element:', lcpEntry.element?.tagName, lcpEntry.url || '[tekst]');
  });

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

measureLCPSubparts();

Korištenje Lighthouse-a i PageSpeed Insights-a

Lighthouse od verzije 10+ prikazuje LCP raščlambu izravno u izvještaju pod kategorijom "Diagnostics". PageSpeed Insights isto prikazuje četiri podfaze za svaku analiziranu stranicu — potražite sekciju "Largest Contentful Paint element" i odmah ćete vidjeti koliko svaka faza doprinosi ukupnom LCP-u.

Korištenje Chrome DevTools-a

U Chrome DevTools-u otvorite Performance panel, snimite učitavanje stranice i u "Timings" traci pronađite LCP marker. Klikom na njega dobivate detalje o LCP elementu i vremenu. Za dublje razumijevanje, Network panel vam pomaže identificirati kašnjenja u preuzimanju LCP resursa.

Korak 2: Optimizacija TTFB-a — Temelj brzog LCP-a

Ako TTFB čini više od 40% vašeg ukupnog LCP-a, ovo je vaš prioritet broj jedan. Bez brzog TTFB-a, sve ostale optimizacije su zapravo kozmetika.

CDN i edge caching

Implementacija CDN-a smanjuje fizičku udaljenost između korisnika i servera. U 2026., edge computing platforme poput Cloudflare Workers-a rade na preko 300 lokacija globalno i mogu smanjiti TTFB za 60–80% za međunarodne korisnike. To je ogroman dobitak za relativno malo posla.

# Nginx konfiguracija za agresivno keširanje na originu
location / {
    proxy_pass http://backend;
    proxy_cache_valid 200 1h;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503;

    # stale-while-revalidate za HTML stranice
    add_header Cache-Control "public, max-age=60, stale-while-revalidate=3600";

    # Brotli kompresija za HTML
    brotli on;
    brotli_types text/html text/css application/javascript;
}

# Statički resursi - dugoročno keširanje
location ~* \.(css|js|woff2|avif|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Server-side rendering i keširanje

Ako koristite framework poput Next.js-a, Nuxt-a ili Astro-a, server-side rendering (SSR) s keširanjem dramatično poboljšava TTFB. Statički generirane stranice (SSG) imaju najbrži TTFB jer se HTML servira izravno iz keša — nema čekanja na bazu, nema serverske obrade.

// Next.js - ISR (Incremental Static Regeneration)
// Kombinacija brzog TTFB-a i svježeg sadržaja
export async function getStaticProps() {
  const data = await fetchPageData();

  return {
    props: { data },
    revalidate: 3600, // Regeneriraj svakih sat vremena
  };
}

// Astro - statička generacija s nultim JS-om
// astro.config.mjs
export default defineConfig({
  output: 'static',
  adapter: cloudflare(),
  build: {
    inlineStylesheets: 'auto',
  },
});

Optimizacija baze podataka i backend-a

Svaki nepotrebni upit bazi podataka dodaje milisekunde TTFB-u. Implementirajte keširanje na razini aplikacije (Redis, Memcached) za često korištene podatke. Profilirajte spore upite koristeći alate poput EXPLAIN ANALYZE u PostgreSQL-u ili slow_query_log u MySQL-u. Ponekad je jedan loše napisani upit krivac za cijeli TTFB problem.

Korak 3: Smanjivanje Resource Load Delay-a — Najčešće zanemaren problem

E sad, ovo je faza koja čini najveću štetu na većini stranica, a istovremeno je najčešće zanemarena. Problem je iznenađujuće jednostavan: preglednik prekasno otkriva da LCP resurs uopće postoji.

Zašto preglednik kasno otkriva LCP sliku?

Preglednik ima ugrađeni preload scanner koji čita HTML u potrazi za resurse za preuzimanje. No, ovaj skener ne može otkriti:

• CSS background slike — definirane u stylesheetima, ne u HTML-u
• Slike učitane putem JavaScripta — dinamički umetnute u DOM
• Slike unutar shadow DOM-a — nedostupne preload skeneru
• Slike u klijentski renderiranim komponentama — čekaju na JS izvršavanje

Sve ovo znači da preglednik doslovno ne zna da slika postoji dok ne bude prekasno.

Rješenje 1: Koristite fetchpriority="high" na LCP slici

Atribut fetchpriority signalizira pregledniku relativnu važnost resursa. Po defaultu, slike u vidljivom dijelu stranice počinju s "Low" prioritetom i naknadno se unapređuju na "High" tek nakon što preglednik završi s layoutom. Atribut fetchpriority="high" preskače taj proces i odmah postavlja visoki prioritet pri otkrivanju.

Podrška preglednika u 2026. je odlična: Chrome 102+, Safari 17.2+, Firefox 132+ i Edge. A u starijim preglednicima? Atribut se jednostavno ignorira — nema nikakvih negativnih posljedica.

<!-- DOBRO: LCP slika s visokim prioritetom -->
<img
  src="/hero-image.avif"
  alt="Opis hero slike"
  width="1200"
  height="630"
  fetchpriority="high"
>

<!-- LOŠE: Lazy loading na LCP slici — najčešća greška! -->
<img
  src="/hero-image.avif"
  alt="Opis hero slike"
  loading="lazy"
>

Rezultati govore sami za sebe: Etsy je poboljšao LCP za 4% samo dodavanjem fetchpriority-ja, a Google Flights je spustio LCP s 2,6 na 1,9 sekundi. Neki testovi pokazuju poboljšanja i do 20–30%. Za jednu liniju HTML-a — to je odličan povrat.

Rješenje 2: Preload za slike koje preglednik ne može rano otkriti

Ako je vaša LCP slika CSS background, dinamički učitana ili skrivena u komponentama, koristite <link rel="preload"> u <head> sekciji HTML-a:

<head>
  <!-- Preload LCP slike s fetchpriority -->
  <link
    rel="preload"
    as="image"
    href="/hero-image.avif"
    type="image/avif"
    fetchpriority="high"
  >

  <!-- Preload za responsive slike -->
  <link
    rel="preload"
    as="image"
    href="/hero-800.avif"
    imagesrcset="/hero-400.avif 400w,
                 /hero-800.avif 800w,
                 /hero-1200.avif 1200w"
    imagesizes="(max-width: 600px) 400px,
                (max-width: 1000px) 800px,
                1200px"
    fetchpriority="high"
  >
</head>

Razumijevanje razlike: preload vs. fetchpriority

Ovo zbunjuje dosta ljudi, pa da razjasnimo. Ove dvije tehnike rješavaju različite probleme:

• preload — utječe na kada se resurs otkriva i dodaje u red za preuzimanje. Rješava problem kasnog otkrivanja.
• fetchpriority — utječe na prioritet resursa jednom kada je u redu čekanja. Rješava problem niskog prioriteta.

Za LCP sliku, optimalna strategija je koristiti oboje zajedno: preload osigurava rano otkrivanje, a fetchpriority visoki prioritet u redu čekanja.

Rješenje 3: Zamijenite CSS background slike s <img> tagom

Background slike su nevidljive preload skeneru, što znači da ih uvijek procesira mnogo sporiji DOM parser. Dobra vijest — možete koristiti obični <img> tag s object-fit: cover za identičan vizualni efekt:

<!-- Umjesto CSS background slike -->
<style>
  .hero { position: relative; height: 500px; overflow: hidden; }
  .hero img {
    position: absolute;
    inset: 0;
    width: 100%;
    height: 100%;
    object-fit: cover;
  }
</style>

<div class="hero">
  <img
    src="/hero.avif"
    alt="Hero slika"
    width="1920"
    height="1080"
    fetchpriority="high"
  >
  <div class="hero-content">
    <h1>Naslov stranice</h1>
  </div>
</div>

Rješenje 4: Deprioritizirajte nekritične resurse

Svaki resurs s visokim prioritetom konkurira vašoj LCP slici za mrežnu propusnost. Koristite fetchpriority="low" na resursima koji nisu hitni:

<!-- Manje ikone i avatari u zaglavlju — snizite prioritet -->
<img src="/logo-small.svg" alt="Logo" fetchpriority="low" width="40" height="40">
<img src="/avatar.webp" alt="Profil" fetchpriority="low" width="32" height="32">

<!-- Slike ispod pregiba — lazy loading -->
<img src="/section-image.avif" alt="Sekcija" loading="lazy" width="800" height="400">

Korak 4: Optimizacija Resource Load Duration — Smanjite veličinu LCP resursa

Kada preglednik konačno počne preuzimati LCP resurs, želite da to preuzimanje bude što brže. Ovo je faza koja se najlakše optimizira — i vjerovatno ona s kojom ste već upoznati.

Moderni formati slika: AVIF i WebP

AVIF nudi do 50% manje datoteke u usporedbi s JPEG-om pri istoj vizualnoj kvaliteti. WebP je solidan fallback s oko 30% uštede. Koristite <picture> element za progresivno poboljšanje:

<picture>
  <source
    srcset="/hero-400.avif 400w,
            /hero-800.avif 800w,
            /hero-1200.avif 1200w"
    sizes="(max-width: 600px) 400px,
           (max-width: 1000px) 800px,
           1200px"
    type="image/avif"
  >
  <source
    srcset="/hero-400.webp 400w,
            /hero-800.webp 800w,
            /hero-1200.webp 1200w"
    sizes="(max-width: 600px) 400px,
           (max-width: 1000px) 800px,
           1200px"
    type="image/webp"
  >
  <img
    src="/hero-800.jpg"
    alt="Hero slika"
    width="1200"
    height="630"
    fetchpriority="high"
  >
</picture>

Responsive slike s srcset

Nemojte slati 1200px sliku na 400px zaslon — to je čisto bacanje bandwidtha. Koristite srcset i sizes atribute kako bi preglednik odabrao optimalnu veličinu slike za korisnikov uređaj.

CDN za LCP resurse

Serviranje LCP slike s CDN-a smanjuje latenciju preuzimanja. Moderne CDN mreže automatski konvertiraju slike u optimalne formate (Cloudflare Polish, Imgix, Cloudinary) i serviraju ih s najbližeg edge čvora. Ako već koristite CDN za HTML, provjerite da i slike idu preko istog ili sličnog CDN-a.

Korak 5: Eliminiranje Element Render Delay-a — Uklonite blokade iscrtavanja

LCP resurs je preuzet, ali element još nije vidljiv. Zašto? Zato što nešto blokira iscrtavanje stranice. Ovo je onaj frustrirajući scenarij gdje imate sve podatke, ali ih korisnik ne vidi.

Render-blocking CSS

Preglednici moraju parsirati sav CSS koji smatraju potrebnim prije prvog iscrtavanja. I to zapravo ima smisla — prikazivanje nestilizirane stranice bilo bi još gore (sjećate se FOUT-a?). Problem nastaje kada je previše CSS-a označeno kao kritično.

<head>
  <!-- Inline critical CSS - samo stilovi za above-the-fold sadržaj -->
  <style>
    .hero { position: relative; height: 500px; }
    .hero img { object-fit: cover; width: 100%; height: 100%; }
    h1 { font-size: 2.5rem; color: #1a1a1a; }
    /* ... samo stilovi vidljivi pri prvom učitavanju ... */
  </style>

  <!-- Ostatak CSS-a - async učitavanje -->
  <link
    rel="preload"
    href="/styles/main.css"
    as="style"
    onload="this.onload=null;this.rel='stylesheet'"
  >
  <noscript><link rel="stylesheet" href="/styles/main.css"></noscript>

  <!-- Print stilovi ne blokiraju rendering -->
  <link rel="stylesheet" href="/styles/print.css" media="print">
</head>

Render-blocking JavaScript

Skripte u <head> bez defer ili async atributa blokiraju parsiranje HTML-a, što odgađa i iscrtavanje LCP elementa. Ovo je nešto što se lako previdi, pogotovo kad dodajete treće strane poput analytics-a ili chat widgeta.

<head>
  <!-- LOŠE: Blokira parsiranje HTML-a -->
  <script src="/analytics.js"></script>

  <!-- DOBRO: defer - izvršava se tek nakon parsiranja HTML-a -->
  <script src="/analytics.js" defer></script>

  <!-- DOBRO: async - preuzima paralelno, izvršava čim je spreman -->
  <script src="/widget.js" async></script>

  <!-- DOBRO: module - ponašanje kao defer -->
  <script type="module" src="/app.js"></script>
</head>

Optimizacija web fontova

Ako je vaš LCP element tekst renderiran prilagođenim fontom, font mora biti preuzet prije iscrtavanja. Evo kako to ubrzati:

<head>
  <!-- Preload kritičnih fontova -->
  <link
    rel="preload"
    href="/fonts/heading.woff2"
    as="font"
    type="font/woff2"
    crossorigin
  >
</head>

<style>
  @font-face {
    font-family: 'Heading';
    src: url('/fonts/heading.woff2') format('woff2');
    font-display: swap; /* Prikaži fallback font odmah */
    font-weight: 700;
    unicode-range: U+0000-024F; /* Subset: samo latinski znakovi */
  }
</style>

Koristite isključivo WOFF2 format — komprimira 30% bolje od WOFF-a zahvaljujući Brotli kompresiji i podržan je u preko 97% preglednika. Atribut crossorigin je obavezan čak i za self-hosted fontove (da, ovo je česta zamka). A font-display: swap osigurava da tekst bude vidljiv odmah s fallback fontom dok se prilagođeni font učitava.

Praktični vodič: LCP optimizacija korak po korak

Ok, dosta teorije. Evo sistematičnog pristupa koji možete primijeniti na bilo koju stranicu, danas:

1. Identificirajte LCP element

Koristite Chrome DevTools → Performance panel ili PageSpeed Insights da saznate koji je element vaš LCP. Česti kandidati:

• Hero slika ili banner
• Najveći naslov (<h1>) na stranici
• Video poster slika
• Slika unutar carousel-a ili slidera

2. Izmjerite podfaze

Koristite kod iz prethodne sekcije ili alate poput DebugBear-a za vizualizaciju LCP podfaza. Identificirajte koja faza čini najveći postotak ukupnog LCP-a — tu ćete dobiti najviše od optimizacije.

3. Primijenite ciljane popravke

Na temelju dijagnoze, primijenite odgovarajuće popravke:

• Visok TTFB (>40% LCP-a) → CDN, server-side keširanje, edge computing
• Visok Resource Load Delay → fetchpriority="high", preload, izbjegavajte CSS background slike
• Visok Resource Load Duration → AVIF/WebP, responsive slike, CDN za resurse
• Visok Render Delay → Inline critical CSS, defer JS, font-display: swap

4. Mjerite i iterirajte

Nakon svake promjene, ponovite mjerenje. LCP optimizacija je iterativni proces — popravak jedne faze može otkriti usko grlo u drugoj. Ne pokušavajte sve popraviti odjednom.

Tablica pregleda: LCP podfaze, budžeti i popravci

Ova tablica sažima sve što trebate znati o svakoj LCP podfazi — korisna je kao referenca za brze provjere:

Podfaza	Preporučeni budžet	Indikator problema	Ključni popravak
TTFB	≤40% LCP-a	>800 ms na p75	CDN, edge caching, SSR/SSG
Resource Load Delay	Što bliže 0	>500 ms	fetchpriority, preload, izbjegavati background slike
Resource Load Duration	<10% LCP-a	Velika datoteka bez CDN-a	AVIF/WebP, srcset, CDN
Render Delay	~10% LCP-a	>500 ms	Inline critical CSS, defer JS, font-display: swap

Najčešće greške u LCP optimizaciji

Evo zamki na koje stalno nailazim u praksi — izbjegavajte ih:

• Lazy loading LCP slike — ovo je najčešća greška i vidim je svugdje. Atribut loading="lazy" na LCP slici aktivno šteti performansama jer odgađa preuzimanje dok element ne uđe u viewport. A LCP element je po definiciji u viewportu.
• Preoptimizacija veličine slike uz ignoriranje otkrivanja — možete komprimirati sliku do savršenstva, ali ako preglednik ne zna za nju do 2 sekunde nakon učitavanja, veličina datoteke je potpuno nebitna.
• Previše preload zahtjeva — svaki preload povećava natjecanje za propusnost. Preloadajte samo LCP sliku i kritične fontove. Sve ostalo je kontraproduktivno.
• Zanemarivanje TTFB-a — bez servera koji brzo odgovara, nijedna frontend optimizacija ne može nadoknaditi izgubljeno vrijeme. Ovo je fundament na kojem sve stoji.
• Korištenje velikih, nekomprimiranih fontova — četiri različita font weighta mogu dodati stotine kilobajta i blokirati iscrtavanje teksta. Koristite samo weightove koji vam stvarno trebaju.

Stvarni učinak LCP optimizacije na poslovanje

LCP optimizacija nije samo tehničko poboljšanje — ima mjerljive poslovne rezultate. I to je ono što u konačnici uvjerava menadžment da uloži vrijeme u performanse:

• Agrofy je poboljšao LCP za 70%, što je rezultiralo 76% smanjenjem napuštanja stranice (s 3,8% na 0,9%). Impresivno.
• Stranice koje prolaze sve tri Core Web Vitals metrike bilježe 24% nižu stopu napuštanja
• Google koristi Core Web Vitals kao signal rangiranja — bolji LCP znači bolju poziciju u pretraživanju

Često postavljana pitanja (FAQ)

Što je dobar LCP rezultat i kako ga mjeriti?

Dobar LCP rezultat je ispod 2,5 sekundi za barem 75% učitavanja stranice (p75). Rezultat između 2,5 i 4 sekunde zahtijeva poboljšanje, a sve iznad 4 sekunde smatra se lošim. Mjerite ga koristeći PageSpeed Insights za stvarne korisničke podatke (CrUX), Lighthouse za laboratorijska mjerenja, ili web-vitals.js biblioteku za vlastito praćenje u produkciji.

Zašto je moj LCP spor iako su slike optimizirane?

Jer optimizacija slika utječe samo na jednu od četiri LCP podfaze (Resource Load Duration). Vaš LCP može biti spor zbog visokog TTFB-a (spor server), kasnog otkrivanja slike (Resource Load Delay) ili blokiranja iscrtavanja CSS-om i JavaScriptom (Render Delay). Koristite dijagnostiku podfaza da pronađete pravo usko grlo — odgovor vas možda iznenadi.

Trebam li koristiti fetchpriority ili preload za LCP sliku?

Kratki odgovor: koristite oboje zajedno. Preload rješava problem kasnog otkrivanja resursa — govori pregledniku da započne preuzimanje čim je moguće. Fetchpriority rješava problem niskog prioriteta — osigurava da LCP slika dobije prednost nad ostalim resursima u redu čekanja. Zajedno pružaju najbolji rezultat.

Kako LCP funkcionira za single-page aplikacije (SPA)?

U SPA okruženjima, LCP se mjeri samo za inicijalno učitavanje stranice. Naknadne navigacije unutar aplikacije ne pokreću novo LCP mjerenje. To znači da je SSR ili SSG za početnu stranicu posebno važan u SPA aplikacijama jer klijentsko renderiranje značajno povećava i Resource Load Delay i Render Delay.

Koliko često Google ažurira Core Web Vitals metrike?

Google povremeno ažurira metrike i pragove. Najznačajnija nedavna promjena bila je zamjena FID-a s INP-om kao službenom metrikom odzivnosti u ožujku 2024. LCP i CLS ostaju stabilne metrike, ali Google kontinuirano poboljšava metodologiju mjerenja. Pratite web.dev/vitals za najnovije promjene — bolje biti u toku nego se iznenaditi.