Najhitrejši način, da WordPress stran prestane Core Web Vitals, je: izmeri z uporabniškimi podatki v Search Console, odpravi TTFB z boljšim gostovanjem in strežniškim keširanjem, nato optimiziraj LCP element. Šele ko je strežnik hiter, frontend optimizacije prinesejo merljiv rezultat.
Trije takojšnji koraki, ki premaknejo največ:
- Preveri Search Console. Odpri razdelek »Osnovna spletna merila« (Core Web Vitals report) in ugotovi, katere strani imajo status »Slabo« ali »Potrebuje izboljšavo«. To so field podatki iz resničnih obiskov, ne laboratorijsko merjenje.
- Preklopi na upravljano gostovanje s strežniškim keširanjem. Prehod z deljenega gostovanja na upravljano WordPress gostovanje pogosto zniža TTFB s 800 ms+ na manj kot 300 ms, kar neposredno izboljša LCP.
- Optimiziraj LCP element. Poišči hero sliko ali naslovni blok, ki ga Google označi kot LCP element, in mu dodaj atribut
fetchpriority="high"ter<link rel="preload">. Odstraniloading="lazy"samo za ta element.
Hiter kontrolni seznam za začetek:
- Izmeri field podatke v Search Console in PageSpeed Insights.
- Preveri TTFB z WebPageTest (cilj: pod 200 ms).
- Aktiviraj strežniško keširanje in CDN (npr. Cloudflare).
- Pretvori slike v WebP, nastavi pravilne dimenzije.
- Odloži ali onemogoči JavaScript, ki ni potreben na trenutni strani.
- Preveri CLS: vsem slikam in iframe-om dodaj
widthinheight.
Strokovni nasvet: LCP element najhitreje prepoznaš tako, da v brskalniku Chrome odpre DevTools, zavihek Performance Insights, in poiščeš »Largest Contentful Paint«. Prikaže ti točno, kateri element je LCP, skupaj z URL-jem vira. Ko ga enkrat identificiraš, odstrani loading="lazy" samo za ta element, vsem ostalim slikam pa ga pusti.
Ključne ugotovitve
Najhitrejša pot do zelenih Core Web Vitals na WordPress strani je kombinacija hitrega gostovanja z nizkim TTFB, pravilno optimiziranega LCP elementa in selektivnega upravljanja JavaScripta za izboljšanje INP.
| Točka | Podrobnosti |
|---|---|
| Začni z merjenjem | Odpri Search Console in identificiraj strani s statusom »Slabo« pred kakršnimi koli popravki. |
| Gostovanje je prioriteta | Prehod na upravljano gostovanje pogosto zniža TTFB s 800 ms+ na pod 300 ms in neposredno izboljša LCP. |
| LCP element zahteva posebno obravnavo | Odstrani loading="lazy", dodaj fetchpriority="high" in <link rel="preload"> za hero sliko. |
| INP zahteva ročno delo | Ni vtičnika, ki bi samodejno popravil INP; selektivno onemogočanje skript po straneh je najučinkovitejša tehnika. |
| Webtim za celovito optimizacijo | Webtim izvede analizo, popravke in vzpostavi stalno spremljanje Core Web Vitals za merljive rezultate. |
Kazalo
- Kaj so Core Web Vitals za WordPress in zakaj so ključni za SEO?
- Kako meriti Core Web Vitals za WordPress: orodja in delovni tok
- Preverjene WordPress optimizacije, razvrščene po vplivu
- Kateri vtičniki in orodja pomagajo pri Core Web Vitals?
- Kako prioritetizirati popravke: časovni okvir in stroški
- Vzpostavitev spremljanja in preprečevanje regresij
- Najpogostejše napake, ki poslabšajo Core Web Vitals
- Podatki: kako WordPress dejansko stoji pri Core Web Vitals
- Ali optimizacije Core Web Vitals koristijo vsem uporabnikom?
- Tri stvari, ki jih priporočamo narediti takoj
- Webtim vam pomaga doseči zelene Core Web Vitals
- Viri
Kaj so Core Web Vitals za WordPress in zakaj so ključni za SEO?
Google od maja 2021 Core Web Vitals (osnovna spletna merila) upošteva kot del algoritma rangiranja. Gre za tri meritve, ki skupaj opisujejo, kako hitro in stabilno se stran naloži ter kako hitro se odziva na ukaze uporabnika.
LCP (Largest Contentful Paint) meri, kdaj se naloži največji vidni element na zaslonu, najpogosteje hero slika ali naslovni blok. Ciljna vrednost je 2,5 sekunde ali manj.
INP (Interaction to Next Paint) je od marca 2024 zamenjal FID in meri odzivnost strani skozi celotno sejo, ne le ob prvem kliku. Ciljna vrednost je 200 ms ali manj pri 75. percentilu uporabnikov.
CLS (Cumulative Layout Shift) meri vizualno stabilnost strani med nalaganjem. Vrednost 0,1 ali manj pomeni, da se elementi ne premikajo nepričakovano.
Ciljni pragovi in tipični WordPress vzroki
| Metrika | Dobro | Potrebuje izboljšavo | Slabo | Tipičen vzrok za WordPress |
|---|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5 s | > 2,5 s | Neoptimizirane hero slike, počasen strežnik |
| INP | ≤ 200 ms | pod 200 ms | > 600 ms | Težki JavaScript vtičniki, page builderji |
| CLS | ≤ 0,1 | 0,1 | > 0,1 | Slike brez dimenzij, spletni fonti, oglasi |
WordPress ni inherentno počasen. Slaba učinkovitost skoraj vedno izvira iz kombinacije težkih page builderjev, preveč vtičnikov in nizkocenovnega deljenega gostovanja. Skrbna konfiguracija omogoča, da WordPress dosledno dosega zahtevane meje.
Field podatki vs. laboratorijska orodja
Field podatki prihajajo iz resničnih obiskov in jih Google zbira prek Chrome User Experience Report (CrUX). Prav ti podatki vplivajo na rangiranje. Laboratorijska orodja, kot sta Lighthouse in PageSpeed Insights, simulirajo pogoje in so odlična za diagnostiko, a ne odražajo nujno tega, kar doživljajo vaši obiskovalci. Oba pristopa sta potrebna: field podatki povedo, ali imate problem, laboratorijska orodja pa pokažejo, kje točno leži.
Ključno: Google za rangiranje upošteva izključno field podatke iz CrUX. Odlična ocena v Lighthouse ne pomeni nič, če field podatki kažejo drugače.
Kako meriti Core Web Vitals za WordPress: orodja in delovni tok
Merjenje brez jasnega delovnega toka hitro postane kaotično. Priporočamo naslednje zaporedje:
- Odpri Google Search Console in pojdi na razdelek »Osnovna spletna merila«. Orodje razvrsti strani v tri kategorije (dobro, potrebuje izboljšavo, slabo) na podlagi field podatkov iz CrUX. Identificiraj predloge strani z največ napakami, ne le posameznih URL-jev.
- Izberi 5 reprezentativnih URL-jev iz vsake problematične kategorije: domačo stran, tipično objavo, kategorijsko stran, kontaktno stran in stran z izdelki (če je relevantno).
- Zabeleži field vrednosti za vsak URL: LCP, INP, CLS in TTFB. To je tvoja izhodiščna točka.
- Zaženi PageSpeed Insights za vsak URL. Orodje prikaže tako field podatke (če so na voljo) kot laboratorijsko analizo z diagnostičnimi priporočili.
- Zaženi Lighthouse v Chrome DevTools za podrobnejšo diagnostiko: prikaže seznam priložnosti in diagnostik z ocenami vpliva.
- Zaženi WebPageTest za globlje testiranje: prikazuje waterfall diagram nalaganja, TTFB po strežnikih in vizualni prikaz nalaganja po korakih. Posebej koristen za identifikacijo počasnih tretjih strank.
- Za real-user monitoring (RUM) na WordPress straneh so na voljo rešitve, ki zbirajo podatke neposredno od obiskovalcev. Search Console in CrUX sta brezplačni možnosti; za bolj podrobne podatke obstajajo specializirane RUM storitve.
Kaj zapisati za vsak URL:
- TTFB (cilj: pod 200 ms)
- LCP element (kateri element, kateri vir, ali ima
loading="lazy") - INP vzorci (kateri vtičniki se nalagajo, ali obstajajo dolge naloge v DevTools)
- CLS izvori (slike brez dimenzij, fonti, oglasni bloki)
Field podatki iz CrUX odločajo o rangiranju; laboratorijska orodja so ključna za diagnostiko, a brez field spremljanja ne vemo, kaj dejansko doživljajo obiskovalci.
Preverjene WordPress optimizacije, razvrščene po vplivu
1. Gostovanje, PHP in TTFB: največji vzvod
Prehod na upravljano WordPress gostovanje z integriranim strežniškim keširanjem je pogosto edini ukrep, ki zniža TTFB s 800 ms+ na manj kot 300 ms. Brez tega so vse ostale optimizacije manj učinkovite. Ob tem poskrbi za PHP 8.2 ali novejši, saj starejše različice PHP neposredno upočasnijo generiranje strani.
LiteSpeed strežniki prinašajo nativno podporo za HTTP/3 in globoko integracijo z LiteSpeed Cache vtičnikom, kar je praktična prednost za WordPress strani, ki želijo izboljšati metrike na strežniški ravni. Redis ali Memcached za object cache dodatno zmanjšata obremenitev podatkovne baze.
Strokovni nasvet: Preden zamenjate gostovanje, zaženite WebPageTest z lokacijo v Evropi in preverite »Time to First Byte«. Vrednost nad 600 ms je jasen signal, da gostovanje zaostaja in da nobena frontend optimizacija ne bo prinesla zadostnih rezultatov.
2. Optimizacija slik: LCP in CLS hkrati
Slike so najpogostejši vzrok za slab LCP. Pretvorba v WebP ali AVIF pogosto zmanjša velikost datoteke brez vidne izgube kakovosti. Za LCP element je ključno:
- Dodaj
fetchpriority="high"in<link rel="preload">v<head>. - Odstrani
loading="lazy"samo za LCP element. - Zagotovi, da je LCP element v HTML-ju zgodaj in ni generiran iz JavaScripta, saj dinamična gradnja zamakne prepoznavo elementa.
Za CLS: vsem slikam in iframe-om nastavi eksplicitne atribute width in height. Brskalnik tako rezervira prostor pred nalaganjem in prepreči premikanje vsebine.
3. JavaScript in INP: selektivno onemogočanje
INP je najtežji za izboljšanje, ker je neposredno odvisen od tega, koliko JavaScripta se izvaja na posamezni strani. Onemogočanje nepotrebnih skript na ravni strani je visoko vplivna tehnika: vtičnik za kontaktni obrazec, ki se nalaga na vseh straneh, je klasičen primer. Izklopi ga na vseh straneh razen kontaktne in glavna nit brskalnika se takoj razbremen.
Defer in delay za nekritični JavaScript (analitika, klepetalni vtičniki, oglaševalske mreže) zmanjšata dolge naloge, ki blokirajo odzivnost. Asset Cleanup pristop, ki ga omogočata vtičnika WP Asset Clean Up in podobni, je pri tem posebej učinkovit.
4. CLS: fonti, oglasi in rezervna mesta
Spletni fonti brez font-display: swap ali font-display: optional povzročajo premike besedila med nalaganjem. Nastavi font-display: swap v CSS ali v nastavitvah vtičnika za fonte. Za oglasne bloke in iframe-e rezerviraj prostor z eksplicitnimi dimenzijami ali CSS aspect-ratio, da preprečiš premike ob nalaganju.
Opomba za page builder uporabnike: Elementor, Divi in podobni gradniki pogosto generirajo odvečen CSS in JavaScript na vsaki strani, ne glede na to, ali ga ta stran potrebuje. Če CWV ostajajo slabi kljub vsem optimizacijam, je zamenjava na lažjo temo ali prenova strani pogosto edina trajna rešitev.
Brez hitrega TTFB so nadaljnje optimizacije neučinkovite — to velja za vse tri metrike, ne le za LCP.
Kateri vtičniki in orodja pomagajo pri Core Web Vitals?
Ni enega vtičnika, ki bi samodejno popravil vse tri metrike. Vsako orodje pokriva določen del optimizacije, INP pa pogosto zahteva ročno delo.
| Orodje | Vpliv na LCP/INP/CLS | Cena | Enostavnost nastavitve | Združljivost z gradniki | Tveganja |
|---|---|---|---|---|---|
| WP Rocket | LCP ✓✓, INP ✓, CLS ✓ | Plačljivo | Visoka | Dobra z Elementor, Divi | Konflikti z drugimi cache vtičniki |
| LiteSpeed Cache | LCP ✓✓, INP ✓, CLS ✓ | Brezplačno | Srednja | Dobra | Zahteva LiteSpeed strežnik |
| Autoptimize | LCP ✓, INP ✓ | Brezplačno | Srednja | Zmerna | Možni vizualni zlomi pri agresivni nastavitvi |
| ShortPixel | LCP ✓✓ | Freemium | Visoka | Odlična | Izguba kakovosti pri agresivni kompresiji |
| Smush | LCP ✓✓ | Freemium | Visoka | Odlična | Brezplačna različica brez WebP |
| Cloudflare | LCP ✓✓, INP ✓ | Brezplačno/plačljivo | Srednja | Neodvisna | Napačna konfiguracija keša |
Kdaj uporabiti katero orodje:
- LiteSpeed Cache je optimalna izbira, če vaš strežnik poganja LiteSpeed. Integracija je globlja kot pri katerem koli drugem vtičniku.
- WP Rocket je najboljša »vse v enem« rešitev za Apache/Nginx strežnike, kjer LiteSpeed ni na voljo. Nastavitev je hitra, rezultati pa merljivi.
- Autoptimize je primeren za minifikacijo in združevanje CSS/JS, kadar WP Rocket ni možnost. Previdno z agresivnimi nastavitvami, ki lahko zlomijo JavaScript.
- ShortPixel ali Smush za serijsko optimizacijo obstoječe knjižnice slik. ShortPixel ponuja boljšo WebP podporo v plačljivi različici.
- Cloudflare kot CDN in dodatni sloj keširanja deluje neodvisno od strežnika in vtičnikov. Brezplačni plan zadostuje za večino WordPress strani.
Opozorilo: nikoli ne nameščaj dveh cache vtičnikov hkrati. Konflikti med njimi povzročajo nepredvidljivo vedenje in pogosto poslabšajo metrike namesto izboljšanja. Po vsaki spremembi vtičnika zaženi PageSpeed Insights in primerjaj z izhodiščnimi vrednostmi.
Kako prioritetizirati popravke: časovni okvir in stroški
Začni vedno z gostovanjem in TTFB. Frontend optimizacije na počasnem strežniku prinesejo le delne rezultate. Ko je strežnik hiter, se učinek vsake nadaljnje optimizacije pomnoži.
| Vrsta popravka | Primer | Časovni okvir | Okvirni strošek | Vpliv |
|---|---|---|---|---|
| Hitri popravki | Aktivacija keša, WebP slike, preload LCP | 1–3 dni | Brezplačno | LCP, CLS |
| Srednji popravki | Prehod na upravljano gostovanje, CDN, JS defer | 1–2 tedna | 50 €/leto | LCP, INP |
| Zahtevni popravki | Zamenjava teme, page builder migracija, JS audit | 2–6 tednov | 300 € | Vse tri metrike |
| Celovita prenova | Nova gradnja z lažjo temo in optimizirano arhitekturo | 4 tedne | 1.000 € | Vse tri metrike |
Kdaj najeti strokovnjaka in kdaj narediti sam:
- Sam: aktivacija cache vtičnika, nastavitev Cloudflare, optimizacija slik z vtičnikom, dodajanje
width/heightatributov. - Strokovnjak: JavaScript audit in selektivno onemogočanje skript, migracija gostovanja, zamenjava page builderja, prenova strani z resno CLS problematiko.
Kriterij za odločitev je preprost: če sprememba nosi tveganje prekinitve funkcionalnosti ali vpliva na konverzije, jo prepusti strokovnjaku. Prenova spletne strani je pogosto bolj stroškovno učinkovita od dolgotrajnega krpanja obstoječe arhitekture.
Vzpostavitev spremljanja in preprečevanje regresij
Doseženi rezultati niso trajni sami po sebi. Nova vsebina, posodobitve vtičnikov ali reklamne mreže lahko hitro povrnejo izgube, zato je redno spremljanje enako pomembno kot začetna optimizacija.
Priporočena nastavitev za stalno spremljanje:
- Aktiviraj e-poštna obvestila v Google Search Console za padce v Core Web Vitals statusu.
- Enkrat mesečno zaženi PageSpeed Insights za 5 ključnih URL-jev in primerjaj z izhodiščnimi vrednostmi.
- Po vsaki večji posodobitvi teme ali vtičnika takoj zaženi test na staging okolju, preden spremembo objavlješ v živo.
- Vzdržuj verzioniran seznam sprememb (datum, kaj je bilo spremenjeno, vrednosti metrik pred in po).
- Za spletne trgovine, kjer vsak sekund zakasnitve neposredno vpliva na konverzije, razmisli o RUM rešitvi, ki zbira podatke v realnem času.
Rollback plan: pred vsako večjo spremembo naredi varnostno kopijo strani in baze podatkov. Če nova tema ali vtičnik poslabša metrike, mora biti povrnitev na prejšnje stanje izvedljiva v manj kot 30 minutah.
Storitve vzdrževanja vključujejo periodično preverjanje metrik in takojšnje ukrepanje ob regresijah, kar je posebej koristno za strani brez namenskega tehničnega upravljavca.
Najpogostejše napake, ki poslabšajo Core Web Vitals
Rdeče zastave in hitri popravki:
- Lazy-load na LCP elementu. Preveri v PageSpeed Insights pod »Avoid lazy loading LCP element«. Popravek: odstrani
loading="lazy"za ta element. - Več cache vtičnikov hkrati. Simptom: nepredvidljivo vedenje, včasih celo slabše metrike. Popravek: obdrži le enega, ostale deaktiviraj in odstrani.
- Preveč aktivnih vtičnikov. Vsak vtičnik doda JavaScript in CSS na vsako stran. Preveri z Health Check & Troubleshooting vtičnikom. Popravek: deaktiviraj vse, ki niso nujni, in preveri vpliv.
- Slike brez dimenzij. CLS skoči, ker brskalnik ne ve, koliko prostora rezervirati. Popravek: vsem slikam dodaj
widthinheightatribute. - Oglasi in iframe-i brez rezerviranega prostora. Oglaševalski bloki, ki se naložijo po vsebini, povzročajo premike. Popravek: nastavi minimalno višino za oglaševalske bloke z CSS.
- Neuporabljeni JavaScript tretjih strank. Analitika, klepetalni vtičniki in oglaševalske mreže pogosto blokirajo glavno nit. Preveri z WebPageTest in odloži ali pogojno naloži te skripte.
Po vsakem popravku počakaj 24–48 ur in znova zaženi PageSpeed Insights. Za field podatke v Search Console je potrebno počakati 28 dni, da se zberejo novi podatki.
Prehod na PHP 8.2+ in strežniško keširanje je eden redkih ukrepov, ki hkrati pozitivno vpliva na vse tri metrike.
Podatki: kako WordPress dejansko stoji pri Core Web Vitals
Po podatkih Search Engine Journal do konca 2025 le približno 44 % WordPress strani na mobilnih napravah prestane vse tri Core Web Vitals. To je bistveno manj od nekaterih drugih platform. Prehod na PHP 8.2+ in strežniško keširanje pa omogoča LCP med 1,2 in 1,8 sekunde, kar je dobro pod ciljno vrednostjo 2,5 sekunde.
Primer iz prakse: pred in po migraciji gostovanja
Stran je bil tipičen WordPress blog z Elementorjem, tremi cache vtičniki in deljenim gostovanjem. Po migraciji na upravljano gostovanje z LiteSpeed in aktivaciji LiteSpeed Cache vtičnika so se vse štiri vrednosti premaknile v zeleno območje. INP je ostal na robu, dokler niso selektivno onemogočili skript kontaktnega obrazca in klepetalne rešitve na straneh, kjer nista bili potrebni.
Metodološka opomba: Vrednosti v zgornji tabeli so povzetek tipičnega scenarija, ki ga opisujeta corewebvitals.io in Search Engine Journal na podlagi CrUX podatkov in dokumentiranih primerov. Posamezni rezultati se razlikujejo glede na temo, vtičnike in vsebino strani.
Ali optimizacije Core Web Vitals koristijo vsem uporabnikom?
Hitrejša stran in stabilna postavitev koristita vsakomur, a nekatere optimizacije nosijo tveganja za dostopnost, ki jih je vredno poznati.
Lazy loading in slike: pravilno implementiran lazy loading ne vpliva negativno na dostopnost. Težava nastane, ko se slike, ki so del vsebine (ne le dekorativne), naložijo prepozno ali sploh ne pri počasnih povezavah. Zagotovi, da imajo vse vsebinske slike atribut alt z opisnim besedilom, ne glede na to, ali so lazy-loaded ali ne.
Spletni fonti in font-display: swap: ta nastavitev prepreči nevidno besedilo med nalaganjem, kar je dobro za dostopnost. Bralniki zaslona ne čakajo na fonte, a vizualni premik med nadomestnim in dejanskim fontom je lahko moteč za uporabnike z določenimi kognitivnimi težavami. Rešitev je font-display: optional, ki nadomestni font obdrži, če se dejanski ne naloži dovolj hitro.
Animacije in CLS: zmanjšanje CLS pomeni manj nepričakovanih premikov vsebine, kar neposredno koristi uporabnikom z motoričnimi težavami ali tistim, ki berejo z bralniki zaslona. Vsak element, ki se premakne po nalaganju, je potencialna ovira za dostopnost.
JavaScript defer in INP: odlaganje JavaScripta izboljša INP, a pazite, da ne odložite skript, ki so potrebne za dostopnost, kot so ARIA live regioni ali upravljanje fokusa. Testirajte s tipkovnico in bralnikom zaslona po vsaki večji spremembi JavaScripta.
Dostopnost in zmogljivost nista v nasprotju. Stran, ki se hitro naloži, je stabilna in pravilno označena, je boljša za vse obiskovalce. Več o tem, kako zagotoviti dostopnost spletnih strani v skladu z zakonodajnimi zahtevami, najdete v ločenem vodniku.
Tri stvari, ki jih priporočamo narediti takoj
Večina WordPress strani, ki ne prestane Core Web Vitals, ima eno skupno lastnost: optimizacije so bile dodajane naknadno, namesto da bi bile del arhitekture od začetka. To pomeni, da je vsak dodani vtičnik, vsaka nova oglaševalska mreža in vsaka posodobitev teme potencialna regresija.
Moje priporočilo je preprosto: začni z merjenjem, ne z vtičniki. Preden namestite karkoli novega, odprite Search Console in ugotovite, katere strani imajo dejansko problem in katera metrika je kritična. Pogosto se izkaže, da 80 % prometa prihaja na 20 % strani, in da je LCP problem samo na domači strani in kategorijskih straneh.
Druga napaka, ki jo vidim pogosto, je fokus na laboratorijske ocene namesto na field podatke. Lighthouse ocena 90+ v DevTools ne pomeni nič, če Search Console kaže, da 60 % resničnih obiskov dobi »Slabo« za LCP. Google rangira na podlagi field podatkov.
Tretja stvar: INP ne boste popravili z vtičnikom. Zahteva razumevanje, kateri JavaScript se izvaja na kateri strani in zakaj. Selektivno onemogočanje skript po straneh je tehnika, ki jo premalo lastnikov WordPress strani pozna, a prinaša merljive rezultate brez kompromisov pri funkcionalnosti.
Webtim vam pomaga doseči zelene Core Web Vitals
Tehnična optimizacija WordPress strani zahteva čas, znanje in sistematičen pristop. Webtim ponuja storitev, ki pokriva celoten spekter: od analize izhodiščnih vrednosti in konfiguracije gostovanja do JavaScript audita, optimizacije slik in vzpostavitve stalnega spremljanja.
Storitev je primerna za podjetja, ki imajo obstoječo WordPress stran z merljivimi težavami pri Core Web Vitals in potrebujejo konkretne rezultate, ne le priporočil. Začetni paket vključuje analizo field podatkov, identifikacijo kritičnih točk in izvedbo prioritetnih popravkov z merjenjem pred in po.
Za spletne trgovine, kjer hitrost neposredno vpliva na konverzije, je optimizacija CWV ena izmed najučinkovitejših naložb. Preverite, kaj Webtim ponuja za izdelavo in optimizacijo spletnih trgovin, ali nas kontaktirajte za brezplačno analizo vaše strani na Webtim.
Viri
Google Search Console je izhodišče za vsakogar: prikazuje field podatke iz CrUX, razvrsti strani po statusu in pošlje obvestila ob padcih. Brezplačen in nepogrešljiv.
PageSpeed Insights združuje field podatke in laboratorijsko analizo v enem pogledu. Diagnostična priporočila so direktno uporabna za WordPress.
WebPageTest je najpodrobnejše brezplačno orodje za analizo nalaganja: waterfall diagram, TTFB po geografskih lokacijah in vizualni prikaz nalaganja po korakih.
Lighthouse je vgrajen v Chrome DevTools in omogoča lokalno testiranje brez omrežnih spremenljivk. Idealen za primerjavo pred in po spremembi.
Za nadaljnje branje o tehničnih podrobnostih optimizacije WordPress strani priporočamo SEO optimizacijo spletnih strani, kjer so zbrani primeri z merljivimi rezultati.
Začetni korak: Odpri Google Search Console, pojdi na razdelek »Osnovna spletna merila« in identificiraj tri strani z najslabšim statusom. To je tvoja prioritetna lista za naslednje tedne.
- 2025 Core Web Vitals CMS rankings — Search Engine Journal
- Corewebvitals
- Core Web Vitals: The Complete WordPress Guide — VeloPress
- WP Asset Clean Up plugin removes unused styles and scripts — WP Tavern