Ako bežne funguje cache stránok
WordPress vytvára stránky dynamicky. Spúšťa PHP, načíta dáta z databázy a spracuje aktívne pluginy, až potom odošle výsledné HTML.
Robiť to pre každého návštevníka by bolo pomalé, preto weby používajú cache stránok. Hotové HTML sa po vygenerovaní uloží. Ďalší návštevník dostane pripravenú kópiu a nemusí čakať na opätovné vytvorenie stránky.
Keď cache vyprší alebo sa stránka zmení, prednačítanie by malo pripraviť novú kópiu ešte pred príchodom ďalšieho návštevníka.
Ako nízka návštevnosť narušila cyklus cache
WP Rocket používal na prednačítanie WP-Cron. Ten však nie je skutočnou plánovanou úlohou: čakajúce úlohy kontroluje iba pri návšteve webu.
Pri približne štyroch návštevách za hodinu nebolo dosť prevádzky na spracovanie frontu. Web s iba niekoľkými publikovanými URL mal v cache jedinú stránku, zatiaľ čo na spracovanie čakalo takmer 300 URL.
Väčšina návštevníkov preto čakala, kým WordPress vytvorí požadovanú stránku od začiatku. Pred zobrazením čohokoľvek v prehliadači to pridávalo 2,7 až 3,8 sekundy.
Ako sme problém odhalili
Problém zachytil Real User Monitoring v Pagespeed Digital, našom vlastnom nástroji na monitoring výkonu. RUM ukázal skúsenosť skutočných návštevníkov na rôznych stránkach, zariadeniach a v rôznych krajinách. Na 75. percentile mal web LCP 4 sekundy a TTFB 4,1 sekundy.
Ručné Lighthouse testy vyzerali dobre, pretože otvorenie stránky zahrialo cache ešte pred testom. RUM meral skutočné prvé návštevy vrátane pomalej odpovede servera.
Riešenie
WP-Cron sme presunuli na skutočný serverový cron spúšťaný každých päť minút. Prednačítanie teraz funguje nezávisle od návštevnosti a udržiava cache pripravenú aj vtedy, keď na web nikto neprichádza.
Pridali sme aj Cloudflare cache pre verejné HTML. Administrácia, prihlásení používatelia a dynamické WordPress cesty cache naďalej obchádzajú.
Do nasledujúceho rána sa spracoval celý front a na origin serveri bolo približne 450 stránok v cache.
Odpoveď pri nenájdení v edge cache klesla z 2,8–3,8 sekundy na približne 200–350 ms.
Výsledky
RUM dáta z Pagespeed Digital ukazujú pokles priemerného sedemdňového LCP z 5,2 na 2,6 sekundy.
Prečo je RUM dôležitý
RUM nám poskytol spätnú väzbu od skutočných návštevníkov ešte predtým, než sa celý prínos prejavil v Chrome User Experience Report od Googlu.
Aj CrUX využíva dáta reálnych používateľov Chromu, ale vykazuje ich v kĺzavom 28-dňovom okne. Aktualizuje sa denne, každý výsledok však stále zahŕňa návštevy za posledných 28 dní. Oprava tak môže fungovať, kým staršie pomalé návštevy ešte ovplyvňujú publikované výsledky.
Náš RUM monitoring zobrazuje nové relácie priebežne. Smer zlepšenia preto overíme bez čakania na úplné obnovenie okna CrUX.
Jedno skóre výkonu nestačí
Pri samotnom Lighthouse by sa problém ľahko prehliadol. Potrebovali sme viac zdrojov dát:
- Syntetický monitoring na konzistentné testovanie stránok.
- RUM na meranie návštevníkov podľa stránky, zariadenia a krajiny.
- CrUX na sledovanie reálnych dát, ktoré Google používa pri Core Web Vitals.
- Dáta Cloudflare a servera na určenie pomalej vrstvy doručovania.
Jeden nástroj vám povie, že sa web počas jedného testu načítal rýchlo. Kvalitný monitoring ukáže, či je rýchly pre skutočných návštevníkov, prečo nie je a či oprava funguje dlhodobo.
Súvisiace články
- Čo sú Core Web Vitals a prečo sú dôležité pre SEO
- Optimalizácia výkonu webu Bloomreach
- Prečo platená návštevnosť dostávala najpomalšiu verziu webu
