Optimalizujeme pro rychlost: HTTPS

Posted 23. 11. 2014 / By Petr Soukup / Vývoj

S přechodem na HTTPS je spojen mýtus, že se tím web zpomalí, což ale není pravda. Perfektně je to sepsáno na webu istlsfastyet.com, ale je to poměrně komplikovaná problematika, takže bych tu chtěl udělat alespoň souhrn a obrázkovou ukázku.

Náročnost na prostředky

Historicky bylo vždy HTTP defaultní a HTTPS se používalo jen když nebyla jiná možnost, protože to znamenalo zvýšenou zátěž na server. S každým spojením bylo potřeba vyjednat komunikaci, vyměnit klíče a následně ještě zašifrovat všechna přenášená data. Dnes už ale nic z toho neplatí.

Máme modernější šifry, které jsou mnohem bezpečnější a zároveň úspornější na prostředky. Režie s šifrováním je minimální, protože už je možné dělat ji jen při prvním spojení a následně recyklovat. Nemluvě o tom, že máme mnohem výkonnější hardware, takže nás takto drobné rozdíly netrápí. Bohužel jsem k tomu nenašel žádný hezký graf, ale když jsme převedli všechny eshopy na https, tak celkové zatížení serverů zůstalo zcela stejné.

HTTPS je samozřejmě v základu o něco málo pomalejší, protože se musí řešit více věcí než u hloupého HTTP, ale je tu jeden zcela zásadní trik, který celou situaci mění.

Modernější protokoly - úspora spojení

HTTPS (respektive TLS) přidává do komunikace funkci NPN (Next Protocol Negotiation), která umožní serveru domluvit si s klientem jiný protokol pro komunikaci. Nemusí tak používat 15 let staré HTTP a místo toho se domluví na modernějším protokolu, který oba podporují. Nás aktuálně zajímá SPDY (a jeho nástupce HTTP/2), který má podporu v 89% prohlížečů a podpora stoupá.

Spojování požadavků

Při načtení stránky na HTTP se kvůli každému obrázku, stylu atd musí sestavit požadavek, poslat na server a počkat na odpověď. V každém požadavku se posílají všechny cookies, hlavičky a tak dále. Pokud se přenáší třeba malá ikonka, tak režie může zabrat mnohem více dat než samotná data obrázku.

SPDY to řeší tím, že spojuje více požadavků do jednoho spojení. Načte se tak HTML stránka a když se mají stáhnout třeba obrázky produktů, tak se nestahují po jednom, ale pošlou se všechny najednou.

Komprimace hlaviček

Na webu se pro přenos standardně používá komprese GZIP. Problém ale je, že se komprimuje pouze obsah a nikoliv hlavičky. Pokud pak jsou třeba velké cookies, tak se vždy přenáší celé bez komprese. SPDY tento problém řeší a komprimuje vše.

Kompatibilita

Kouzelné na tom je, že je SPDY zcela kompatibilní. Pokud ho klient neumí, tak se zkrátka ani nepoužije. Pouze zapouzdřuje klasické HTTP, takže ani tvůrce webu se s ním nemusí nijak zabývat. Pokud je web na https, tak stačí SPDY jen zapnout na webserveru a je hotovo.

Srovnání

Pro názornost jsem vyrobil malý test. Jednoduchou HTML stránku, která načítá 40 různých malých obrázků (u eshopu poměrně běžná situace). Stránku jsem nejprve několikrát načetl, aby se vytvořilo keep-alive a pak načetl bez cache.

(graf jsem lehce upravil, aby to šlo porovnat pod sebou)

HTTP (bez SPDY)

nospdy

HTTPS (SPDY)

spdy2

Rozdíl je na první pohled vidět. V případě HTTP se sice obrázky stahují paralelně, ale vždy po dávkách. Ke každému obrázku se navíc přenést spousta informací navíc. SPDY tohle všechno řeší a přestože jeden požadavek trvá déle, tak celá stránka se načítá poloviční čas.

Cenu certifikátu jsme už vyřešili dříve a teď i rychlost. Co vám ještě brání nasadit HTTPS? :)

 

Další díly:

  1. Jak se loví milisekundy (nejen v #nettefw)
  2. Optimalizujeme pro rychlost: Obrázky
  3. Optimalizujeme pro rychlost: HTTPS
  4. Efektivní minifikace Javascriptu
  5. Optimalizujeme: critical+asynchronní CSS


O blogu
Blog o provozování eshopů a technologickém zázemí.
Aktuálně řeším hlavně cloud, bezpečnost a optimalizaci rychlosti.

Rozjíždím službu pro propojení eshopů s dodavateli.