Nazrime úvodom len na moment do športu. Keď sa povie napr. v slovenskej atletike Ján Volko - dovolím si povedať, že tohto úspešného šprintéra môžeme označiť za rýchleho. Keď vidím triatlonistu Richarda Vargu ako snáď na každých pretekoch vystupuje na prvom mieste na breh - “hmm, ten je ale vo vode rýchly”. A čo potom Peter Sagan vo svojich ikonických dojazdoch? To už ani netreba zvlášť komentovať. A teraz tá otázka - kto z nich je rýchlejší?
Rýchlo - ako inak - sa ale vráťme k e-shopom. Skúsim pri nich nadhodiť podobnú úvahu - ktorý z nich je naozaj rýchly, nebodaj najrýchlejší? Prv, než sa k výsledku dopracujeme (ak vôbec), poďme sa pozrieť detailnejšie na weby, ich rýchlosť, CMS-ká, BUXUS atď. Že sa v tom spoločne viac zorientujeme. Len pred pár dňami sme publikovali blogový článok k tejto téme z knihy Martina Krupu E-shop: Od nápadu po úspech. Zároveň sme však zaznamenali zvýšený dopyt po informáciách k danej problematike, tak sme sa v krátkom slede po sebe rozhodli pridať ďalší pohľad na tento dôležitý paramater každého e-shopu.
Čo je to vlastne rýchlosť? A čo ju ovplyvňuje?
Rýchlosť alebo pomalosť webu je vo všeobecnosti čas, za ktorý sa návštevníkovi načíta konkrétna stránka.
Rozdeľujeme ju na:
- rýchlosť backendu - ako rýchlo dokáže stránku server vygenerovať a poslať klientovi
- rýchlosť frontendu - ako rýchlo vygenerovanú stránku (HTML) dokáže klientovi zobraziť jeho prehliadač - vyrenderovať CSS, zobraziť obrázky, načítať JavaScript atď.
Backend ako taký máme celkom dobre v rukách. Úpravy sú priamočiarejšie. Napr. zoptimalizujeme stránku aby jej generovanie bolo rýchlejšie, nakoľko premenné ktoré do neho vstupujú, sú nám známe (poznáme kód aplikácie, servery máme pod kontrolou). Jediná premenná v tomto prípade je rýchlosť pripojenia klienta, ktorá určuje, ako rýchlo vygenerovanú stránku (dáta) dokáže klient stiahnuť. Pri sťahovaní vieme pomôcť len tak, že zabezpečíme serveru dostatočne rýchle pripojenie k internetu a snažíme sa, aby výsledná stránka (HTML) bola čo najmenšia. Ďalej nastavenie servera, čiže zapnutie Mod_Pagespeed, memcache a nastavenie protokolu HTTP/2.0.
Frontend už je zložitejší, nakoľko do neho vstupuje viacero faktorov:
- typ zariadenia klienta (pomalý mobil, rýchly mobil, tablet, PC…),
- prehliadač - aj doplnky, ktoré má používateľ nainštalované,
- rýchlosť pripojenia klienta.
Ako ovplyvňuje rýchlosť webu samotné CMS?
Samotné CMS môže pomôcť rýchlosti backendu - ako rýchlo sa stránka vygeneruje, poskytuje rôzne cachovanie a pod.
Na frontende môže pomôcť napr. s minifikáciou JavaScriptu, resizovaním obrázkov, zmenšením veľkosti HTML kódu, komprimáciou CSS-iek.
Merače rýchlosti
Na trhu existujú viaceré nástroje, kde si môže ktokoľvek namerať rýchlosť akéhokoľvek webu. Čo však obyčajne reportujú? Resp. čo prípadne neodhalia? Nakoľko smerodajná je nameraná rýchlosť cez takéto nástroje?
Asi dva také najpoužívanejšie nástroje sú:
- Page speed Insights (na pozadí používa Google lighthouse) a
- Yslow (je to plugin do prehliadača, ale online sa dá nájsť napr na https://gtmetrix.com/).
Výhoda týchto nástrojov:
- rýchlo dajú prehľad o veciach, ktoré sa dajú zlepšiť, napr. že máme veľké obrázky,
- dajú ucelené číslo, ktoré nám po úprave odporúčaní povie, či pomohli alebo nie.
Smerodajné sú samozrejme aj čísla v Google Analytics, ktoré robia priemer cez celú stránku.
Nevýhody:
- informácie poskytnú len pre konkrétnu URL a nie pre celú site (Page Speed Insight to robí vo Field Data - ukazujú agregované dáta za posledných 30 dní zo všetkých stránok),
- čísla, ktoré ukážu, sú len z konkrétneho jedného zariadenia a z určitého miesta (odkiaľ sa stránka sťahuje - napr. ak mám väčšinu klientov zo Slovenska a nástroj sťahuje dáta z USA, môžu byť časy sťahovania dosť skreslené).
Známe spomaľovače a ako na ne
Obrázky aj videá môžu spomaliť hlavne svojou veľkosťou (koľko klientovi zaberie ich stiahnutie zo servera). Preto sa hlavne pre obrázky odporúča zopár šikovných tipov a trikov, z ktorých vyberáme:
- posielať obrázky v presne takom rozlíšení ako treba, čiže ak mám v HTML obrázok 200x200px, ale on v skutočnosti je 500x500px, tak je zbytočne veľký, nakoľko klient vidí len 200x200,
- snažiť sa ich zmenšiť použitím vhodného formátu, napr. .webp,
- obrázky lazy loadovať, teda nahrávať len vtedy, ak obrázok skutočne klient má vidieť - napr. ak je nejaký obrázok mimo viewportu, niekde na konci stránky, stačí ak sa nahrá len ak používateľ scrolluje až k nemu.
Pre videá je to podobné, ale pri nich najviac záleží na použitom formáte kompresie, teda sa snažíme ich zmenšiť kvôli šetreniu prenesených dát.
Iný content je potom Javascript s CSS, ale ten používateľ priamo nevidí.
V princípe každý nástroj (napr. marketingový), ktorý do stránky nasadíme (väčšinou je to vo forme JavaScript kódu - či už priamo alebo cez GTM) stránku nejako spomalí.
Odporúčanie: keď už nejaký nástroj do stránky vkladáme, mal by sa vkladať asynchrónne, t.j. aby javaScript neblokoval načítavanie stránky, ale nahrával sa akoby na pozadí. To ho síce môže odsunúť na neskôr, ale pri marketingových nástrojoch to natoľko nevadí.
Určite je viac ako 42 spôsobov, ako optimalizovať rýchlosť e-shopu
...a z nich vyberáme príklady pre backend:
- architektúra aplikácie,
- škálovanie infraštruktúry - pridávanie serverov,
- používanie cachovania (memcache, redis, cachovanie DB),
- varnish (viď obr. z analytiky, kde sme jednému z našich klientov kontinuálne pracovali na vylepšení rýchlosti jeho e-shopu, čo sa nám zásadne podarilo práve nasadením varnishu).
A príklady pre frontend:
- minifikovanie JS a CSS,
- spájanie JS a CSS,
- lazy loading pre obrázky,
- optimalizácie obrázkov, konverzia do iných formátov (napr. webp),
- minifikovanie HTML,
- nastavovanie cachovania pre obrázky, CSS, JS,
- Mod_pagespeed.
To sú v podstate zároveň hlavné aktivity, ktoré pre rýchlosť robíme u nás v ui42.
Ako je na tom CMS BUXUS powered by ui42 vs. rýchlosť?
Vieme povedať, že BUXUS kladie dôraz na backend rýchlosť - ak developer pracuje spôsobom, akým má (ktorý je v BUXUSe štandard), tak je aj výsledok rýchly.
Na frontende dáva BUXUS developerom voľnejšiu ruku, ale ponúka postupy, ktoré zabezpečia lepšiu rýchlosť. Napr. ak developer používa Javascript a CSS štandardným spôsobom v BUXUSe, tak vie tento BUXUS potom následne skompilovať do optimalizovanej formy aby zrýchlil frontend.
V štandardnej inštalácii BUXUS používa cache-ovanie, či už samotných BUXUS page objektov, alebo aj častí stránky (napr. header, footer). Na frontende poskytuje už v základe spomínané optimalizovanie JS a CSS - CSS spája do jedného súboru, pre JS robí takzvané layery (pospájané JS podľa typu stránky, napr. jeden základný layer a pri detaile produktu druhý, ktorý obsahuje JS kód, potrebný len pre detail produktu)
Ako nadstavbu na backende ponúkame už vyššie spomínaný varnish, teda cachovanie celých stránok. Na frontende nasadenie mod_pagespeed alebo potom custom ladenie rýchlosti pre klienta.
Support information - Google Analytics
Pre niekoho notoricky známe fakty, pre iného možno osviežujúca rekapitulácia významu jednotlivých rýchlostných parametrov v Google Analytics:
- Priemerný čas načítania stránky - čas, za ktorý sa načítajú všetky časti stránky (obrázky, JS a pod.). Skladá sa zo serverového času a času renderovania frontendu. Toto je zároveň čas, na ktorý je dobré sa v rámci sledovania analytics zamerať.
- Priemerný čas presmerovania - čas, koľko trvá presmerovanie. Teda to, keď príde klient na stránku A a tá ho presmeruje na B. Vo väčšine prípadov je toto číslo minimálne.
- Priemerný čas vyhľadania domény - ako dlho trvá klientovmu prehliadaču, kým preloží názov domény na IP adresu. Toto je tiež väčšinou minimálne a dá sa pokaziť asi len keby bol veľmi zle nakonfigurovaný DNS server.
- Priemerný čas spojenia so serverom - čas, ktorý trvá klientovi nadviazať spojenie so serverom. Toto číslo by malo byť čo najnižšie a ak je vysoké, tak môže napr. znamenať to, že server nestíha odbavovať požiadavky včas.
- Priemerný čas odpovede servera - server response time = najdôležitejšie číslo ohľadom backendu. Je to čas, ktorý potrebuje server na vygenerovanie HTML.
- Priemerný čas stiahnutia stránky - čas, ktorý klient strávi fyzickým sťahovaním HTML stránky cez sieť. Môže silno závisieť na rýchlosti pripojenia klientov, ale vo všeobecnosti ak je číslo vysoké, je treba znížiť veľkosť stránky.
O samotnom CMS-ku hovorí teda hlavne:
- Server response time (Priemermý čas odpovede servera)
- a do určitej miery (podľa frontendu) aj Priemerný čas načítania stránky
Záver
Nebojte sa, nejdem na záver filozofovať o tom, ktorý web je či nie je najrýchlejší, ako som načrtol v úvode. Viac som chcel navodiť tému pohľadu na rýchlosť z viacerých perspektív. Tak snáď sa mi to aspoň kúsok podarilo.
V prípade otázok ohľadom rýchlosti, CMS BUXUS, prípadne kľudne aj o športe kontaktujte:
Andrej Kajan
CEO
