Obsah
- Cena zpomalení
- Sítě pro doručování obsahu
- Další techniky
- Aspekty předběžného načítání a předběžného vykreslování
- Načítání obsahu Ajax
Tento článek se poprvé objevil v čísle 231 časopisu .net - světově nejprodávanějšího časopisu pro webové designéry a vývojáře.
Rychlost by měla být důležitá pro každý web. Je dobře známo, že Google používá rychlost webu jako metriku hodnocení výsledků vyhledávání. To nám říká, že návštěvníci upřednostňují rychlé webové stránky - žádné překvapení!
Jakob Nielsen napsal v roce 1993 o třech limitech doby odezvy; ačkoliv je výzkum starý podle internetových standardů, naše psychologie se za uplynulých 19 let příliš nezměnila. Uvádí, že pokud systém zareaguje za méně než 0,1 sekundy, bude vnímán jako okamžitý, zatímco reakce rychlejší než jedna sekunda umožní, aby tok myšlenek uživatele zůstal nepřerušovaný. Načíst webovou stránku za 0,1 sekundy je pravděpodobně nemožné; přibližně 0,34 sekundy představuje nejlepší dobu načítání Google UK, takže slouží jako realističtější (i když ambiciózní) měřítko. Načtení stránky někde v oblasti 0,34 až 1 sekundu je dosažitelné a důležité.
Cena zpomalení
Tyto druhy cílů mají skutečné důsledky pro váš web a podnikání. Marissa Mayer z Googlu hovořila v roce 2006 o experimentu, při kterém se počet výsledků vrácených vyhledávačem zvýšil na 30. To zpomalilo dobu načítání stránky přibližně o 500 ms, což bylo způsobeno 20% poklesem provozu. Amazon mezitím uměle zpozdil načítání stránky v krocích po 100 ms a zjistil, že „i velmi malá zpoždění by vedla k podstatnému a nákladnému poklesu výnosů“.
Mezi další nepříznivé asociace spojené s pomalými webovými stránkami patří snížená důvěryhodnost, nižší vnímaná kvalita a stránky považované za méně zajímavé a atraktivní. Zvýšená frustrace uživatelů a zvýšený krevní tlak jsou další dva efekty, které jsme v určitém okamžiku pravděpodobně všichni zažili! Jak ale můžeme zajistit, aby se naše webové stránky načítaly dostatečně rychle, abychom se těmto problémům vyhnuli?
Jednou z prvních věcí, na které se podíváme, je velikost vašeho kódu HTML. Toto je pravděpodobně jedna z nejvíce přehlížených oblastí, možná proto, že se lidé domnívají, že u moderních širokopásmových připojení již není tak relevantní. Některé systémy pro správu obsahu jsou poměrně liberální, pokud jde o množství, které chrlí - jeden z důvodů, proč může být lepší zpracovat vaše vlastní stránky.
Jako vodítko byste měli snadno zvládnout přizpůsobit většinu stránek v 50 kB kódu HTML, a pokud máte méně než 20 kB, děláte to velmi dobře. Existují samozřejmě výjimky, ale toto je celkem dobré pravidlo.
Je také důležité mít na paměti, že lidé nyní na mobilních zařízeních procházejí plné weby častěji. Rozdíly v rychlosti mezi stránkami prohlíženými z mobilu jsou často znatelnější, protože mají nižší přenosové rychlosti než kabelové připojení. Dva konkurenční weby s rozdílem velikosti 100 kB na stránku mohou v některých pomalých mobilních sítích znamenat více než jednu sekundu rozdíl v době načítání - a to do oblasti „přerušeného toku myšlenek“ specifikované Jakobem Nielsenem. Rychlejší webová stránka ořezávače bude při procházení mnohem méně frustrující, což dává výraznější konkurenční výhodu nad tučnějšími webovými stránkami a povede dlouhou cestu k podpoře opakovaných návštěv.
Jednou z důležitých funkcí většiny webových serverů je schopnost poskytovat HTML v komprimovaném formátu. Protože HTML přirozeně obsahuje spoustu opakujících se dat, je to ideální kandidát na kompresi. Například 18,1 kB HTML domovské stránky se sníží na 6,3 kB, když se zobrazí v komprimovaném formátu. To je 65% úspora! Kompresní algoritmy zvyšují efektivitu, čím větší část textu musí pracovat, takže s většími stránkami HTML uvidíte větší úspory. Stránka 138,1 kB na populárním fóru je při komprimaci snížena na 25,7 kB, což je úspora více než 80 procent - což může výrazně zlepšit celkovou dobu přenosu zdrojů.
Poskytování HTML v této podobě nemá prakticky žádné negativy; každý by to měl povolit pro veškerý svůj obsah HTML.Některé webové servery mají různá nastavení pro kompresi statického a dynamicky generovaného obsahu, takže stojí za to zajistit, abyste pokud možno poskytovali komprimovaný obsah pro oba.
Sítě pro doručování obsahu
Sítě pro doručování obsahu (známé jako CDN) mohou také výrazně zkrátit dobu načítání vašeho webu. CDN jsou kolekce serverů distribuovaných po celém světě, které obsahují kopie vašeho obsahu. Když uživatel požádá o obrázek z vašeho webu, který je hostován na CDN, bude k zobrazení obrázku použit server v CDN, který je geograficky nejblíže uživateli.
Existuje mnoho služeb CDN. Některé z nich jsou velmi nákladné, ale inzerují, že nabídnou lepší výkon než levnější CDN. Začaly se také objevovat bezplatné služby CDN a může být užitečné experimentovat s nimi, zda mohou zlepšit výkon vašeho webu.
Při používání sítě CDN je důležité se ujistit, že jste ji nastavili správně, abyste neztratili žádnou hodnotu SEO. Může se stát, že z obrazů hostovaných na vaší doméně budete dostávat hodně provozu, v závislosti na povaze vašeho webu, a jejich přesunutím do externí domény to může nepříznivě ovlivnit váš provoz. Služba Amazon S3 umožňuje nasměrovat subdoménu na její CDN, což je velmi výhodná funkce v CDN.
Poskytování obsahu v jiné doméně (například CDN) nebo subdoméně ve vašem vlastním názvu domény, která nenastavuje soubory cookie, má další klíčovou výhodu. Když je soubor cookie nastaven na doménu, prohlížeč odešle data souborů cookie s každým požadavkem každému prostředku ve stejné doméně. Častěji než ne, data cookie nejsou vyžadována pro statický obsah, jako jsou obrázky, soubory CSS nebo JavaScript. Rychlost nahrávání uživatelů webu je často mnohem nižší než rychlost stahování, která může v některých případech způsobit výrazné zpomalení doby načítání stránky. Při použití jiného názvu domény k poskytování vašeho statického obsahu nebudou prohlížeče tato zbytečná data cookie odesílat, protože mají přísné zásady pro více domén. To může významně urychlit doby požadavku pro každý zdroj.
Soubory cookie na webových stránkách mohou také zabírat většinu požadavků HTTP; 1 500 bajtů je kolem nejčastěji používaného limitu jednoho paketu pro velké sítě, takže pokud jste schopni udržet své požadavky HTTP pod tímto limitem, měl by být odeslán celý požadavek HTTP v jednom paketu. To může nabídnout vylepšení doby načítání stránky. Google doporučuje, aby vaše soubory cookie neměly velikost menší než 400 bajtů - to je dlouhá cesta k udržení požadavků HTTP na vašem webu pod limitem jednoho balíčku / 1 500 bajtů.
Další techniky
Existují i jiné, snáze implementovatelné techniky, které mohou nabídnout velké výhody pro rychlost vašeho webu. Jedním z nich je umístit soubory JavaScriptu na konec dokumentu HTML, těsně před koncovou značku těla, protože prohlížeče mají limity na to, kolik zdrojů si mohou paralelně stáhnout ze stejného hostitele.
Původní specifikace HTTP 1.1 napsaná v roce 1999 doporučuje, aby si prohlížeče stahovaly pouze dva zdroje paralelně z každého názvu hostitele. Ale moderní prohlížeče mají ve výchozím nastavení limit kolem šesti. Pokud má vaše webová stránka více než šest externích zdrojů (například obrázky / soubory JavaScriptu / CSS), může vám nabídnout vylepšený výkon při poskytování z více domén (například subdoména v názvu vaší hlavní domény nebo CDN), abyste zajistili, že prohlížeč nedosáhne svého maximálního limitu pro paralelní stahování.
Místo rozdělení více požadavků na různé domény můžete zvážit jejich kombinaci. Ke každému požadavku HTTP je přidružena režie. Desítky obrázků, jako jsou ikony na vašem webu, sloužící jako samostatné zdroje, vytvoří spoustu nehospodárných režijních nákladů a způsobí zpomalení vašeho webu, často významné. Spojením obrázků do jednoho obrázku známého jako „sprite sheet“ můžete snížit počet požadovaných požadavků. Chcete-li zobrazit obrázek, definujete jej v CSS nastavením šířky a výšky prvku na obrázek, který chcete zobrazit, a poté nastavením pozadí na sprite list. Pomocí pozice na pozadí Vlastnost můžeme přesunout sprite list pozadí na pozici tak, aby se na vašem webu objevila jako zamýšlený obrázek.
Sprite prostěradla nabízejí i další výhody. Pokud používáte obrázky umístěné myší, jejich uložení na stejném listu sprite znamená, že při zahájení přejíždění myší nedochází ke zpoždění, protože obrázek myši již byl načten do tabulky sprite! To může výrazně zlepšit vnímanou dobu načítání uživatele a vytvořit mnohem citlivější web.
Určení rozměrů všech ostatních obrázků v obrázek /> značky je také důležitým faktorem při zvyšování vnímané doby načítání vaší webové stránky. Je běžné, že vývojáři explicitně nenastavují šířku a výšku obrázků na stránkách. To může způsobit, že se velikost stránky při načtení každého obrázku (částečně) zvětší, což způsobí, že se věci budou zdát pomalé. Pokud jsou nastaveny explicitní rozměry, může prohlížeč při načítání obrázku vyhradit místo pro obrázek, zastavit změnu velikosti stránky a někdy výrazně zlepšit vnímanou dobu načítání uživatele.
Co dalšího tedy můžeme udělat, abychom to vylepšili? Jednou z funkcí dostupných v HTML5 je předběžné načítání. Předběžné načítání umožňuje načítání stránek a zdrojů dříve, než o ně uživatel skutečně požádal. Jeho podpora je aktuálně omezena na Firefox a Chrome (s alternativní syntaxí). Jeho snadná implementace a užitečnost při zlepšování vnímané doby načítání vaší webové stránky je však tak velká, že je třeba implementaci zvážit.
! — Předběžné načítání Firefoxu -> link rel = "prefetch" href = "http://www.example.com/page2.html">! - Chrome Prerender -> link rel = "prerender" href = "http: / /www.example.com/stranka2.html">!— Obě v jednom řádku -> odkaz rel = "předběžné vykreslení předběžného načtení" href = "http://www.example.com/stranka2.html">
Mezi předběžným načítáním a předběžným vykreslením je rozdíl v chování. Mozilla prefetch načte prostředek nejvyšší úrovně pro danou adresu URL, obvykle samotnou stránku HTML, a tam se načítání zastaví. Google předobjednávka načte také podřízené zdroje a slovy Google „provede veškerou práci potřebnou k zobrazení stránky uživateli, aniž by ji skutečně zobrazoval, dokud uživatel neklikne“.
Aspekty předběžného načítání a předběžného vykreslování
Ale použití této funkce přichází také s důležitými úvahami. Pokud předběžně vykreslíte nebo načtete příliš mnoho podkladů nebo stránek, může dojít k narušení celého prohlížení webu; pokud máte nějaké statistiky na straně serveru, mohou být silně zkresleny. Pokud uživatel neklikne na předinstalovaný zdroj a opustí váš web, může váš měřič statistik počítat návštěvu jako dvě zobrazení stránky, nikoli skutečné. To může být zavádějící pro důležité metriky, jako je míra okamžitého opuštění.
Chrome předobjednávka má další upozornění, na které si vývojáři musí být vědomi, protože předrenderovaná stránka spustí JavaScript. Předběžné vykreslení načte stránku téměř přesně stejným způsobem, jako kdyby uživatel klikl na odkaz. Chrome s předběžným vykreslením neodesílá žádné speciální záhlaví HTTP; Rozhraní API pro viditelnost stránky vám však umožňuje rozlišit, zda je stránka předběžně vykreslena. To je zásadně důležité znovu pro všechny skripty třetích stran, které používáte, jako jsou reklamní skripty a nástroje pro sledování statistik (Google Analytics již používá API pro viditelnost stránky, takže si s tím nemusíte dělat starosti). Nesprávné zacházení s těmito prostředky pomocí rozhraní API pro viditelnost stránky vás znovu vystavuje riziku zkosení důležitých metrik.
Použitím prefetch a předobjednávka na stránkovaném obsahu je pravděpodobně bezpečná a užitečná implementace - například na webové stránce s výukovými programy, která je rozdělena do několika sekcí. Zejména u obsahu, jako jsou výukové programy, je pravděpodobně důležité držet se hranic „nepřetržitého toku myšlenek“ Nielsen.
Google Analytics může také poskytnout cenné vodítka o tom, které stránky možná budete chtít předběžně vykreslit / předběžně načíst. Pomocí analýzy na stránce můžete určit, na který odkaz na domovské stránce kliknete nejpravděpodobněji. V některých případech s vysoce definovanými výzvami k akci může být toto procento extrémně vysoké - což z něj činí vynikajícího kandidáta na předběžné načítání.
Předběžné načítání i předběžné vykreslování fungují napříč doménami - neobvykle liberální postoj pro prohlížeče, které jsou na přístup mezi doménami obvykle extrémně přísné. To však pravděpodobně funguje ve prospěch Google a Mozilly, protože mohou svým uživatelům vytvořit rychlejší zážitek z procházení několika způsoby, což nabízí značnou konkurenční výhodu oproti jiným prohlížečům, které tyto funkce ještě nepodporují.
Předběžné načítání a zejména předběžné vykreslování jsou výkonné nástroje, které mohou výrazně zlepšit vnímanou dobu načítání webových stránek. Je však důležité pochopit, jak fungují, aby zážitek z procházení vašich uživatelů nebyl přímo a negativně ovlivněn.
Načítání obsahu Ajax
Dalším způsobem, jak zlepšit časy načítání, je použití Ajaxu k načtení obsahu na rozdíl od opětovného načtení celé stránky - efektivnější je, že načítá pouze změny, nikoli pokaždé obklopující obsah.
Problém se spoustou načítání Ajaxu spočívá v tom, že se může cítit jako nepřirozený zážitek z procházení. Pokud nebudou správně provedeny, tlačítka zpět a vpřed nebudou fungovat podle očekávání uživatele a provádění akcí, jako je přidávání stránek do záložek nebo obnovování stránky, se také chová neočekávaným způsobem. Při navrhování webů je vhodné nezasahovat do chování na nízké úrovni, jako je toto - je to pro uživatele velmi znepokojivé a nepřátelské. Ukázkovým příkladem toho by mohlo být úsilí některých webů o deaktivaci pravého kliknutí na jejich webové stránky jako marného pokusu zabránit porušování autorských práv. Přestože implementace Ajaxu neovlivňuje činnost prohlížeče se stejným záměrem zakázat klepnutí pravým tlačítkem, efekty jsou podobné.
HTML5 nějakým způsobem řeší tyto problémy pomocí rozhraní History API. Je dobře podporován v prohlížečích (kromě prohlížeče Internet Explorer, i když se plánuje, že bude podporován v IE10). Při práci s historickým API HTML5 můžeme načítat obsah pomocí Ajaxu a zároveň simulovat „normální“ procházení pro uživatele. Při správném použití fungují tlačítka zpět, dopředu a obnova podle očekávání. Lze také aktualizovat adresu URL adresního řádku, což znamená, že záložky nyní opět fungují správně. Pokud je implementováno správně, můžete odstranit spoustu opakovaného načítání zdrojů a také mít půvabné záložní stránky pro prohlížeče s deaktivovaným JavaScriptem.
Existuje však velká nevýhoda: v závislosti na složitosti a funkci webu, který se pokoušíte vytvořit, je obtížné implementovat načítání obsahu Ajaxu pomocí rozhraní History API způsobem, který je pro uživatele neviditelný. Pokud web používá také skriptování na straně serveru, můžete také zjistit, že píšete věci dvakrát: jednou v JavaScriptu a znovu na serveru - což může vést k problémům s údržbou a nesrovnalostem. Může to být obtížné a časově náročné zdokonalit, ale pokud to funguje, jak bylo zamýšleno, můžete výrazně snížit skutečné i vnímané doby načítání pro uživatele.
Při pokusu o zvýšení rychlosti vašeho webu můžete narazit na některé neřešitelné problémy. Jak bylo uvedeno na začátku tohoto článku, není žádným tajemstvím, že Google používá rychlost stránky jako metriku hodnocení. To by měla být významná motivace pro zlepšení rychlosti vašeho webu. Můžete si však všimnout, že když použijete prostředky, jako jsou přehledy rychlosti stránek Nástrojů pro webmastery Google, budou hlásit pomalejší časy načítání, než byste čekali.
Příčinou mohou být skripty třetích stran, jako jsou tlačítka Facebook Like nebo Tweet. Často mohou mít čekací doby v řádu stovek milisekund, což může výrazně snížit dobu načítání celého vašeho webu. To však není argument k odstranění těchto skriptů - je pravděpodobně důležitější mít tlačítka sociálních médií na vašem webu. Tato tlačítka obvykle zabírají relativně malá místa na vaší stránce, takže nijak významně neovlivní dobu načítání vnímanou návštěvníkem - o co bychom se měli primárně starat při optimalizaci rychlosti.
Objevte 101 tutoriálů CSS a Javascript na našem sesterském webu Creative Bloq.
