Zrychlujeme web

K čemu to? Budou závody webových stránek?

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

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...

Dlouho jsem se takhle nezasmál, díky Noby

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.

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.

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/coo­kie/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.

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.

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.

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.

@10 tohle je ale za predpokladu toho, ze samozreme http server mate naskalovany na maximum a skvele nastaveny. To same plati pro to, ze vam stiha databaze a vsechno. Samozrejme jestli mate problemy jinde, tak tohle vam nepomuze...

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 :)

jeste jsem zapomel, zapnout pak na te proxyne keepalive a na webserveru ji vypnout :)