Přejít k navigační liště

Zdroják » Webdesign » Front-end vývojáři, dejte si pozor na HTTP2! Mohli byste webům škodit.

Front-end vývojáři, dejte si pozor na HTTP2! Mohli byste webům škodit.

Články Webdesign

HTTP2 změní způsob, jakým vytváříme webové aplikace. Nejčastější a nejlepší optimalizační praktiky z HTTP1 jsou při použití nového protokolu kontraproduktivní a škodlivé. Pokud je budete používat, můžete stránky výrazně zpomalovat.

Nálepky:

HTTP1.X je pro většinou stávajících stránek pomalé a neefektivní. Jde o starý protokol, který byl navržen dlouhou dobu před tím, než se vůbec tušilo, jaké podoby web dosáhne. Přestože stávající protokol koná svou práci, není příliš efektivní, neboť po něm požadujeme mnohem komplexnější služby, než pro jaké byl původně navrhnut.

Aby se HTTP1 stránka načetla v rozumném čase, musíme si mnohdy pomáhat sérií hacků, abychom vymáčkli ze starého protokolu maximum:

Nejčastější optimalizační techniky

Sprites

Anglicky sprites, českoanglicky často „sprity“ či „sprajty“, je technika skládání několika různých, obvykle menších, obrázků či ikon do jednoho velkého souboru. Soubor je pak následně napozicován v CSS tak, aby se zobrazila pouze výseč, jen malá část tohoto obrazu, kde je původní obrázek umístěn.

Ukázka spritu

Ukázka spritu (obrázek pochází z wikipedie)

Concatenating

Concatenating, česky zřetězení, je slučování více CSS či JS souborů do jednoho obrovského. Technika se obvykle řeší programově, přes různé task runnery (například známý Grunt). CSS concatenating kupříkladu umožňuje LESS, SASS či Stylus, což jsou nástroje, které rozšiřují CSS o různé dynamické prvky a kromě zmiňovaného zřetězení umí výsledný soubor i zminifikovat a řadu jiných fint. JS concetating ve své úplně nejjednodušší formě umí program Prepros, kde stačí na začátek libovolného js souboru definovat, které soubory se mají spojit a jak a pokud necháte program skrytý na pozadí, všechno udělá za vás.

Assets z domén bez cookies

Poskytování assetů z domén nezatížených cookies. Assets jsou dodatečné zdrojové soubory, kupříkladu sady písem, css soubory, neobsahové obrázky a podobně. Pro tento případ se obvykle používá specializovaných služeb, neboť se poskytování assetů hůře řeší na vlastním serveru (ale lze to). Jednou z takových služeb je systém zvaný Content Delivery Network (CDN), u nás například velmi populární český CDN77.

Sharding

Sharding, neboli vytváření více domén nebo sub-domén k hostování assetů, jako jsou obrázky. Rovněž se hůře řeší na vlastním serveru (serverech), je snažší použít pro to specializovanou službu.

Aktuální implementace

První dvě techniky jsou navrženy k tomu, aby se vyhýbaly několikanásobným HTTP requestům. V HTTP1 je požadavek (request) velmi drahá záležitost. Trvá příliš dlouho a každý požadavek může být doslova naládován cookies, které spolu s ním musí být pokaždé zasílány. Navíc žádný z nich není komprimován. Je proto rychlejší sloučit několik souborů dohromady a mít všechno přeneseno najednou, než poskytovat jednotlivé soubory odděleně.

Třetí technika se používá k tomu, aby zminimalizovala čas nutný k získání assetů – aby odstranila cookies, které je třeba neustále zasílat jako část požadavku, což ústí k tomu, že pokaždé je zároveň přenesena řada bordelu. Pokud jednotlivé soubory umístíte na různé domény, které nepoužívají cookies, tyto soubory pak nebudou nebudou cookies zatíženy a celý proces se výrazně zrychlí.

Poslední technika, sharding, existuje teprve krátce. Vznikla po implementaci HTTP/1.1 specifikací, které omezují počet http requestů pro jednu (sub)doménu na pouhé dva.
V dřívějších dobách se maximální počet spojení se serverem výrazně lišil. Některé prohlížeče podporovaly 8 až 15 requestů, což přinášelo zároveň řadu problémů.

Pro porovnání podpora trvalého spojení se serverem u starších prohlížečů:

  • Firefox 2: 2
  • Firefox 3: 6
  • Opera 9.26: 4
  • Safari 3.0.4: 4
  • IE 7: 2
  • IE 8: 6 (pro dial-up vytáčené připojení bylo číslo mnohem nižší)

Se snížením počtu requestů (lze říci, že průměr předtím byl kolem 4 najednou), se začala rozvíjet právě zmiňovaná technika sharding, která dokáže tento limit obejít tak, že se jednotlivé zdrojové soubory (assets) rozdistribují mezi různé domény, takže prohlížeč obvykle přistupuje v jednom čase k více souborům. Z toho důvodu se také často doporučuje u frameworků a jiných volně dostupných css či js souborů používat CDN server, pokud jej tvůrci nabízejí. Zjednodušeně řečeno, techniku sharding používáte, když například nejpoužívanější js framework jQuery nenutíte uživatele stahovat z vašeho serveru, ale ve svém zdrojového html souboru nalinkujete volně dostupný script z adresy http://code.jquery.com/jquery-latest.min.js

Budoucnost s HTTP2

HTTP2 je téměř zde, je založeno na síťovém protokolu SPDY a dělá všechno mnohem efektivnější. Což ale také znamená, že všechny optimalizační techniky z HTTP1 se stávají škodlivými. Udělají HTTP2 stránku pomalejší, nikoliv rychlejší, čili důrazně varuji, pokud vyvíjíte stránku, kde víte, že bude nový http protokol – nepoužívejte je!

HTTP2 řeší problém s více požadavky efektivněji, pomocí technik, které dělá automaticky:

  • Umožňuje otevřenou komunikaci pro zpětné použití requestu, čili není třeba nového zasílání hlaviček a tudíž složitého navazování komunikace, kterou HTTP1 potřebuje pro každý nový soubor
  • HTTP2 oproti HTTP1 rovněž používá kompresi nejen dat, ale i hlaviček, čili velikost každého požadavku je výrazně nižší a tudíž rychlejší
  • HTTP2 umí multiplexovat – umí odesílat a přijímat více souborů v té samé chvíli zapomocí jednoho spojení

To znamená, že starší HTTP1 techniky optimalizace zmiňované v tomto článku nejen že nejsou třeba, ale zároveň vše zpomalují. Velmi často tak můžete načítat soubory, které nejsou v tuto chvíli pro danou stránku potřeba, což jsou problémy, které defaultně vytváří concatenation a sprity. Zároveň sharding v důsledku komunikaci s DNS servery (DNS lookups) vše zpomalí, a to nehledě na to, že taková věc v HTTP2 již vůbec není potřeba.

Zjednodušeně řečeno – budete-li vytvářet frontend pro stránku o které víte, že bude přenášena přes HTTP2 – ujistěte se, že nepoužíváte optimalizační techniky, které znáte z HTTP1, mohli byste stránky výrazně zpomalovat.

Kde hledat informace dále

Vznik článku byl inspirován článkem od Matta Wilcoxe

Komentáře

Subscribe
Upozornit na
guest
19 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
severak_cz

Přijde mi, že by bylo lepší dát závěr na začátek článku.

sharkodlak

Přijde mi pořád efektivní mít zvláštní doménu na servírování statického obsahu. I když jsou hlavičky komprimované, stále je zbytečné je přenášet tam a zpět, pokud nejsou vůbec potřeba. Navíc mám pocit, že v dnešní době, kdy převažují asymetrická připojení k internetu (kde download může být třeba 10* rychlejší než upload), se výrazněji ušetří přenosový čas každého požadavku.

Souhrn:

  • jeden dotaz na DNS navíc
  • zmenšení přenášených dat při každém požadavku
  • urychlí přenosy i pro HTTP/1.x
Dor

Concatenating považuji i za součást obfuskace. Podle vzoru: Krádeži nelze zabránit, ale každá další překážka může rozhodnout o tom, že už se to nevyplatí krást.

Jirka Kosek

A k tomu závěru se došlo teoreticky, nebo na základě měření skutečného webu servírovaého přes oba protokoly? Ptám se, protože v článku jsou různé nepřesnosti.

Jaroslav Bereza

Co třeba změna obrázku na najetí myši? Nebude to problikávat? Není tohle třeba výjimka kdy spritesheet použít?

Jirka Kosek

Umožňuje otevřenou komunikaci pro zpětné použití requestu, čili není třeba složitého navazování komunikace, kterou HTTP1 potřebuje pro každý požadavek

Tak to v HTTP/1.1 funguje stejně, spojení se standardně neuzavírá, v HTTP/1.0 jde toto chování vynutit pomocí hlavičky Keep-Alive

HTTP2 oproti HTTP1 rovněž používá kompresi, čili velikost každého požadavku je výrazně nižší a tudíž rychlejší

HTTP/1.1 samozřejmě kompresi podporuje, viz hlavička Content-Encoding (nepodporuje však komprimaci hlaviček)

HTTP2 je bezesporu mnohem lepší a efektivnější, ale nemá cenu šiřit o HTTP/1.0/1.1 bludy.

karel

když například nejpoužívanější js framework jQuery nenutíte uživatele stahovat z vašeho serveru, ale ve svém zdrojového html souboru nalinkujete volně dostupný script z adresy http://code.jquery.com/jquery-latest.min.js

Aneb jak si na webové stránky zatáhnout zranitelnost.
Je celkem sranda, že na rootu dnes vyšli články o bezpečnosti a zde se nabádá k používaná nebezpečných věcí.
Tohle vkládání javascriptu od kdejaké služby je strašlivá hloupost a neznalost. A navíc přes http. Je to jak, kdyby ste dali klíče od bytu náhodnému kolemjdoucímu a on Vám slíbyl, že po dobu dovoléne Vám zaleje kytky, ano nic se nemusí stát nebo taky po příjezdu zjistíte, že Vám krom zalívání kytek také vybílil.

wsh

Tady bych viděl prostor pro vylepšení prohlížečů. Kdyby kodér mohl místo konkrétního url odkazovat na knihovnu s názvem XYZ ve verzi vM.N s nějakým checksumem a fallback url a prohlížeč by to držel v samostatné cache sdílené mezi weby, mohlo by to zejména na mobilech dost přenosu dat ušetřit.

karel

ano to by mohla být cesta, dokonce by možná stačil checksum pro identifikaci,
jen je otázkou co by na to řekli provozovatelé cdn, že jim někdo leze do zelí.

ale teď vážně, většina postupů, rad a triků jak zvíšit rychlost načítání vebů je vlastně marginální v porovnaná s nutností cucnout si jquery, jquery.ui nebo bootstrap ….. opravdu zazdílení obsahu těchto knihoven by by bohatě stačilo

Jan Žák

Na to už tu máme W3C draft http://www.w3.org/TR/SRI/

Martin Šoch

To je sice všechno hezké, ale co když chci ty HTTP2 vychytávky používat už teď? Existuje nějaká funkční serverová implementace, vhodná do produkce? Třeba „server push“ by se mi sakra hodil…

Martin Hassman

Přehled podpory na serverech jsem našel na https://en.m.wikipedia.org/wiki/HTTP/2#HTTP.2FHTTPS_servers všude tam zatím vidím experimental nebo beta.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.