Optimizacija hitrosti nalaganja strani za Googlovo prvo stran
Hitrost strani vam sama po sebi ne kupi prvega mesta na Googlu. Kaj dejansko naredi, kje se čas izgublja (TTFB) in zakaj optimizacijski vtičniki ne pomagajo.
»Naredite nam hitro stran in bomo na prvem mestu Googla.« To slišimo pogosto. Pa ni tako preprosto — in če vam nekdo to obljublja, vam prodaja mit.
Hitrost sama po sebi ne kupi prvega mesta. Kupi pa nekaj drugega, kar je za posel pogosto pomembnejše — o tem na koncu. Najprej: kje se hitrost dejansko izgublja in kako jo dobite nazaj.
Prvih 200 milisekund, ki jih nihče ne meri: TTFB
Ko obiskovalec klikne povezavo, se najprej ne zgodi nič vidnega. Brskalnik pošlje zahtevek strežniku in čaka na prvi bajt odgovora. Ta čakalna doba je TTFB (Time To First Byte) — pogosto največji, a najbolj spregledan del počasne strani.
Pri tipičnem slovenskem deljenem gostovanju, kjer WordPress ob vsakem obisku sestavi stran iz baze in ducata vtičnikov, je TTFB pogosto 500–800 ms — še preden se je karkoli začelo risati. Na Cloudflarovem robnem omrežju, kjer je stran že sestavljena in postrežena iz lokacije najbližje obiskovalcu, je TTFB 20–50 ms.
To ni fina razlika. To je pol sekunde, preden se stran sploh začne nalagati — na vsakem obisku, na vsaki podstrani.
Trije kraji, kjer se izgublja čas
- Strežnik, ki premisli preveč. Vsak obisk, ki sproži poizvedbo v bazo, izvajanje PHP in vtičnike, je čas. Vnaprej sestavljena (statična) stran tega ne počne — HTML je že pripravljen.
- Predaleč od obiskovalca. Strežnik v Nemčiji ali ZDA doda vsakemu zahtevku fizično razdaljo. Robno omrežje postreže iz Ljubljane, Dunaja ali Milana — kar je najbližje.
- Preveč zahtevkov in JavaScripta. Vsak vtičnik doda svoje datoteke; brskalnik jih mora vse prenesti in izvesti. Manj ko pošljete, hitreje je — najhitrejši zahtevek je tisti, ki ga ni.
Prva dva rešuje arhitektura gostovanja, tretjega način gradnje strani. Optimizacijski vtičnik ne reši nobenega — le doda še eno datoteko.
Konkretno: ta stran
Stran, ki jo berete, ima TTFB pod 50 ms in se v celoti izriše pod pol sekunde. Ne zato, ker bi jo neskončno »optimizirali«, ampak ker se sestavi vnaprej v čist HTML, gostuje na robnem omrežju in pošlje brskalniku skoraj nič JavaScripta. Ni baze, ki bi razmišljala, ni strežnika, ki bi ga bilo treba čakati.
Kako se hitrost meri z vidika Googla (LCP, INP, CLS), smo razložili v ločenem prispevku o Core Web Vitals. Tukaj gre za korak prej — od kod hitrost sploh pride.
Kaj hitrost dejansko naredi za uvrstitev
Zdaj pošteno. Hitra stran vas ne bo katapultirala na vrh, če vsebina ni relevantna. Kar hitrost naredi:
- Boljši prvi vtis Googlovih pajkov. Hitrejša ko je stran, več strani Google obišče v istem času (crawl budget) — pomembno pri večjih spletiščih.
- Boljša uporabniška izkušnja, ki jo Google meri prek pravih obiskovalcev — in je razlikovalec med dvema podobno relevantnima stranema.
- Cenejše oglaševanje. Če poganjate Google Ads, hitrost pristajalne strani vpliva na Quality Score — počasna stran pomeni dražje klike za isto pozicijo.
Skratka: hitrost je vstopnica, ne zmagovalec. Brez nje tekmujete z ročno zavoro; z njo pa še vedno morate imeti kaj povedati.
Kaj storiti
Najprej izmerite TTFB — v razvijalskih orodjih brskalnika (zavihek Network, prva vrstica, stolpec »Waiting/TTFB«) ali na pagespeed.web.dev. Če je nad ~300 ms, težava skoraj zagotovo ni v vsebini, ampak v tem, kje in kako stran gostuje.
Optimizacijskih vtičnikov, ki obljubljajo čudež, ne nameščajte — dodajo le še en sloj. Prava rešitev je lažja stran na hitrem gostovanju: zakaj gradimo na Cloudflaru in kako izgleda hitra spletna stran v praksi.
Če želite, da vašo stran brez obveznosti izmerimo mi in vam povemo, kje se izgublja čas — pošljite povpraševanje. Odgovor dobite isti delovni dan.