Rastavljanje: revizija spore WordPress web stranice korak po korak

Zašto je redoslijed revizije važniji od same revizije?

Kada pokušavate revidirati web strnicu, što god radili, prvo obavezno upotrijebite besplatne alate koji su vam dostupni, a koji vam u kombinaciji, kada se pravilno koriste i tumače, mogu reći dosta toga o tome što se zapravo događa.

Većina vodiča reći će vam da optimizirate slike, omogućite predmemoriranje (caching), minificirate CSS i JavaScript, ali vam nikad neće objasniti zašto su stvari onakve kakve jesu i zašto se rade na određeni način. Da biste u potpunosti razumjeli što se zapravo događa “ispod haube”, nažalost, prvo morate razumjeti kako stvari funkcioniraju u WordPressu. Sve ostalo je čista kozmetika ako nemate pristup CLI-ju ili barem standardni SSH pristup, a to je uz pretpostavku da nisu uključeni ni plaćeni dodaci (plugins).

Besplatno iskoristite preglednik koji već svakodnevno koristite

Otvorite Chrome Dev Tools (ili ekvivalentni alat u pregledniku po vašem izboru), kliknite na karticu Network i osvježite stranicu. To će prikazati razne informacije pomoću kojih možete otkriti gdje je stvarno usko grlo.

Pomoću alata PageSpeed Insights možete po pojedinoj stranici ili predlošku pronaći gdje su problemi i prilično ih brzo riješiti. A ako imate poteškoća s upitima prema bazi podataka ili s načinom na koji WordPress dohvaća i prikazuje podatke, možete upotrijebiti i Query Monitor kako biste vidjeli gdje se nalaze informacije i problemi.

Kao što je spomenuto u prethodnom članku o stvarnim troškovima koji se kriju iza spore web stranice, imajte na umu da je jurenje za čistih 100 bodova, iako vrlo hvale vrijedno, besmisleno. Dovoljno je proći pragove i sve je u redu.

Dakle, zaronimo u detalje i pogledajmo kako provesti solidnu WordPress reviziju.

Krenite od podataka stvarnih korisnika, a ne od laboratorijskog rezultata

O ovome sam već pisao u prethodnom članku, ali samo ukratko. Gledajući podatke o performansama, možete uočiti dvije vrste podataka; možete vidjeti što stvarno doživljavaju vaši korisnici putem CrUX-a, o čemu možete saznati više u prethodnom članku, te laboratorijske podatke.

Imajte na umu da laboratorijski podaci predstavljaju idealan scenarij za pokretanje testova s fiksne lokacije servera. Stoga, da biste pronašli podatke stvarnih korisnika, morate imati postavljen i pokrenut Google Search Console. Izvještaj koji tražite naziva se izvještaj Core Web Vitals u kojem možete vidjeti koji URL prolazi, koji ima upozorenje Needs improvement (potrebno poboljšanje), a koji imaju status Poor (loše).

Vaš prvi i glavni fokus trebali bi biti mobilni uređaji, a zatim stolna računala, budući da Google web-mjesta uvijek indeksira putem mobilnih uređaja.

Ako vam je potreban pregled uživo vaših Core Web Vitals pokazatelja dok radite na web stranici, u Chrome Dev Tools otvorite karticu “Performance” i moći ćete vidjeti s kojim je elementom bilo interakcije i kakav je bio rezultat. Drugim riječima, koliko je vremena bilo potrebno da se izvrši promjena zatražena vašom interakcijom.

Izolirajte TTFB prije nego što dirate bilo što drugo

To je metrika koja mjeri kašnjenje između trenutka kada preglednik pošalje HTTP zahtjev i trenutka kada primi prvi bajt HTML odgovora. Sve se to događa na razini servera, prije nego što se učita ijedan resurs i prije nego što preglednik uopće ima što iscrtati.

Dobar TTFB, odnosno Time To First Byte (vrijeme do prvog bajta), nalazi se unutar prvih 800 ms. Između 800 ms i 1800 ms nalazi se u zoni Needs improvement (potrebno poboljšanje), a sve iznad 1800 ms ima status Poor (loše). U WordPressu na to najčešće utječu preslabi serveri dijeljenog hostinga, nedostajuće ili pogrešno konfigurirane postavke predmemoriranja (caching) ili prekomjeran broj upita prema bazi podataka pri svakom učitavanju stranice, a da i ne spominjemo verzije PHP-a. Stare i neodržavane teme također mogu uvelike pridonijeti stvaranju prekomjernih upita, čime dodatno povećavaju TTFB.

Kako izmjeriti TTFB – Time To First Byte?

Za mjerenje možete upotrijebiti nekoliko alata. Možete koristiti terenske (field) alate poput Chrome User Experience Reporta ili web vitals JS biblioteku, koju možete instalirati putem node package managera.

Ili možete koristiti alate poput:

1. GTmetrix – https://gtmetrix.com/
2. kartica Network u Chrome DevToolsu
3. PageSpeed Insights – https://pagespeed.web.dev/

Pročitajte GTmetrix waterfall prikaz prije nego što napravite bilo kakve promjene

Vrlo slično kartici Network u PageSpeed Insightsu, GTmetrix prikazuje waterfall vremensku traku svakog mrežnog zahtjeva koji stranica pokrene: od HTML-a, CSS-a, JavaScripta, slika, fontova, API zahtjeva i svih drugih vanjskih (third-party) skripti, poredanih redoslijedom kojim su zatraženi. Primjer toga možete vidjeti u nastavku.

Na početku revizije ovdje zaista trebate obratiti pozornost na dvije stvari. Prvo, na prvu zelenu liniju, a zatim na uzastopne zahtjeve koji su odgođeni zbog te zelene linije. Ti odgođeni zahtjevi obično su najkorišteniji resursi na vašoj web-stranici, poput fontova, CSS-a, JS-a i drugih skripti za razne funkcionalnosti. Kako bi vam bilo lakše, GTmetrix vam omogućuje filtriranje tih vrsta resursa i pregled svih potrebnih detalja o njima, kako biste utvrdili gdje je usko grlo.

Imajte na umu da ovaj alat služi isključivo kao dijagnostički alat. U ovoj fazi nemojte poduzimati nikakve akcije.

Revidirajte sloj baze podataka pomoću alata Query Monitor

Ako WordPress koristite u punom kapacitetu i imate omogućene prilagođene tipove sadržaja (CPT-ove), kada se pojavi problem, nemojte pogriješiti pokušavajući ga otkloniti sami ili uz pomoć bilo kojeg dostupnog AI alata. Razlog tomu je što ni vi ni umjetna inteligencija ne možete doći do potpunog konteksta onoga što se zapravo događa. A upravo to omogućuje dodatak Query Monitor.

On rasvjetljava što WordPress traži od baze podataka pokušavajući doći do informacija koje ste zatražili, kao što možete vidjeti na snimci zaslona u nastavku.

Query Monitor vam također daje kontekst svakog zahtjeva, što ga čini korisnim za otklanjanje pogrešaka umjesto da samo izvještava o brojevima. Broj upita koristite kao signal: održavanje broja upita ispod 50 zdrav je cilj, dok bi se sve iznad 100 trebalo smatrati upozorenjem da se učitava previše podataka, ponavlja rad ili se baza podataka ispituje kada to nije potrebno.

Stupac Caller jedno je od najkorisnijih mjesta za početak jer vam pomaže da s “ima previše upita” prijeđete na “ovaj specifični dodatak, datoteka teme, hook ili funkcija odgovorni su za njihovo generiranje.” Umjesto da promatrate ukupan broj upita izolirano, filtrirajte prema pozivatelju (caller) i tražite ponavljajuće obrasce: istu komponentu koja više puta izvršava slične upite, upite pokrenute unutar petlji ili zahtjeve pokrenute funkcionalnošću koja na toj stranici uopće ne bi trebala biti aktivna. Tu se obično nalazi stvarna prilika za optimizaciju, jer čim znate koji dio WordPressa stvara opterećenje, možete odlučiti hoćete li ga predmemorirati (cachirati), prepisati upit, onemogućiti nepotrebnu logiku ili zamijeniti komponentu koja uzrokuje opterećenje.

Identificirajte dodatke koji usporavaju performanse

Kada je riječ o dodacima, pitanje nije koliko ih je instalirano na WordPress instalaciji. Pitanje je što ti dodaci rade kada su instalirani i aktivirani.

Npr. koliko dodatnog opterećenja (bloat) stvaraju kada se koriste. Kako biste odgovorili na to pitanje, najsigurniji način provjere jest metoda deaktivacije, nakon koje biste svaki put trebali izmjeriti utjecaj deaktivacije tog dodatka. Ostajući pritom uz Query Monitor, nakon što onemogućite određeni dodatak, trebali biste moći vidjeti za koliko se smanjio broj upita. Ako se smanji za više od otprilike 50 bodova, pronašli ste krivca.

Najčešći uzročnici problema su alati za izradu stranica (page builderi) koji na svakom tipu stranice učitavaju cijeli svoj skup resursa, dodaci za dijeljenje na društvenim mrežama koji pri svakom učitavanju stranice šalju vanjski poziv, ili WooCommerce ekstenzije zahtjevne za sesiju koje izvršavaju upite košarice čak i na stranicama koje nisu dio trgovine.

Revidirajte frontend resurse: slike, CSS i JavaScript

Nakon što je čišćenje servera i upita završeno i sve je u redu bez neriješenih problema, vrijeme je usredotočiti se na ono što preglednik preuzima i iscrtava.

Ta je faza u ovom trenutku važna jer provođenje tih optimizacija dok još postoje problemi sa serverom i bazom podataka može imati suprotan učinak i uvući vas u začarani krug u kojem sve postaje gore nego što zapravo jest, tj. može doći do sve manjih koristi od uloženog truda.

Najlakše rješenje, kao i meta s najvećim učinkom, jesu slike, koje mogu činiti otprilike 37% (ako ne i više) ukupne težine stranice. Pritom će PageSpeed Insights prikazati greške za prevelike slike s procijenjenim uštedama. Uz to što ćete slike učiniti što lakšima, obavezno na svakoj postavite “width” i “height” atribute kako biste smanjili mogućnost pojave CLS problema. Na najvećoj slici iznad linije preloma (above the fold) u predlošku koji koristite, postavite fetchpriority=”high”, čime će se ta slika prioritizirati pri iscrtavanju stranice, poboljšavajući tako vaš LCP rezultat.

Kada je riječ o CSS-u, morate utvrditi koji su elementi kritični za temu koju gradite i razviti kritični CSS, koji se obično odnosi na sadržaj iznad linije preloma pri učitavanju stranice. Stoga ga je važno ugraditi izravno u HTML pomoću elementa <style> unutar elementa <head> dokumenta. Kada je riječ o JavaScriptu, nije svaka skripta u zaglavlju dokumenta problem — identificirajte koje su doista potrebne prije prvog iscrtavanja (first paint), a koje se sigurno mogu odgoditi (defer).

Ocijenite hosting i konfiguraciju servera

Ako je TTFB u redu prema prethodnim koracima, ovo je samo brza preventivna provjera konfiguracije. Ako bi vaš TTFB bio spor, a revizija baze podataka i dodataka nije pronašla ništa značajno, hosting je vjerojatno ograničavajući faktor, pa ovaj odjeljak postaje ključniji.

Postoje tri varijable na strani servera koje izravno utječu na performanse WordPressa:

1. Verzija PHP-a

PHP verzija 7.4 dosegnula je kraj životnog vijeka (end-of-life) u studenom 2022., a web-mjesta koja je i dalje koriste mogla bi u testovima ostvariti znatna poboljšanja propusnosti prelaskom na PHP 8.x.

2. Status OPcachea

Na WordPress nadzornoj ploči postoji zaslon Health check koji vam može pokazati je li OPcache aktiviran ili ne. Do tog zaslona možete doći putem: Tools -> Site Health -> Info -> Server

Ako je deaktiviran, to znači da se svaka PHP datoteka iznova parsira pri svakom zahtjevu, a njegovo omogućavanje nema nikakav nedostatak za produkcijsku WordPress web stranicu.

Prvenstveno se koristi za kompiliranje svake PHP datoteke i pohranu tih datoteka u memoriju, čime se uklanja potreba za ponovljenim parsiranjem.

3. Dostupnost object cachinga

Object caching je tehnika kod koje se rezultat zahtjevne operacije — poput upita prema bazi podataka ili izračunate vrijednosti — pohranjuje u brzu, privremenu memoriju (poput Redisa ili Memcacheda) pod jedinstvenim ključem nakon što je prvi put generiran, tako da se budući zahtjevi za istim podacima mogu odmah poslužiti iz te pohranjene kopije umjesto ponovnog izračunavanja ili dohvaćanja od nule. Predmemorirana (cachirana) kopija obično istječe ili se poništava (invalidira) čim se temeljni podaci promijene, a najbolje performanse obično se postižu njezinom kombinacijom s OPcacheom.

Izradite popis prioritetnih ispravaka, a ne obični popis zadataka

Kada imate sve podatke, važno je strukturirati akcijski plan za rješavanje svih problema. Nemojte pogriješiti izradom običnog popisa zadataka (to do list). To nije pravi pristup.

U ovom smo članku obradili sve što se tiče prioriteta, pa se držite sljedećeg redoslijeda:

1. Riješite sve što bi smanjilo TTFB i uklonite sve neučinkovite upite prema bazi podataka – oboje će utjecati na svako sljedeće mjerenje
2. Ispravite sve resurse koji utječu na vaše LCP i CLS rezultate – od slika (fetchpriority, width, height), JavaScripta (odgoda neesencijalnih skripti), do CSS-a (ugrađeni kritični CSS za sadržaj iznad linije preloma)
3. Ispravite manje resurse koji imaju manji pojedinačni utjecaj, ali kada se zbroje, mogu donijeti postupna poboljšanja – učitavanje fontova, predmemoriranje u pregledniku itd.

Mjerite nakon svake pojedinačne promjene, a ne nakon što odjednom primijenite deset ispravaka. Grupiranje promjena onemogućuje vam da znate koja je promjena zapravo pomogla, a koja nije učinila ništa — a ujedno onemogućuje da uočite ispravak koji je stanje pogoršao.

Trebate pomoć oko revizije svoje WordPress stranice?
TTFB, broj upita na bazu, dodaci koji usporavaju rad, skripte koje blokiraju renderiranje — da biste utvrdili što stvarno usporava vašu stranicu, potreban je pravi redoslijed koraka, ne samo pravi alati. Ako želite preskočiti nagađanje, javite nam se i zajedno ćemo proći kroz vašu trenutnu postavku te odrediti što je najprije vrijedno popraviti.

FAQ