Website speed SEO: performanse važne za rangiranje

Što je website speed SEO?

Website speed SEO je praksa smanjenja vremena i troška resursa između trenutka kad korisnik zatraži stranicu i trenutka kad stranica postane smisleno interaktivna i vizualno stabilna, s jasnim ciljem podrške search performansu i korisničkom iskustvu. Nije riječ o jednome metricu ili jednom alatu: obuhvaća karakteristike odgovora servera, dostavu resursa, renderiranje i percipirane performanse na različitim uređajima.

Koji metrički podaci o performansama su važni (i zašto)

Usredotoči se na metrike koje opisuju iskustvo stvarnih korisnika (field data) i one koje pomažu debugiranju renderiranja (lab data). Za SEO i page experience najrelevantniji mjerljivi signali u 2026. su:

• Largest Contentful Paint (LCP) — mjeri percipiranu brzinu učitavanja najvećeg vidljivog elementa; koristi Googleovu Core Web Vitals smjernicu za pragove.
• Interaction to Next Paint (INP) — field metrika za responzivnost koja je zamijenila FID; pokazuje koliko brzo stranica reagira na korisnički unos.
• Cumulative Layout Shift (CLS) — mjeri vizualnu stabilnost i neočekivane pomake layouta tijekom učitavanja.
• Time to First Byte (TTFB) and server response time — korisno za dijagnostiku sporog backend-a i njegov utjecaj na učinkovitost crawlanja.
• Total Blocking Time (TBT) u lab izvještajima — koristan kad stranica ima duge main-thread zadatke koji blokiraju interaktivnost.

Kad navodiš konkretne pragove, pripiši izvor u istoj rečenici. Na primjer: Google's Core Web Vitals guidance definira 'Good' pragove kao LCP ≤ 2.5s, INP < 200 ms i CLS < 0.1.

Kako performanse utječu na SEO mehanike

Razdvoji crawling, indexing i ranking kad razmišljaš o performansama. Svaka faza je pogođena drugačije:

Crawling

Brža vremena odgovora omogućujutražilice da preuzmu više stranica po crawl sesiji, što može poboljšati coverage za vrlo velike sajtove. Ako je origin spor ili se često time-outa, crawleri mogu smanjiti brzinu kojom traže stranice. Koristi server logove za korelaciju sporih odgovora s ponašanjem crawlера.

Indexing

Odluke o indeksiranju ovise o sadržaju koji je crawlan i renderiran. Budući da Google koristi mobilnu verziju kao primarnu osnovu za crawling and indexing, i po defaultu crawla s Googlebot Smartphone (prelazak je dovršen u July 2024), osiguraj da mobilni HTML i resursi prikazuju isti suštinski sadržaj kao desktop.

Ranking and user signals

Googleovi ranking sustavi koriste mnogo signala; page speed i Core Web Vitals su dio page experience signala, ali nisu jedini faktor. Brzina također utječe na metrike angažmana (bounce, time on page, konverzije) koje neizravno mogu utjecati na vidljivost u konkurentnim queries. Tretiraj brzinu kao komponentu koja pomaže sadržaju konkurirati na ravnopravnosti s bolje performirajućim sajtovima.

Mjeri: lab vs field i pravi alati

Koristi i lab i field podatke. Field data pokazuje stvarne korisnike na stvarnim mrežama; lab data reproducira uvjete na jednome stroju i ponovljiva je za debug. Kombiniraj alate za potpunu sliku.

• Field alati: PageSpeed Insights (field tab), Chrome Real User Metrics (CrUX) preko BigQuery ili third-party dashboarda, i Core Web Vitals report u Google Search Console za vlastita vlasništva.
• Lab alati: Lighthouse (u DevTools ili CLI), WebPageTest za kontrolirane network i device profile, i Chrome DevTools Performance panel za analizu trace-a.
• Brze provjere: curl za header-e i server timing, browser view-source i DevTools Elements da potvrdiš koji HTML se isporučuje, i server logove da vidiš stvarne crawler zahtjeve.

Primjeri naredbi i što rade:

• Inspekcija samo header-a: pokreni curl -I https://example.com/page što vraća response headers (bez body-a). Iskoristi to da potvrdiš status kodove, cache-control i server-timing header-e.
• Dohvati HTML kao mobilni user-agent: curl -A "Mozilla/5.0 (Linux; Android 10) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0" https://example.com/page da vidiš mobilni HTML koji tvoj server vraća. Ako koristiš samo -I, nećeš vidjeti HTML body.

Prioritetizacija: gdje početi na velikim sajtovima

Na velikim sajtovima ne možeš popraviti sve odjednom. Prioritetiziraj stranice prema SEO vrijednosti, prometu i važnosti za konverzije. Tipični koraci prioritetizacije:

1. Identificiraj URL-ove visokog značaja (top landing pages, money pages) koristeći svoju analitiku i Search Console Performance report.
2. Iskoristi field data da pronađeš stranice s lošim Core Web Vitals; ako je field data oskudna, pokreni reprezentativne lab testove za stranice sa sličnim templatom.
3. Popravi render-blocking probleme s velikim utjecajem (kritični CSS, blocking skripte), prevelike slike i spore serverske odgovore gdje utječu na mnogo stranica.
4. Primijeni poboljšanja na razini templata prije pojedinačnih izmjena po stranici da bi se skala benefita primijenila na stotine ili tisuće URL-ova.

Praktični popravci i opcije implementacije

Server i dostava

Koristi caching (CDN i edge caching) za statičke assete i cache-friendly HTML gdje je primjenjivo. Konfiguriraj cache-control header-e u skladu s volatilnošću sadržaja. Istraži server-timing header-e da izneseš upstream latenciju. Ako je TTFB visok, profile-aj backend servise i database upite.

Front-end i renderiranje

Odgodi non-critical JavaScript, razdijeli kod po rutama i izbjegavaj duge main-thread zadatke. Koristi resource hints (preconnect, preload) gdje je primjenjivo. Osiguraj da slike koriste moderne formate, odgovarajuće veličine i učinkovite lazy-loading obrasce koji ne odgađaju LCP. Ograniči strategiju webfontova da izbjegneš FOIT/FOUT probleme koji utječu na LCP.

Vizualna stabilnost

Rezerviraj prostor za slike, oglase i embed-ove pomoću width/height ili aspect-ratio CSS-a, izbjegavaj naknadno injektiranje above-the-fold DOM-a i koristi placeholder-e koji održavaju layout kako bi se smanjili CLS događaji.

Česte pogreške i slijepi kutovi

• Goniš rezultat jednog alata — Lighthouse i PageSpeed Insights su korisni, ali dobar Lighthouse score ne jamči poboljšanja za stvarne korisnike ako su ti field metrici loši.
• Optimiziraš samo desktop — Google koristi mobilnu verziju kao primarnu osnovu za indeksiranje, pa osiguraj paritet suštinskog sadržaja i performansi na mobilnom.
• Tretiraš third-party skripte kao nedodirljive — analytics, tag manageri i ad skripte mogu dodati duge main-thread zadatke i network latenciju; procijeni njihov stvarni trošak i učitaj ih asinhrono ili na consent gdje je primjereno.
• Pretpostavljaš da neregistrirana stranica i dalje daje punu link vrijednost — backlink na stranici koju Google ne indeksira općenito je manje koristan za ranking signale. Za verifikaciju vanjskih objava koristi neovisne provjere (page HTML, site: upiti kao indikator i renderirani DOM) jer nećeš imati pristup publisherovom Search Console-u.

Lista za verifikaciju: potvrdi da promjene zaista pomažu

Postavi reproducibilan workflow za verifikaciju svakog popravka i zabilježi prije/poslije field metric-e gdje je moguće.

• Zabilježi field metric-e iz PageSpeed Insights ili svoje CrUX pipeline za ciljanu URL ili grupu URL-ova.
• Pokreni Lighthouse u konzistentnoj lab konfiguraciji i spremi trace file za komparaciju prije/poslije.
• Koristi Chrome DevTools Performance da pregledavaš long tasks, layout shiftove i network waterfalle kako bi pronašao korijenske uzroke.
• Potvrdi server-side promjene s curl -I da pregledaš cache header-e i server-timing, i provjeri server logove za smanjena vremena odgovora i obrasce crawler zahtjeva.

Tokovi za rješavanje problema

Sporo LCP samo na mobilnom

Pregledaj mobilni HTML koji se isporučuje (curl s mobile UA). Auditiraj kritični rendering path: hoće li veliki hero image biti lazy-loaded krivo? Blokiraju li fontovi renderiranje? Koristi Lighthouse i DevTools da identificiraš točan resource koji odgađa LCP element, pa prvo smanji ili preload-aj taj resurs.

Visok INP ili dugi zadaci

Koristi Performance trace da pronađeš duge main-thread zadatke. Podijeli težak JavaScript na manje zadatke, odgodi nebitne poslove i primijeni web-worker obrasce gdje je prikladno. Ponovno pokreni lab testove da potvrdiš smanjenje long-task vremena.

Regresija nakon deploymenta

Održi performansnu bazu i automatizirane provjere u CI za template-e. Ako deploy pogorša metrike, rollback-aj ili izoliraj promjenu preko feature flagova i debug-iraj s usporedbom trace-ova.

FAQ