Názory k článku Chrome přešel na jádro Blink, Chromebooky budou dostupnější
-
Optimizátor (neregistrovaný)
Zdarec. Možná si ještě někdo vzpomenete na doby kdy se tvůrci webů snažili aby jedna web-stránka (nejlépe i včetně grafiky) nebyla větší než 64 kB.
V té době se pro dosažení používal i "komprimátor" HTML, který prostě a jednoduše odstranil mezery, případně i nepotřebný balast. Takováto stránka byla pro libovolný browser (bez doinstalovaných jakýchkoliv dekomprimátorů do počítače) normálně čitelná, pro člověka vypadala podobně jako text s nevhodně naformátováným ukončením řádků.
V době kdy se podobné věci používaly byly mnohdy zbytečné, protože zpravidla řádně fungovala komprese skrze modemová připojení. Dnes je komprese přenášených dat značně pochybná, mnohdy zcela evidentně není volitelná pro dané připojení do Internetu (podle množství přenášených dat, není aplikována ani skrytě).
Neexistuje podobný nástroj i dnes? Něco co přeskládá HTML kód, tak aby ho dnešní browsery dokázaly přečíst a došlo alespoň k částečnému zmenšení velikosti stránky? Díky za případné odkazy.
-
Glo (neregistrovaný)
minifikace ciste html nema moc smysl. to uz vic pomuze spojovani napr. js , css a jinych resources do jednoho souboru. jinak treba tady by neco bylo https://code.google.com/p/minify/source/browse/?name=master#git%2Fmin%2Flib%2FMinify
ale spis pomuze treba to SPDY, jen kdyby se to rozsirilo
-
Optimizátor (neregistrovaný)
Díky za odkazy na Minify a SPeeDY.
Nemyslím si ale, že SPDY je nějaký zázrak. Myslím, že uživatele ani tak netrápí počet připojení k serveru a priorita stahovaných dat.
Naopak potřebujeme menší dynamiku a čistě "zmenšené zdroje" (nemám na mysli rozkouskovaný sloučený zdroj celé web-stránky), které se ve stabilní podobě uloží do cache browseru tak aby byl opakovatelně použitelný pro více načítaných různých stránek nebo alespoň v budoucích verzích té původní web-stránky. Kdyby se měl pokaždé generovat nový kód celé webstránky tak si vůbec nepomůžeme a jsme tam kde dnes.
Existuje nějaká komprese (alespoň pro JS, CSS, HTML), kterou nativně zvládnou všechny browsery (řekněme od roku 2010) a není třeba doinstalovávat do systému dekompresor?
Ještě jednou díky za osvětu.
-
Filip JirsákStříbrný podporovatelGzip dnes umí snad každý prohlížeč. I kdyby to tak nebylo, není to žádné omezení – prohlížeč s každým požadavkem posílá podporované typy dekomprese, takže server si může vybrat ten nejlepší. Pokud klient nepodporuje nic, server pošle data nezkomprimovaná. Posílat data komprimovaná je podle mne důležitější, a je otázka, zda se pak vůbec ještě něco ušetří minifikací skriptů a stylů.
Počet připojení k serveru uživatele trápí, i když ne přímo. Počet souběžných spojení k jednomu serveru je v prohlížečích limitován v řádu jednotek, takže když se stahují desítky doplňkových souborů, stahují se jeden po druhém – a uživatel musí čekat. Dá se to obejít slučováním do jednoho souboru na straně serveru, ale to má také svém nevýhody – jednak se nedostatek přenosového protokolu řeší na úplně jiné vrstvě (a navíc je to další potenciální zdroj chyb), jednak se často přenášejí pro klienta úplně zbytečná data, jednak to narušuje kešování, protože se změnou v jednom zdrojovém souboru musíte vyměnit celý sloučený soubor.
Navíc prohlížeč si začne o doplňkové soubory říkat až v okamžiku, kdy rozparsuje HTML kód a zjistí, že vůbec nějaké soubory potřebuje. S SPDY na tohle čekat nemusí. Celkově SPDY není primárně určeno ke zmenšení množství přenášených dat (i když zavádí povinnou kompresi), ale k tomu, aby se stránka uživateli zobrazila rychleji.
-
Optimizátor (neregistrovaný)
To s tím počtem souběžných připojení k serveru je pochopitelně pravda, jenže...
Z pohledu uživatele (klienta) tím zřejmě dojde spíše k optimalizaci rychlosti načtení web-stránky. Ideální pro jedinečné načtení jediné web-stránky z celého web-serveru. Při opakovaném načítání datová linka zřejmě šetřena nebude.
Mne konkrétně spíše trápí celkové množství přenášených dat za určité období. Zpravidla při opakované návštěvě webu a načítání vícero web-stránek na jednom web-serveru.
Pokud se ale tohle vyřeší, tak rychlost načítání se optimalizuje sama, již z principu.Navíc je dnešní Web tak přeplácané a vzájemně poprojené místo (mnohdy zbytečně - jen reklamou a kódy které nikdo nechce a nepotřebuje) že zrovna tady by asi SPDY spíše škodil než pomáhal.
Zrovna u mobilních připojení do Internetu, kde je optimalizace důležitá, si myslím že by paralelní načítání (při selhání) způsobovalo neúnosné navýšení přenášených dat. Asi něco jako je Internet od Vodafone - stahujete hodinu jeden megabyte, ale užitečných a použitelných dat nestáhnete ani ten kilobyte, přestože se o to pokouší browser neustále dokola. -
Filip JirsákStříbrný podporovatel
Nerozumím vám. Uživatel přijde na stránku poprvé, s SPDY dostane prohlížeč echo, které soubory si má rovnou stáhnout k hlavní stránce. Stránka se tedy zobrazí rychleji. Při každé další návštěvě už má další soubory v cache, takže je nestahuje znova. Na načítání z cache protokol samozřejmě žádný vliv nemá, ale má vliv na ten první požadavek – a tam SPDY přináší zlepšení (aniž by se něco jiného zhoršilo).
„Paralelní stahování“ s SPDY neznamená, že by se přenášelo víc dat, ale že se stávající spojení lépe využije – místo aby se čekalo, přenášejí se data pro jiný soubor. Pokud se spojení po nějakém čase přeruší, stihlo se za tu dobu přenést víc dat a důležitější soubory – takže je možné, že obnova načítání ani nebude potřeba, protože to důležité se už načetlo.
-
Optimizátor (neregistrovaný)
Po pravdě řečeno to moc nechápu.
To jako ten server připraví pro každého klienta žádajícího danou web-stránku speciální balíček který bude obsahovat jen to co klient potřebuje protože v cache je již obsah neaktuální? Myslel jsem že jde o úpravu všech zdojů do jediného balíku.
Je vůbec možné aby server věděl hned na poprvé co klient bude chtít? Vždyť ani neví jak si daný web bude interpretovat (co si vezme a o co nemá zájem protože - interní pravidla/požadavek uživatele) aniž by mu napřed dodal alespoň hrubou strukturu stránky. A i potom by asi musel čekat nějakou dobu až na něj klient vychrlí postupně všechny požadavky aby je mohl zpracovat do jediného balíku pro přenos.
Paralelní stahování jsem uváděl v souvislosti s chybovostí. I dnes je chybovost docela značná a mnohá data se musí přenášet opakovaně.
-
Filip JirsákStříbrný podporovatel
Ne. Server pošle HTML stránku, kterou chtěl prohlížeč, a k ní seznam souborů (skripty, styly, obrázky), které se na té stránce používají. Prohlížeč se podívá do cache, co z toho má, a o zbytek si řekne serveru. Což by za chvíli udělal stejně – ale právě až za chvíli, kdy stránku rozparsuje. Případně, pokud server o něčem rovnou ví, že to prohlížeč mít v cache nemůže (třeba protože se to neustále mění), pošle to prohlížeči rovnou.
Server ví, co bude klient chtít, protože si to HTML může rozparsovat úplně stejně, jako prohlížeč, a stejně jako prohlížeč si z toho vytáhne odkazy na styly, skripty, obrázky. To, že prohlížeč nebude třeba skripty chtít, protože má zakázané jejich provádění, je tak okrajová záležitost, že nemá smysl to na serveru nějak řešit. SPDY řeší, jak stránku co nejlépe uživateli zobrazit v co nejkratším čase, takže uživatelé, kteří si stránku sami rozbíjejí, nejsou jeho cílová skupina.
Server nemusí čekat, až klient vychrlí požadavky, prostě odesílá to, o co si klient zatím řekl. Naopak klient nemusí s odesláním požadavku čekat, než server doodešle předchozí odpověď.
Chybovost ale multiplexing nijak neovlivní – když se během čekání na data jednoho souboru zatím odešlou data jiného souboru, nemá to přece s chybovostí nic společného. Nanejvýš se data stihnou odeslat dřív, než se spojení rozpadne.
-
Optimalizátor (neregistrovaný)
Díky za osvětu a čas. Už jsem to zřejmě, alespoň přibližně, pochopil (komunikace je totiž obousměrná).
Tohle je asi nejlepší informace o SPeeDY v češtině, kterou jsem našel - http://www.zdrojak.cz/clanky/bude-web-rychlejsi-s-protokolem-spdy/
Tady je celkem slušné zpracování v angličtině - http://dev.chromium.org/spdy/spdy-whitepaper
-
Kolesova plavkyně (neregistrovaný)
JAVA se dneska skoro nepoužívá, já osobně vím jen o dvou webech, kde mají na stránce Javu, naštěstí na žádný z nich nemusím.
Jinak souhlas, JPEG obrázky uložené s kvalitou 100, nejméně desítka přilinkovaných JS, nejméně desítka přilinkovaných CSS, nejméně desítka přilinkovaných písem, počet http požadavků převyšuje stovku. -
Riff (neregistrovaný)
nejméně desítka přilinkovaných JS
Když se to dělá chytře, tak je to jediný požadavek.
nejméně desítka přilinkovaných CSS
Viz předchozí. To už máme celé dva požadavky.
nejméně desítka přilinkovaných písem
Na kolika procentech webů myslíš, že najdeš desítku nebo dokonce víc písem? Běžně to jsou dvě, tři písma.
Pokud kodér nezaspal někde v minulosti, tak často dokáže celé UI napsat jenom pomocí HTML/CSS3, místo aby ho jak tatar rozřezával do dlaždic, takže UI nesežere ani ten jeden požadavek navíc.
Suma sumárum na jednu stranu silně přeháníš, na druhou stranu je pravda, že plno kodérů netuší, která bije, což ale není chyba technologie - úplně stejně by dokázali zprasit i cokoliv dalšího.
-
Širo (neregistrovaný)
Komprimácia a minifikácia HTML má veľký význam. Síce sa jedná o 2 rozdielne veci. Pri minifikácii sa odstraňujú nové riadky a dvojité medzery, taby (s výnimkou PRE a TEXTAREA tagov) a pri komprimácii sa jedná o komprimovanie textového "streamu" pomocou GZIP alebo DEFLATE. To isté platí aj pre CSS a JS. Na web stránkach sa dá všetko zrýchliť aj pomocou CDN (viď google čo je CDN), lenže tu nastáva ďalší problém a to sú sociálne siete, ktoré si ťahajú množstvo iných zdrojov (napr. Facebook like button je killer).
Ja som vytvoril framework, ktorý toto rieši automaticky len na serveri, kde beží - http://www.partialjs.com (stačí pozrieť zdrojový kód vyrenderovanej stránky). Málo webových frameworkov toto v základe ovláda, väčšinou sa to rieši pluginami 3 strán.
PS: minifikáciu HTML stránky doporučuje aj Google PageSpeed.
-
Filip JirsákStříbrný podporovatel
Změřil někdy někdo, jakou úsporu minifikace přináší, pokud se pro transport používá gzip?
-
Širo (neregistrovaný)
Logické hľadisko: čím menej dát tým, rýchlejšie parsovanie.
Ak má HTML stránka, ktorá má 100 riadkov (napr. vo Windowse sú to 2 znaky) \r\n - tak pri 100 riadkoch to bude zbytočných 200 znakov, ktoré sa musia komprimovať, dekomprimovať a samozrejme načítať do pamäti. Nie je to bohvie-aké šetrenie, ale niečo málinko tam je a ak to vynásobíme 1000 requestami, možno ušetríme aj pár kB.
-
Filip JirsákStříbrný podporovatel
Takže jsem se na dotaz, kolik se reálně minifikací ušetří, dozvěděl, že se možná něco málo ušetří. No ale právě na to „možná něco málo“ jsem se ptal…
Takže, naivní experiment, uložil jsem tuto stránku, a velikosti jsou následující:
page.html 76 257 b 100,0 % page.min.html 69 369 b 90,9 % page.html.gz 15 755 b 20,7 % 100,0 % page.min.html.gz 14 851 b 19,5 % 94,2 % page.html.gz (Zopfli) 15 272 b 20,0 % 96,9 % page.min.html.gz (Zopfli) 14 421 b 18,9 % 91,5 % page.htm.lzma 14 068 b 18,4 % 89,3 % page.min.htm.lzma 13 342 b 17,5 % 84,6 %
Takže především má smysl komprimovat, a pak má na výsledek větší vliv způsob komprese, než to, zda HTML soubor je nebo není minifikován. Takže v případě statických souborů, u kterých už bych řešil bajty a jestli komprimovat běžným gzipem nebo Zopfli, má minifikace HTML smysl, v ostatních případech ne.
-
Optimizátor (neregistrovaný)
Chtěl jsem kompresi vyzkoušet na lokálním počítači... Komprese vypadá slibně, nicméně nějak se nezdařilo. Browser takto upravené HTML nezobrazí jak má.
Dejme tomu, že v první fázi chci zprovoznit jen primitivní statický web a nebudu se vůbec zabývat instalací serveru, skryptováním,... Uživatel zná jen IP adresu a port na kterém najde index.html
Používám 7-Zip. Jak bych měl nastavit parametry komprese gzip (Deflate) a jakou příponu souboru aby browser návštěvníka zpracoval takto komprimovaný HTML soubor správně? Nebo mám použít 7-zip (LZMA)? Dále je k dospozici xz (LZMA2) a zip (Deflate, LZMA) i další formáty archívů a komprimačních metod. Děkuji za informaci.
-
Filip JirsákStříbrný podporovatel
Komprese je věc transportního protokolu (HTTP), nikoli souborů. Takže nad lokálními soubory (bez serveru) vám to nebude fungovat.
Nejjednodušší řešení je jen konfigurace webového serveru, kde většinou stačí podporu pro kompresi zapnout (např. u serveru Apache použít modul mod_deflate). Pokud klient pošle hlavičku, že podporuje kompresi, soubor načte normální nezkomprimovaný soubor a během odesílání jej komprimuje. Sofistikovanější varianta je pak taková, že soubory jsou na serveru naopak uložené zkomprimované, a pokud prohlížeč kompresi nepodporuje, server je při odesílání dekomprimuje.
-
Tonda (neregistrovaný)
Každopádně pokud chceš spořit data na mobilu, tak si to řeš spíš ve vlastní režii, přenosová rychlost obecně roste a nějaké optimalizace od provozovatelů webu.
Takže si pomocí stroje někde venku se slušným připojením rozjeď komprimovanou VPN/tunel nebo komprimující proxy jako třeba ziproxy, ta navíc umí i optimalizovat obrázky.
-
VfB (neregistrovaný)
Jeden z nejpoužívanějších nástrojů se jmenuje Minify. Komprimuje jQuery a css-ka. Navíc se stalo téměř nepsaným pravidlem, že když si stáhnete nějaký jQeury plugin, např. nějaký slider, či colorbox, tak kromě normální verze je k dispozici verze minifikovaná. Samotné HTML se již většinou nekomprimuje. Už jen proto, že kód, kdy je celá stránka v jednom řádku se dosti špatně ladí.
ČLÁNKY DO MAILU