Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
A pokud to prohlížeč podporovat nebude (starší verze Chrome, či jakýkoliv jiný prohlížeč) tak se bude dít co? Doufejme, že stránka stále pojede...
Protože jinak by to bylo odsouzeno k zániku hned. Takhle je to dobá věc, co by majitelům a provozovatelům serverů mohla ušetřit bandwith. A to je důležité...!
...jde jen teď o kolik, protože stránka nebývá největší. Největší kapacita je video a pak obrázky na ní... A s tím se toho asi moc udělat nedá, že. Pokusy o komprimaci jpegu nedopadají nejlépe...
Pokusy o komprimaci jpegu jsou už dávno součástí standardu. Progresivní kódování a aritmetická komprese dají slušný výsledek a to bezeztrátově. Akorát že aritmetickou kompresi klienti nějako stále nechtějí podporovat, buď se bojí patentů (už vypršely), nebo se vymlouvají na to, že nechtějí být první (Mozilla team). https://bugzilla.mozilla.org/show_bug.cgi?id=680385
Mechanismus komprese je vyreseny a docela chytry. Prohlizec posila serveru informaci o tom cemu rozumi a server si muze vybrat. Rozsireni kompresnich algoritmu obsahu na webu je diky tomu dost jednoduche. Pouziva se automaticky to, co umi prohlizec a server pro dany obsah povazuje za nejsikovnejsi. Obrazky se skoro nikdy nekomprimuji.
Bude to mozno rychlejsie, ak bude aj podpora na strane web servera. Podporuje ju v tejto chvili niekto?
Zaujimala by ma energeticka narocnost pri kompresii na strane servera. Cital som niekde, ze kompresia pri tomto formate je narocnejsia ako dekompresia.
Sakra, a jak mi podpora nějaké komprese v prohlížeči zrychlý načítání stránek a sníží spotřebu datového limitu? To všichni na českém webu jen přepisují tiskové zprávy? To si musím hledat v anglických zdrojích, že to předpokládá podporu na straně serveru?
Já myslím, že by bylo urážkou inteligence čtenářů jim vysvětlovat, že prvně věc musí podporovat server, kde stánka je hostována a až pak lze řešit podporu v prohlížeči a vyšší rychlost.
Naopak co skutečně chybí je informace o zátěži serveru při komprimaci - zdali bude větší nebo relativně stejná či dokonce menší. Ale je možné, že tohle momentálně nikdo neví... mimo pár vývojářů. Takže to může být jen reklama na Chrome - podívejte, Chrome umí načíst stránku o 26% rychleji! - zatím co reálný přínos je ve hvěždách. A může být třeba jen 5% za cenu 15 či 20% nárustu zátěže CPU na serveru.
vsechny zpusoby komprese vyzadujou podporu od serveru.. to je fakt treba nekomu zduraznovat ze pro uspesny pouziti dekomprese je treba dodavat komprimovana data? ((: zajimavy by spis bylo kdyby to server nemusel umet (:
>zajimavy by spis bylo kdyby to server nemusel umet
Pokud to neni server jen na domaci pouziti, tak treba F5 LTM tohle presne dela. Nejen SSL offloading, ale treba i ruzne WAN akceleracni techniky, pricemz gzip komprese je jednou z nich.
O tom ako Google spravy peknu medialnu masirku o zrychleni nacitania stranok napriec internetom (teda nainfikuje tuto domnienku ludom). Pekna rozpravka.
Aby to vobec fungovalo musi najprv prevadzkovatel serveru na svojej strane tuto kompresiu nasadit, aby mal Chrome vobec co dekomprimovat. Otazne je v ktorych serveroch (apache, iis, javovske servery atd.) to bude dostupne a kedy to prevadzkovatelia realne nasadia do prevadzky.
Dalej, ako tu aj bolo spomenute, daleko vacsiu cast trafficu generuju videa, obrazky a celkovo multimedia ktore sa dost blbo komprimuju zvlast lossless kompresiou. No a dalsiu velku cast trafficu, hlavne co sa tyka textovych dat, robia prelinkovania cez rozne ad, analyticke a sledovacie sluzby.
Tie mozno este viac zpomalia nacitanie stranky a celkovy response , ked pri jednom pageview sa generuje 20-30 requestov krizom krazom, co pri dnesnych weboch je celkom bezne (ze preco potom funguje adblock,ublock a podobne).
Já reklamní, blokovací a sledovací servery řeším souborem hosts v drivers/etc :) Tam lze serveru přiřadit IP adresu, takže každý server, co mi vyhodí nevyžádané okno, je "zabanován" a ještě mi stránky děkují, že neužívám AdBlock :)))
Docela slušně to zrychluje načítání (ale reklamy z stejného serveru jako je hlavní stránka tak blokovat nejdou...). Aktuální verze: http://ax2.old-cans.com/hosts.zip
Ručně nebo nějak automatizovaně?
Ručně. Co si za stránku (přesněji, server) zadáte, že "běží na Vašem PC", to dostanete. Když zadáte, žena vaší IP (127.0.01) beží třeba seznam.cz, tak uvidíte... že neběží :)
Stejně tak (a proklatě rychle) to vrací chybu serveru, jenž se pokusí načíst reklamy z jiného serveru.... To je celé. Ručně to má i výhodu v tom, že blokujete jen to, co chcete. Co nechcete blokovat, to neblokujete... :)
Dělám to s NoScriptem naopak. To co má běžet to si povolím a všechny ostatní scripty ostatní blokuji.
Navíc těch sajrajtových domén je tolik, že explicitně zakazovat není asi nejlepší nápad. Většina jich takhle proklouzne.
"Stejně tak (a proklatě rychle) to vrací chybu serveru, jenž se pokusí načíst reklamy z jiného serveru..."
Hosts mechanismus bohužel tohoto není technicky schopen. Resolver neví (a ani nemůže vědět), že resolvovaná doména bude použita k získání prostředku pro stránku z jiné domény.
Možná se pletu, ale neprovádí stejnou či podobnou blokaci doplněk prohlížeče Ghostery? O každém takovém bloknutí řekne prohlížeč: Failed to load resource: net::ERR_BLOCKED_BY_CLIENT
nginx by si také zasloužil zmínit, možná i před apachem :)
Pokud vím, tak kompresi načítaných stránek obsahuje Opera již pěknou řádku let. Že by se Googlu konečně povedlo vykrást funkci z Opery jako další užitečné funkce?
to bylo neco uplne jineho. opera funguje jako prostrednik - server posle data serveru opera.com, ten je zkomprimuje a posle browseru opera, ktery je rozbali.
google navrhuje tohle: obecny server data zkomprimuje pomoci brotli, tvuj browser je rozbali.
To co popisujete je nesmysl. Už vidím jak všechny servery komprimují obsahy svých stránek jenom proto, že to po nich chce nějaký Americký trotl. On totiž důvod, proč to Google chce pochopí i méně inteligentní lidé. Je to proto, aby zpravodajské služby mohli rychleji kontrolovat obsahy stránek různých webů. Pokud myslíte, že je to pro uživatele, tak na to zapomeňte. Ti to dostanou jakoby mimoděk i když se to na ně svádí.
tím způsobem co popisuje John Douberro to funguje už mraky let, stačí se podívat do html hlaviček, běžně tam najdete např. gzip, či čisté Deflate, Google jen vyvinul lepší on-the-fly kompresní algorytmus a už bylo na čase :)
Až na to, že Opera to žene přes vlastní servery ;)
Asi sem blbý, ale jak to bude dělat Google? To všechny weby budou mít speciální verzi jen pro něj? Nebo se zkomprimuje po ceste jen tak samo?
Vicemene ano. Predpoklada se, ze se pro kazdy web server napise modul pro kompreseni do Brotli a vsechny weby to nainstaluji. Jinak bude zrychlene jen brouzdani po www.google.com ...
...a i ten Google se zrychlí jen těm s novým Chrome/Firefoxem a je dobrou otázkou o kolik...
Serverové aplikace mají výstupní filtry, které se dají zapnout. Takže se to víceméně "zkomprimuje jen tak samo" (resp. člověk to povětšinou nemusí řešit, maximálně pro to určí nějaká obecná pravidla v konfiguraci serveru).
Bylo by mozna dobre vysvetlit k cemu je Brotli vlastne dobre a proc je to opravdu dobry algoritmus pro pouziti jako komprese HTTP komunikace.
- je to algoritmus bez otravnych patentu, ktere ma LZMA a castecne deflate
- ma extremne rychlou a nenarocnou dekompresi srovnatelnou s deflate/gzip
- ma extremne variabilni nastaveni komprese - pri urovni 1 je o dost rychlejsi nez deflate a produkuje o trochu lepsi vysledky, pri urovni 11 je extremne pomaly a narocny a za odmenu produkuje vysledky srovnatelne LZMA(7-zip) nebo bzip2
Vysledkem je, ze pro runtime kompresi dynamicke obsahu je brotli o malinko vyhodnejsi nebo srovnatelny algoritmus jako deflate, ale pokud si pro staticky obsah predem predpocitate komprimovanou variantu, tak muzete usetrit docela podstate mnozstvi prenesenych dat.
Pointa Brotli je prave v tom, ze staticky obsah zkomprimujete dopredu jen jednou a vsechny ty spousty javascrptu, css a statickeho obsahu tak dostanete do prohlizece levneji a rychleji.
Díky za informace.
Uvažoval jsem o tom, proč by google měl chtít někomu šetřit trafic, a ono jde ve skutečnosti zase jen hlavně o patenty.
K tomu příjemný bonus za moderní algoritmus. Google je dost veliký na to aby to časem prosadil.
LZMA je zatíženo patenty? Tak to slyším prvně. No a pokud jde o šetření dat, u statických dat to řeší HTML5 Application Cache, takže zrovna rychlá a dostatečně efektivní komprese dynamických dat se mi jeví jako potřebnější než maximálně efektivní komprese statických dat (tedy aspoň pokud jde o zlepšení stávajících technik komprese, samozřejmě předpokládám, že nějakou základní již člověk používá).
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.