Zrychlujeme web
Úvodem je nutno připomenout, že neexistuje žádný konkrétní způsob, kterak načítání a samotný chod webové stránky urychlit. Vždy se jedná jen o sadu pravidel a triků, kterak zoptimalizovat stávající stav.
Každý požadavek je drahý
Browser musí nejdříve získat z názvu domény adresu, navázat TCP spojení a poté si vyžádat stránku, styly, scripty a obrázky. I když je naše „vzdálenost“ k serveru třebas jen 20ms, musíme to vynásobit počtem požadavků.
- 1× DNS lookup
- 1× navázání TCP spojení
- 1× požadavek na získání samotné stránky
- + 1 pokud dojde k redirectu
- 1× pro každý styl
- 1× pro každý externí script
- 1× pro každý obrázek (v css, nebo ve stránce)
Tím samotný výčet zpomalení nekončí. Stránka se musí před zobrazením „sestavit.“ Tedy aplikuji se styly a provede se javascript. Ale i to se dá optimalizovat.
Co s tím ?
Při optimalizaci se nám bude hodit projekt Browserscope, kde najdeme informace a statistiky jednotlivých prohlížečů.
DNS + TCP
S tímto nic nenaděláme. Potřebuje to pro základní komunikaci mezi browserem a serverem.
Hlavní stránka + redirect
Se samotnou stránkou toho také moc nenaděláme. Některé framworky ale podporují přesměrování na straně serveru. Tím se ušetří jeden požadavek.
Kaskádové styly
Komprese
- Všechny styly dát pouze do jednoho souboru a použít komprimačńí nástroj na zmenšení samotné velikosti
- Můžeme použít například [webový nástroj csscompressor
- Nebo na straně serveru ruby knihovnu a mít aktuální výsledek po dobu jedné revize aplikace
Optimalizace
Používat co nejpopisnější css selektory, abychom odlehčili rendrovacímu nástroji
div.selected {width:500px;height:500px} div.selected > span {background-color:red} div.selected > span.inactive {background-color:gray}
Scripty
Komprese kódu
Můžeme použít například službu od googlu. A nebo použít celý projekt s možností stáhnutí javovského programu a použít ho stejně jako css kompresor na straně serveru. Tento nástroj slouží zároveň jako validátor, odstraňuje takzvaně mrtvý kód (což mnohdy není úplně ideální, jelikož ho můžeme volat odjinud) a kód zároveň optimalizuje.
Příklady
//Vstup var height = 50; var heightAdd = 25; function tellMeWidth() { alert(height + heightAdd); } tellMeWidth()
Použití maximální komprese a optimalizace
Kompresor v tomto režimu nepracuje jen s kódem samotným, ale i celým kontextem. Sečte proměnné a odstraní celé volání metody, jelikož v daném kontextu není použito jinak
alert(75);
Použití obyčejné komprese
var a=50,b=25;function c(){alert(a+b)};c();
Či jen odstranění „white spaces“
var height=50,heightAdd=25;function tellMeWidth(){alert(height+heightAdd)}tellMeWidth();
Programátorská optimalizace
- Důležité je kód psát tak, aby byl rychlý, přehledný a nedocházelo v něm k zbytečným operacím
- Nenačítat kód, který na stránce nepoužíváme
- Kód, který používáme, ale nepotřebujeme ho při inicializaci stránky (například nějaké komponenty jako je kalendář, autocompleter apod.) načítat až poté
- K tomu použijeme takzvaný návrhový vzor [http://en.wikipedia.org/wiki/Lazy_loading Lazy loading]
- Dlouhý a vyčerpávající článek s mnoha možnostmi, kterak toho v JS dosáhnout
- Velmi komplexní implementace pro javascript
- A jednoduchá a účelná implementace
- „Safecall“ implementace v js
Obrázky
CSS pozadí
Zde je jen použití triku, kdy se všechny obrázky tvořící pozadí a nemají nastavenou vlastnost repeat uloží do jednoho obrázku a jejich umístění se určuje pomocí souřadnic
body.background-main-bg * { background-image: url(main-bg.png); background-color:transparent; background-repeat: no-repeat; background-position: –10000px –10000px;} .album_bg {background-position: 0px 0px !important;} .bg_reg_button {background-position: 85px 0px !important;} .bg_reg_button_yellow {background-position: 107px 0px !important;} .bg_reg_button_green {background-position: 129px 0px !important;} .ikona {background-position: 151px 0px !important;} .ico_concepts {background-position: 151px 41px !important;}
Obrázky ve stránce
Toto se dá řešit jedině pomocí javascriptu, kdy obrázky, které nejsou vidět při úvodním zobrazení načteme později například pomocí pluginu v jQuery LayzyLoad
Článek inspirován přednáškou Make the web faster na Google Developer Day 2009
-
Související články na blogu RailsWorx Warťásek
-
In-Page Editing 18. 1. 2010 9:54
-
Ruby on Rails - Vnořené šablony 3. 11. 2009 10:30
-
Ruby Eigenclass (Singleton Class) 12. 2. 2010 9:00
-
Web navigation testing methods 18. 12. 2009 11:43
-
Sign-up framework 9. 12. 2009 3:21
-
Go - nový programovací jazyk od Googlu 12. 11. 2009 8:40
-
-
Související články na ostatních blozích
-
Školácká chyba na Mikroblogy.cz pro Facebook 2. 2. 2009 17:08
-
Redesign Tarifomat.cz - co vy na to? 20. 9. 2012 10:50
-
Odpověď pro všechny, kteří potřebují "malé a jednoduché" internetové stránky 11. 10. 2010 21:41
-
Nový fulltext na Seznam.cz spuštěn 16. 9. 2010 14:13
-
AJAX výběr zboží na e-shopu (prosím komentáře) 13. 9. 2010 15:29
-
Naše nová korporátní identita (prosím komentáře) 8. 9. 2010 17:55
-
-
Související články na serveru Lupa.cz
-
Accelerated Mobile Pages od Googlu: Je velmi snadné podlehnout hypu 14. 10. 2015 9:23
-
AMP HTML: impuls pro weby, které se na mobilech načítají pomalu 9. 10. 2015 6:30
-
Nová kniha o skriptování v moderním DOM volně online 21. 9. 2012 9:23
-
Jak se kreslí realtime volební mapy pro statisíce lidí 6. 2. 2018 8:00
-
Únik dat z Nevyhazujto.cz aneb Co se dá zjistit, když máte v heslu název webu 1. 2. 2018 6:30
-
Vítězem WebTop100 je FotoŠkoda, osobností digitálního marketingu Filip Podstavec 15. 11. 2017 20:16
-
-
Lukáš Svoboda (neregistrovaný) 81.19.47.---
Zdravím,
Rozhodně doporučuji další práci s
Cache-Control a gzipem
Accept-Encoding: gzip, deflate
Content-Encoding: gzip
podle mého asi nejdůležitější,.
jinak více zde http://developer.yahoo.com/performance/rules.html -
WuDo (neregistrovaný) 85.70.131.---
Pokud by všechny grafické prvky (v css) byly uloženy v jednom souboru, tak se všechny zobrazí až poté, co tento soubor bude natažen
x
Snést drobně větší komunikaci mezi serverem a browserem, ale uživateli se grafika načítá postupně => tím minimálně vidí, že se něco děje....
U mě vítězí druhá možnost...
-
Petr (neregistrovaný) 93.99.73.---
Jak zrychlit web? To co je výše popsané samozřejmě pomůže, ale základem je rychlé generování samotných stránek na serveru. Pokud web pojede na pomalém nebo přetíženém serveru, nebo jestli to bude nějaký "slepenec" amatérských kódů nalezených na internetu - tak tomu už nepomůže ani světcená voda.
-
Eduard Hlava (neregistrovaný) 89.102.143.---
Tohleto ladění je fajn, zejména u webů, které mají obrovkou návštěvnost. Ale dokud vám to bude zdržovat databáze, která je většinou na vině toho, že je web pomalý (resp. DB má šílenou strukturu a dotazy stojí za prd), pak vám nějaké tisícinky v podobě komprese css kódu nepomůžou.
-
Labir (neregistrovaný) 217.195.174.---
Mě hodně pomohlo vhodné napsání frameworku - nejlépe s dvojitým bufferováním, popré nabufferuje analýzu HTML šablony takže generátor vkládající hodnoty již ví kam co vložit a podruhé když to lze tak bufferovat celý výstup podle analýzy vstupů (post/get/cookie/db/files). Drtivá většina zobrazení stránek zobrazuje stále totéž, změna nastává jen v případě změny vstupu - parametrů, změně použitých tabulek databáze nebo datových souborů což se z hlediska návštěvnosti děje jen zřídka. Takže většinou se prostě jen načte a zobrazí hotové HTML, u často navštěvovaných stránek se soubor s bufferem vejde do cache takže je to hned.
-
Lukáš Svoboda (neregistrovaný) 62.84.155.---
Eduard Hlava: přesně s Vámi souhlasím, pokud se používá špatně navržená db tak je to hřebík, který je smrtící. Bohužel je to velmi častý jev projektů a to z jednoduchého důvodu,. Zákazník,. pokud zákázník od začátku nepočítá s rozšiřováním základních prvků webů, web app, tak je následné dolepování funkčností často problematické a to samozřejmě pokud se bavím o termínu ASAP.
Jinak myslím, že popsaný techniky opravdu počítají s dobrým databázovým návrhem a proto je to tu vlastně bezpředmětné řešit. -
Eduard Hlava (neregistrovaný) 88.102.142.---
Labir: jojo, bufferováni (u nás tomu říkáme cachování) je základ jakéhokoliv redakčního, publikačního a content management systému. My máme těch úrovní víc (cache modulů, cache pro celou page, cache podmíněná apod.) ... pak se dá udělat to, že se cachuje jen část stránky která se nemění (záhlaví apod.), zbytek se vůbec třeba nekešuje a při zobrazení stránky tak třeba místo 10 dotazů do DB jde jen jeden, ale vše je stále aktuální... Je to pár měsíců zpátky, co jsme na jednom serveru (apahe, php, mysql dohromady) utáhli celkem v pohodě web, který měl skoro 1,2 milionu pageviews za 24 hodin, takže ve špičkách to byl docela frkot.
A samozřejmě při takovémhle provozu už se projeví i pár ušetřených kB v CSS či výsledném html, takže to samozřejmě pak význam má. Spíš v tom smyslu, že se šetří přenosové pásmo.
-
polygon (neregistrovaný) 94.113.154.---
Podle me jsou tohle vsechno zbytecne snahy. O rychlost by se mel starat predevsim http server podporou transportni komprese a cashovani. Pochybuju, ze odstraneni white space nejak vyznamne pomuze gzipu.
Pokud je web i pres to pomaly pak je pomala bud aplikace nebo databaze a v takovem pripade optimalizace nacitani stranek do browseru nijak veci nepomuze.LazyLoad - v principu to zni logicky, ale v praxi bych doporucil se spise zamyslet nad tim, jestli je potreba opravdu nacitat na strance tolik dat a nebylo by lepsi spise provest urcite odlehceni, nez nacitat dodatecne dalsi komponenty. LazyLoad je totiz navrzen pro pouziti v trochu jinych situacich. (Dlouha ws volani, zpracovani dat na serveru se zobrazenim vysledku, ...)
"Drahost pozadavku" - obavam se, ze odezvy pozadavku nelze proste poscitat. Browser totiz po ziskani html kodu stranky neni omezen na stahovani stylu a obrazku po jednom.
-
motyq (neregistrovaný) 77.75.72.---
a co jeste k tomu pridat reverse proxy pripadne i neco cachovat s ttl treba 1minuta? prijde mi zbytecne aby styly serviroval "velky" webserver na kterem jede primo aplikace. Tedy styly + statiku (ikonky kravinky okolo) vydavat primo reverzni proxynou + inteligentni cachovani na zaklade uri a zbytek nechat propadnout na webserver.
Mozna to tak mate, ale v clanku jsem tuto variantu nevidel.
btw - jako reverse/proxy cache v pripade nejakeho takovehoto reseni velice doporucuju nginx :)
