WordPress optimizācija: kāpēc zaļš PageSpeed rezultāts nenozīmē ātru mājaslapu

Reizi pāris nedēļās kāds atsūta ekrānuzņēmumu no PageSpeed Insights ar jautājumu, ko ar to darīt. Parasti tur ir viens liels skaitlis, bieži sarkans, un jau gatavs risinājums: uzlikt kešošanas spraudni.

Skaitlis ir īsts. Tikai tas nav tas skaitlis, pēc kura Google izlemj, vai mājaslapa ir pietiekami ātra.

Īsumā

Zaļš PageSpeed rezultāts un izturēts Core Web Vitals novērtējums ir divas dažādas lietas. Lighthouse rezultāts ir viens simulēts mērījums, kas notiek tagad. Core Web Vitals novērtējums nāk no Chrome User Experience Report un ir reālu Chrome lietotāju datu 28 dienu slīdošais vidējais. Turklāt Lighthouse rezultātā INP vispār nav iekļauts, lai gan tieši INP ir viens no trim Core Web Vitals. Tāpēc lapa var rādīt 95 un vienlaikus krist novērtējumā. Kešošanas spraudnis parasti labo to daļu, kas jau bija kārtībā.

Trīs rādītāji un to robežas

Core Web Vitals ir trīs, un robežas ir publicētas Google web.dev dokumentācijā. Pārbaudīts 2026. gada 8. augustā:

Rādītājs	Ko mēra	Laba vērtība
LCP	Cik ilgi parādās lielākais redzamais elements	2,5 sekundes vai mazāk no brīža, kad lapa sāk ielādēties
INP	Cik ātri lapa atbild uz lietotāja darbību	200 milisekundes vai mazāk
CLS	Cik daudz saturs lēkā ielādes laikā	0,1 vai mazāk

Svarīgākā daļa nav pati robeža, bet tas, kur to mēra. web.dev norāda, ka mērīt vajag 75. procentili no lapas ielādēm, atsevišķi mobilajām un datora ierīcēm. Tas nozīmē, ka vidējais apmeklētājs nav mērķis. Mērķis ir tas apmeklētājs, kuram iet sliktāk nekā trim ceturtdaļām pārējo, un Latvijā tas gandrīz vienmēr ir cilvēks ar telefonu mobilajā tīklā ārpus Rīgas.

Divi mērījumi, kurus sajauc gandrīz visi

Šeit pazūd lielākā daļa laika, ko WordPress mājaslapas īpašnieks velta ātrumam.

PageSpeed Insights rezultāts ir laboratorijas mērījums. Viena lapas ielāde, simulēta ierīce, no tā aprēķināts skaitlis no 0 līdz 100.

Core Web Vitals novērtējums Search Console nāk no citurienes. Tas nāk no Chrome User Experience Report, ko Google savā dokumentācijā apraksta kā datu kopu, kas atspoguļo, kā reāli Chrome lietotāji izmanto vietnes. CrUX API dokumentācija to formulē precīzi: dati ir 28 dienu slīdošais vidējais no apkopotiem rādītājiem, un tie atjaunojas katru dienu ap plkst. 04.00 pēc UTC.

No tā izriet divas praktiskas lietas, un abas ir svarīgas.

Pirmkārt, izmaiņa, ko izdarījāt šodien, šodien nekur neparādīsies. Nākamajā dienā pēc izmaiņas atskaitē joprojām ir 27 dienas veco mērījumu. Pilnu efektu redzēsiet aptuveni pēc četrām nedēļām.

Otrkārt, ja PageSpeed Insights rāda zaļu skaitli un Search Console tajā pašā laikā rāda problēmu, kļūda nav Search Console. Tie ir dažādi dati par dažādām lietām, un no tiem diviem Google ranžēšanā izmanto to, kas nāk no reāliem lietotājiem.

Ko Lighthouse rezultātā vispār nav

Šī ir tā detaļa, kas parasti pārsteidz, un to var pārbaudīt pats, jo Google to publicē.

Lighthouse rezultāta aprēķinu Lighthouse 10 versijā veido pieci rādītāji ar šādiem svariem: TBT 30%, LCP 25%, CLS 25%, FCP 10% un Speed Index 10%.

INP tur nav. Tā vietā ir TBT, kas ir laboratorijas aizstājējs interaktivitātei. TBT nav Core Web Vitals rādītājs. INP ir.

Tātad gandrīz trešdaļu no PageSpeed rezultāta nosaka rādītājs, kas Google novērtējumā neietilpst, un viens no trim rādītājiem, kas tur ietilpst, PageSpeed rezultātā netiek skaitīts nemaz. Zaļš skaitlis un izkritis novērtējums nav pretruna. Tās ir divas atbildes uz diviem dažādiem jautājumiem.

Kāpēc mazai mājaslapai atskaite var būt tukša

Latvijā šī ir bieža situācija, un to nedrīkst nolasīt kā “viss kārtībā”.

CrUX dokumentācija norāda, ka datu kopā nav pilnīgi visas vietnes un lapas. Iekļaušanai ir atsevišķi kritēriji, un galvenie ir divi: lapai jābūt publiski atrodamai un apmeklētāju skaitam jābūt pietiekami lielam, lai izlase būtu statistiski nozīmīga.

Liela daļa Latvijas uzņēmumu mājaslapu šo slieksni nesasniedz. Tad Search Console Core Web Vitals atskaite ir tukša, un tas nozīmē tikai to, ka datu nav. Mājaslapa var būt lēna, un neviens to nemērīs jūsu vietā.

Ko darīt šādā gadījumā: mēriet paši ar laboratorijas rīku, bet mēriet vairākās lapās, nevis tikai sākumlapā. Sākumlapa parasti ir vienīgā, kurai kāds ir pieskāries. Produkta lapa, bloga ieraksts un kontaktu lapa mēdz izskatīties pavisam citādi.

Ko kešošanas spraudnis salabo, un ko nē

Kešošana saglabā gatavu HTML, lai serverim tas nebūtu jāģenerē no jauna katram apmeklētājam. Tas samazina servera atbildes laiku.

Servera atbildes laiks ir daļa no LCP, bet reti tā lielākā daļa. WordPress mājaslapā vairāk parasti dod trīs citas lietas: titulbilde, fonti un JavaScript.

Un INP kešošana neietekmē vispār. INP mēra, cik ātri lapa atbild pēc tam, kad tā jau ir ielādēta. To nosaka skriptu daudzums pārlūkā. Page-builderis, kas katrai sadaļai pievieno savu CSS un JavaScript failu, ir tipiskākais iemesls, un neviens kešošanas spraudnis to nesamazina.

Tā nav argumentācija pret kešošanu. Tā ir argumentācija par secību.

Viena lieta, kas attiecas tikai uz latviešu mājaslapām

Šo angliskajos rakstos par WordPress ātrumu neatradīsiet, jo angļu valodā tādas problēmas nav.

Google Fonts sadala katru fontu apakškopās, un katrai apakškopai ir savs unicode-range. 2026. gada 8. augustā paņēmām Google Fonts CSS atbildi un pārbaudījām, kas kurā apakškopā ietilpst.

Apakškopa latin sākas ar diapazonu U+0000-00FF un tālāk satur vairs tikai atsevišķus kodpunktus, piemēram, U+0131 un U+0152-0153.

Apakškopa latin-ext sākas ar diapazonu U+0100-02BA.

Visi latviešu burti ar diakritiskajām zīmēm ir otrajā. Ā ir U+0100, č ir U+010D, ē ir U+0113, ģ ir U+0123, ī ir U+012B, ķ ir U+0137, ļ ir U+013C, ņ ir U+0146, š ir U+0161, ū ir U+016B, ž ir U+017E. Nevienam no tiem apakškopā latin vietas nav.

Tātad latviešu mājaslapai, kas ielādē tikai latin, ir divas iespējas, un abas maksā. Vai nu pārlūks velk otru fonta failu tieši mūsu burtiem, vai arī tos zīmē ar sistēmas fontu, kamēr īstais fonts vēl nav klāt. Otrajā gadījumā teksts ielādes laikā pārzīmējas, un tieši tas ir tas, ko redzat kā virsraksta lēcienu ar garumzīmēm un mīkstinājuma zīmēm.

Ko pārbaudīt: atveriet pārlūka izstrādātāja rīkus, sadaļu Network, filtru Font, un paskatieties, cik fonta failu lapa velk un vai kāda no tiem nosaukumā ir latin-ext. Ja tēma vai spraudnis fontu apakškopas iestata pats, latin-ext mēdz būt izslēgta, jo noklusējumu rakstīja kāds, kuram šie burti nebija vajadzīgi.

Pašu vietnē fontus glabājam uz sava servera, nevis velkam no Google CDN, un latin-ext ir iekšā. Bez tās šī lapa nespētu attēlot pati sevi.

Ko darīt, un kādā secībā

Secība ir svarīga, jo pirmie divi soļi parasti dod vairāk nekā visi pārējie kopā.

1. Titulbilde. Neoptimizēts hero attēls ir biežākais LCP vaininieks. Pareizs izmērs konkrētajai vietai, moderns formāts, un attēlam, kas ir redzams uzreiz, fetchpriority="high". Un otrādi: tam attēlam nekad nedrīkst būt loading="lazy", jo tad pārlūks tieši to elementu, pēc kura mēra LCP, sāk vilkt pēdējo.
2. Fonti. Cik fontu saimju un cik biezumu lapa tiešām lieto. Divas saimes ar diviem biezumiem ir gandrīz vienmēr pietiekami. Glabājiet fontus pie sevis, nevis velciet no sveša CDN, un pārliecinieties, ka latin-ext ir iekšā.
3. Skripti. Katrs spraudnis, kas pievieno savu JavaScript failu katrai lapai, arī tur, kur to nelieto. Šis ir INP darbs, un tas ir vienīgais no pieciem soļiem, kas prasa izstrādātāju.
4. Izmēri attēliem un iframe elementiem. CLS rodas tāpēc, ka pārlūks nezina, cik vietas atstāt, līdz elements ir ielādējies. Norādīts platums un augstums to novērš, un tas ir lētākais labojums sarakstā.
5. Tikai tagad kešošana. Tā ir vienkāršākā darbība un tāpēc parasti vienīgā, ko izdara. Tā palīdz, bet tā palīdz pēdējā.

Kā pārbaudīt, vai izmaiņa nostrādāja

Pierakstiet datumu, kad izmaiņa nonāca produkcijā. Pēc tam nemēriet katru dienu.

CrUX dati ir 28 dienu slīdošais vidējais, tāpēc pilns efekts Search Console atskaitē būs redzams aptuveni četras nedēļas pēc izmaiņas. Līdz tam skaitlis ir maisījums no lapas pirms un pēc, un no tā secināt neko nevar.

Laboratorijas mērījumu varat veikt uzreiz, bet ne vienu reizi. Viens Lighthouse mērījums svārstās pats no sevis. Veiciet trīs un skatieties uz vidējo, un mēriet to pašu lapu, nevis katru reizi citu.

Biežākie jautājumi

Kāpēc PageSpeed rāda zaļu, bet Search Console rāda problēmu? Tie ir divi dažādi mērījumi ar dažādiem datiem un dažādiem rādītājiem. Laboratorijas mērījums pret reālu lietotāju 28 dienu vidējo, un INP, kura Lighthouse rezultātā nav.

Vai kešošanas spraudnis atrisina ātruma problēmu? Daļēji, un parasti to daļu, kas jau bija kārtībā. INP tas neietekmē nemaz.

Kāpēc Core Web Vitals atskaite ir tukša? Visticamāk, mājaslapa nesasniedz CrUX iekļaušanas slieksni. Datu nav, un tas nav tas pats, kas problēmu nav.

Cik ilgi jāgaida pēc labojuma? Aptuveni četras nedēļas, jo dati ir 28 dienu slīdošais vidējais.

Ar ko sākt, ja laika ir maz? Ar titulbildi un fontiem.

---

Ja jums šķiet, ka mājaslapa ir lēna, bet nav skaidrs, kura no piecām lietām to izraisa, mēs to izmērām un pasakām secību. Skatiet ātruma optimizāciju, vai arī, ja jautājums ir plašāks par ātrumu, WordPress uzturēšanu un tās izmaksas.