- Kako smo rešili težavo z eno najhitrejših full page cache rešitev (NGINX FastCGI Cache).
- Kako smo izboljšali TTFB (server response time) za več kot 75%.
- Kratko obrazložitev, zakaj je NGINX FastCGI ena najbolj kompatibilnih rešitev za Wordpress strani.
TL;DR;
Takoj prikaži: Rezultati (Benchmarks)
Wordpress stran za slovenia-trips.com
V turistični agenciji Slotrips d.o.o. so se v drugi polovici 2019 odločili za vzpostavitev nove strani slovenia-trips.com. Zaradi fleksibilnosti samostojnega urejanja in privlačnosti Elementor design-a so se odločili uporabiti Wordpress. Vzpostavili smo jim gostovanje na začasni domeni, kjer so lahko v miru pričeli urejati vsebino.
Naše sodelovanje pri razvoju in gostovanju spletnih strani sega že v leto 2013, ko smo razvili in še vedno vzdržujemo stran Slotrips.si. V času priprave nove strani na Wordpress-u smo izvedli nadgradnjo slotrips.si z mobile-responsive obliko ter priredili, da je prepletanje (obstoječe) slotrips.si in (nove strani) slovenia-trips.com skladno z vizijo njihovega prihodnjega delovanja.
Težava: Počasno delovanje strani
Spletno stran so uspeli urediti v skladu s svojimi željami (Screenshot) in v tem pogledu sta Wordpress in Elementor dala željeni rezultat.
Pojavilo pa se je nekaj težav:
- Kljub dobremu gostovanju je stran nalagalo nekoliko prepočasi. Ob vsakem kliku je bil prisoten "lagging" občutek (1.50-2.50sek čakanja).
- Cache plugin-i, ki običajno izboljšajo hitrost nalaganja, niso delali pravilno.
- Spletna stran namenjena obiskovalcem v tujini in ciljem biti landing page za oglaševalske akcije "mora" delati ustrezno hitro.
Ker so pri Slotrips želeli obdržati WP/Elementor template (in vso do tega trenutka vloženo delo), smo se kot administratorji strežnika in ponudnik gostovanja ponudili, da poizkusimo poiskati rešitev za pohitritev nalaganja strani.
Ob koncu 2019 je bil Elementor: #1 Free WordPress Website Builder še relativno mlada in nova zadeva. Zaradi privlačnega videza je postal zelo popularen, a njegov način delovanja in oblikovanja ima "prikrito" ceno pri velikosti kode in hitrosti delovanja strani.
Na gostovanjih, ki niso optimizirana za Worpress, bo odzivni čas strežnika za takšne strani hitro šel čez 3 sek (meja, kjer pričnejo obiskovalci zapuščati stran zaradi prepočasnega delovanja). In to je le odzivni čas oz. čas, ki ga strežnik potrebuje za sprocesiranje kode, zajem podatkov in pripravo HTML vsebine za prikaz. Nalaganje vsebine, slik, "first meaningfull paint"... šele sledijo.
Možne optimizacije
- Optimizacija vsebine (Zmanjšanje slik, besedila, integriranih YouTube posnetkov...)
- Identifikacija in odstranitev počasnih plugin-ov (običajno smo manj zadovoljni z uporabniško izkušnjo ali funkcionalnostmi na voljo)
- Zamenjava theme/template-a s hitrejšim (Običajno smo manj zadovoljni z videzom)
- Optimizacija nastavitev strežnika (Zelo omejene možnosti na shared gostovanju. Relativno drag je tudi zakup storitve administracije strežnika)
- Zakup zmogljivejšega strežnika
Urednik strani je že optimiziral vsebino in poizkusil izboljšati hitrost nalaganja z večino dobrih praks (minify JS/CSS, image-resize...). Poizkusil je tudi z nekaj popularnimi plugin-i za cache, a te niso delovale pravilno oz. so "pokvarile" videz stran ("breaking the webpage" je precej pogost pojav pri uporabi več plugin-ov).
Če berete ta članek, potem vam verjetno ni potrebno posebej omenjati pogostih težav s "počasnimi Wordpress stranmi" in vzroki zanj (How To Speed Up WordPress"). Če vas zanima, zakaj je TTFB čas pri hitrosti nalaganja tako pomemben, si lahko preberite naš članek o tem: Importance of TTFB
Ali je potreben zmogljivejši strežnik?
Na enakem strežniku, kot je bila postavljena nova Wordpress stran, Slotrips.si teče izredno hitro (slika: TTFB za uporabnika je 100-200ms po Google Analytics) in zlahka servira tisoče dnevnih obiskovalcev tudi v non-cached obliki (npr. seznam Nastanitve). Takšen strežnik (VPS: Linux container, 4x workstation-level vCPU, 4GB RAM, NVMe storage) običajno lahko poganja mnogo več od le ene Wordpress strani.
Da v celoti izločimo faktor zmogljivosti strežnika smo stran začasno postavili na najhitrejši možni PHP/Wordpress strežnik. Nalaganje je postalo nekoliko boljše (lokalni TTFB se je zmanjšal iz 1.50-2.50sek na 1.00-1.50sek), a tudi to ni ravno dober rezultat. Poleg tega je slaba praksa projekt zasnovati na predpostavki, da bo stran zadovoljivo hitra, če bo na najhitrejšem možnem gostovanju.
Tako sta bili izločeni možnosti 1 in 2; Zamenjava template-a (3) je bila praktično "non-option"; Mi pa smo izločili večino možnih optimizacij pod točko 4 ter v celoti zavrgli možnost, da bi stran bila hitra, če bi le strežnik bil dovolj zmogljiv (5).
Na seznamu preostalih možnosti ni ostalo veliko možnosti. Ena izmed njih pa je bila:
NGINX FastCGI Cache
NGINX FastCGI Cache je Full Page Cache za spletne strani. Ker je zanj potrebnih nekaj posebnih nastavitev strežnika in ne deluje le kot Wordpress plugin, je pri manjših straneh/podjetjih bistveno manj pogost od WP-Rocket, WP-Optimize, WP Super Cache, W3 Total cache....
Ima pa pred običajnimi rešitvami sledeče prednosti:
- Je ena najhitrejših cache-ing rešitev za podobne projekte;
- Kompatibilnost z izbranimi Wordpress themes & plugins je običajno 100%, ker deluje PRED samo Wordpress/PHP aplikacijo;
- Za razliko od nekaterih dobrih plugin-ov za cache je FastCGI brezplačen (zahteva pa posebno administracijo strežnika).
Projekt Slovenia-trips.com je potreboval rešitev IZVEN običajnega Wordpress ekosistema plugin-ov, saj ti niso dajali ustreznih rezultatov. Zato je bila kompatibilnost velik faktor pri odločanju za test FastCGI.
Bigger is better. Source: Spinup WP
REZULTATI (Benchmarks)
Če bi morali izbrati le eno sliko za prikaz učinka implementiranega cache-a, bi to bilo poročilo "Google Analytics > Server response time". Spodnja slika kaže večmesečni status tega kazalca in jasen prikaz znatnega izboljšanja točno na dan po implementaciji full page cache-a.
Slika: Prikaz "server response time" meritve po Google Analytics-u se meri pri cca. 10% realnih uporabnikih.
* "Slabši" čas 1.55sec je bil dosežen na izredno hitrem strežniku. Na povprečnem shared gostovanju bi po naši oceni presegel 3sec.
** Rezultati meritev izboljšanja bi bili še boljši, če bi imeli nekoliko bolj konzervativno politiko glede življenjske dobe (TTL) cached vsebine. Te nastavitve bomo lahko glede na dosedanje izkušnje še bolje prilagodili, TTFB hitrosti pa bodo posledično še boljše.
V tabeli je prikazanih še nekaj benchmark-ov:
TEST | Units | FastCGI: NO | FastCGI: YES | Diff. | Screenshot |
NGINX FastCGI Cache STATUS | |||||
Apache Bench | Reqs/ sec | 4.83 | 412.20 | 85x | Screenshot |
Google Analytics (avg. TTFB) | sec | 1.55 | 0.37 | -76% | Screenshot |
Pingdom Website Speed test (TTFB) | ms | 831.9 | 145.2 | -83% | Screenshot |
Google Chrome Dev Tools (TTFB) | sec | 1.010 | 0.043 | -96% | Screenshot |
TTFB via CURL (TTFB) | sec | 1.67 | 0.01 | -99% | Screenshot |
TTFB/CURL via Terminal test (NGINX FastCGI Disabled)
$ curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total}" https://slovenia-trips.com/?fpc=off % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 309k 0 309k 0 0 184k 0 --:--:-- 0:00:01 --:--:-- 184k Connect: 0.001100 TTFB: 1.670056 Total time: 1.673938
TTFB/CURL via Terminal test (NGINX FastCGI Enabled)
$ curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total}" https://slovenia-trips.com/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 309k 0 309k 0 0 21.5M 0 --:--:-- --:--:-- --:--:-- 21.5M Connect: 0.000887 TTFB: 0.010282 Total time: 0.014403
Code by: Analyze Your Website’s TTFB (Time to First Byte) by Hayden James
Nekaj komentarjev ob rezultatih:
- Test "TTBF via CURL" znotraj lokalne mreže kaže, da je odziv strežnika, ko ima cache na voljo, skoraj INSTANTEN (TTFB = 0.010282 sek). To je praktično maximum, kar lahko pričakujete od strežnika oz. gostovanja.
- Spletna stran pri realnih uporabnikih v večini primerov ne bo dosegala 1-5ms TTFB, ker bo pot podatkov do uporabnika običajno terjala več čas kot to (zato so "realni primeri" po Google Analytics-u v povp. 0.37sec). Je pa to indikator, da "server response time", ki je v veliki večini primerov glavni krivec za počasne strani, ni (več) ozko grlo.
- Slovenia-trips.com ima DNS zapise na Cloudflare, kar delno vpliva na rezultat v smislu oddaljenosti DNS strežnika in njihove protekcije proti DDOS napadom (če je apache bench test trajal več kot 5sek, je bil "longest request" zaradi aktivacije njihovih protekcij opazno daljši in je izkrivljal sliko dejanskega delovanja).
- Apache Bench teste smo izvedli znotraj LAN mreže, ker stran gostujemo za HAProxy strežnikom. Ta (med ostalim) služi tudi kot WAF (web application firewall) in usage limiter (podobno kot Cloudflare anti-DDOS) in bi tovrstni obremenitveni zunaj mreže bil blokiran po nekaj request-ih.
Kljub obremenitvi z 8-imi vzporednimi uporabniki je novi setup s FastCGI cache ohranil povp. TTFB čas na odličnem nivoju (< 20ms).
Testi so bili narejeni z različnimi orodji za benchmark TTFB, rezultati pa med seboj nekoliko odstopajo zaradi zunanjih vplivov na stran.
A trend je zelo jasen - kjer je bil cache na voljo, so bili rezultati bistveno boljši.
Če imate Wordpress stran in bi želeli imeti na voljo takšno gostovanje, si oglejte:
Znotraj tega paketa smo uredili zgoraj opisano rešitev (NGINX FastCGI cache), poleg pa je vključenih še množica drugih rešitev, ki zadevajo nastavitve in možnosti strežnika. Z njimi Wordpress teče bistveno bolje in hitreje, vam pa ni potrebno imeti opravka z nastavljanjem strežnika in optimizacijami Linuxa.
Vaše delo se prične z Wordpress Login obrazcem na vaši domeni.