Podívejme se úvodem jen na okamžik do sportu. Když se řekne např. ve slovenské atletice Ján Volko - dovolím si říct, že tohoto úspěšného sprintera můžeme označit za rychlého. Když vidím triatlonistu Richarda Vargu, jak snad na každých závodech vystupuje na prvním místě na břeh - “hmm, ten je ale ve vodě rychlý”. A co potom Peter Sagan ve svých ikonických dojezdech? To už ani nemusíme zvlášť komentovat. A teď ta otázka - kdo z nich je rychlejší?
Rychle - jak jinak - se ale vraťme k e-shopům. Zkusím u nich nadhodit podobnou úvahu - který z nich je opravdu rychlý, snad nejrychlejší? Než se k výsledku dopracujeme (pokud vůbec), pojďme se podívat podrobněji na weby, jejich rychlost, CMS-ká, BUXUS atd. Ať se v tom společně více zorientujeme. Jen před pár dny jsme publikovali blogový článek k této tématice z knihy Martina Krupu E-shop: Od nápadu po úspěch. Zároveň jsme ale zaznamenali zvýšený zájem o informace k dané problematice, tak jsme se v krátkém sledu po sobě rozhodli přidat další pohled na tento důležitý parametr každého e-shopu.
Co je to vlastně rychlost? A co ji ovlivňuje?
Rychlost nebo pomalost webu je obecně čas, za který se návštěvníkovi načte konkrétní stránka.
Dělíme ji na:
- rychlost backendu - jak rychle dokáže stránku server vygenerovat a poslat klientovi
- rychlost frontendu - jak rychle vygenerovanou stránku (HTML) dokáže klientovi zobrazit jeho prohlížeč - vyrenderovat CSS, zobrazit obrázky, načíst JavaScript atd.
Backend jako takový máme celkem dobře v rukou. Úpravy jsou přímočařejší. Např. optimalizujeme stránku, aby její generování bylo rychlejší, protože proměnné, které do něj vstupují, jsou nám známé (známe kód aplikace, servery máme pod kontrolou). Jediná proměnná v tomto případě je rychlost připojení klienta, která určuje, jak rychle vygenerovanou stránku (data) dokáže klient stáhnout. Při stahování můžeme pomoci jen tak, že zajistíme serveru dostatečně rychlé připojení k internetu a snažíme se, aby výsledná stránka (HTML) byla co nejmenší. Dále nastavení serveru, tedy zapnutí Mod_Pagespeed, memcache a nastavení protokolu HTTP/2.0.
Frontend už je složitější, protože do něj vstupuje více faktorů:
- typ zařízení klienta (pomalý mobil, rychlý mobil, tablet, PC…),
- prohlížeč - i doplňky, které má uživatel nainstalované,
- rychlost připojení klienta.
Jak ovlivňuje rychlost webu samotné CMS?
Samotné CMS může pomoci rychlosti backendu - jak rychle se stránka vygeneruje, poskytuje různé cachování a pod.
Na frontendu může pomoci např. s minifikací JavaScriptu, resizováním obrázků, zmenšením velikosti HTML kódu, komprimací CSS-ek.
Měřiče rychlosti
Na trhu existují různé nástroje, kde si může kdokoliv změřit rychlost jakéhokoliv webu. Co však obvykle reportují? Resp. co případně neodhalí? Nakolik směrodatná je změřená rychlost přes takovéto nástroje?
Asi dva tak nejpoužívanější nástroje jsou:
- Page speed Insights (na pozadí používá Google lighthouse) a
- Yslow (je to plugin do prohlížeče, ale online se dá najít např na https://gtmetrix.com/).
Výhoda těchto nástrojů:
- rychle dají přehled o věcech, které se dají zlepšit, např. že máme velké obrázky,
- dají ucelené číslo, které nám po úpravě doporučení řekne, zda pomohly nebo ne.
Směrodatné jsou samozřejmě i čísla v Google Analytics, které dělají průměr přes celou stránku.
Nevýhody:
- informace poskytnou jen pro konkrétní URL a ne pro celou site (Page Speed Insight to dělá ve Field Data - ukazují agregovaná data za posledních 30 dní ze všech stránek),
- čísla, která ukážou, jsou jen z konkrétního jednoho zařízení a z určitého místa (odkud se stránka stahuje - např. pokud mám většinu klientů ze Slovenska a nástroj stahuje data z USA, mohou být časy stahování dost zkreslené).
Známé zpomalovače a jak na ně
Obrázky i videa mohou zpomalit hlavně svou velikostí (kolik klientovi zabere jejich stažení ze serveru). Proto se hlavně pro obrázky doporučuje pár šikovných tipů a triků, z nichž vybíráme:
- posílat obrázky v přesně takovém rozlišení, jaké potřebujeme, tedy pokud mám v HTML obrázek 200x200px, ale on ve skutečnosti je 500x500px, tak je zbytečně velký, protože klient vidí jen 200x200,
- snažit se je zmenšit použitím vhodného formátu, např. .webp,
- obrázky lazy loadovat, tedy načítat jen tehdy, pokud obrázek skutečně klient má vidět - např. pokud je nějaký obrázek mimo viewport, někde na konci stránky, stačí, pokud se načte jen pokud uživatel scrolluje až k němu.
Pro videa je to podobné, ale u nich nejvíce záleží na použitém formátu komprese, tedy snažíme se je zmenšit kvůli šetření přenesených dat.
Jiný content je pak Javascript s CSS, ale ten uživatel přímo nevidí.
V principu každý nástroj (např. marketingový), který do stránky nasadíme (většinou je to ve formě JavaScript kódu - ať už přímo nebo přes GTM) stránku nějak zpomalí.
Doporučení: když už nějaký nástroj do stránky vkládáme, měl by se vkládat asynchronně, t.j. aby javaScript neblokoval načítání stránky, ale načítal se jakoby na pozadí. To ho sice může odsunout na později, ale u marketingových nástrojů to tolik nevadí.
Určitě je více než 42 způsobů, jak optimalizovat rychlost e-shopu
...a z nich vybíráme příklady pro backend:
- architektura aplikace,
- škálování infrastruktury - přidávání serverů,
- používání cachování (memcache, redis, cachování DB),
- varnish (viz obr. z analytiky, kde jsme jednomu z našich klientů kontinuálně pracovali na zlepšení rychlosti jeho e-shopu, což se nám zásadně podařilo právě nasazením varnishu).
A příklady pro frontend:
- minifikování JS a CSS,
- spojování JS a CSS,
- lazy loading pro obrázky,
- optimalizace obrázků, konverze do jiných formátů (např. webp),
- minifikování HTML,
- nastavování cachování pro obrázky, CSS, JS,
- Mod_pagespeed.
To jsou v podstatě zároveň hlavní aktivity, které pro rychlost děláme u nás v ui42.
Jak je na tom CMS BUXUS powered by ui42 vs. rychlost?
Můžeme říct, že BUXUS klade důraz na backend rychlost - pokud developer pracuje způsobem, jakým má (který je v BUXUSu standard), tak je i výsledek rychlý.
Na frontendu dává BUXUS developerům volnější ruku, ale nabízí postupy, které zajistí lepší rychlost. Např. pokud developer používá Javascript a CSS standardním způsobem v BUXUSu, tak to BUXUS poté následně zkompiluje do optimalizované formy, aby zrychlil frontend.
