aargh právě jsem klikl na escape, takže to celé musím psát znovu :-<<<
neviděl bych to tak černě, nositelem informace není jen text, ale i související obraz, tedy je-li článek o povodních, tak by byl hodně špatný, kdyby se tam nedal srdceryvný obraz topícího se člověka, tučňáka, slona ...
Tento obrázek je přitom řádově větší než samotný text, na každý truecolor pixel potřebujete bez komprimace tuším třetinu normostrany. A přesto je to potřebná, až bezpodmíněčně nutná součást magazínu, jinak by se na to nikdo nekoukal.
Na druhou stranu jsou i textové reklamy, které tak nejsou započítány.
Myslím tedy, že celá metodika je špatná, respektive výstup z tohoto "výzkumu" je naprosto nesmyslný. Měl by se počítat tzv. vyžádaný versus nevyžádaný obsah, tedy na jednu stranu dávat text článků a k němu obázky, na druhou stranu reklamy textové i grafické a (nejlépe na třetí) režii - tagy, hlavičky. Tipuji, že by ten poměr pak byl řekněme 20-30:80
Mimochodem nová podoba živě má devět grafických a devět textových reklam (nepočítám li stálé odkazy na ostatní servery)
A myslím, že tento jev není počítán při kalkulacích placeného obsahu. Pásmo něco stojí, když by měl pro tyto zákazníky pětkrát klesnout objem přenášených dat, plus kdyby tam byly textové reklamy přesně cílené podle údajů udaných při registraci, tak by se (možná, nevím), cena dostala níže
Souhlasím s tím, že metodika nedovoluje vydat naprosto přesné údaje, ale zvolil jsem ji takovým způsobem, aby získané informace byly dost užitečné a přitom aby to Marka Antoše nepřišlo na zbytečně moc peněz. Odlišovat textovou reklamu, odlišovat konstrukční a ilustrační grafiku, to chce poněkud více času.
Mně šlo stejně jako loni jen o obecný pohled, pokud se potom provozovatel nějakého serveru chytne za nos, může si přesnější analýzu udělat pro svůj web sám, a jistě se mu vyplatí ten čas do ní investovat.
Mimochodem, konstrukční, ilustrační grafika, skripty a iframes dohromady v průměru zabírají 35 % objemu, což je o něco více než 57 KB. Na Lupě na stejný typ dat připadne jen kolem 5 %, na BonusWebu 29 %, na iDnes 39 %.
Kromě toho metodika dovoluje jen statický pohled na vybraný vzorek, mnophem zajímavější by bylo sledovat přenesená data u vzorku uživatelů, kde by se zobhlednil například fakt, že během povodní lidé co půlhodinu refreshují iDnes, kdežto o Lupu zavadí jen dvakrát denně...
> Tento obrázek je přitom řádově větší než samotný text, na
> každý truecolor pixel potřebujete bez komprimace tuším
> třetinu normostrany.
Třetinu normostrany? Normostrana je 1800 znaků, ne? Takže na jeden pixel se spotřebuje 600 bajtů? (Nebo víc, protože znak je kódován *nejméně* jedním bajtem.) To byste musel mít bitovou hloubku 4800bpp :o)
Navíc úvaha o nekomprimovaném RGB obrázku je pitomost. Obrázky jsou buď typu fotky, a pak jsou to vysoce komprimované JPEGy, nebo dekorace, a pak jsou to vysoce komprimované PNG/GIFy, obvykle s indexovanými barvami.
Naopak se nikdo nepozastavil nad tím, že samotný text stránky (myslím celé HTML, nejen text) bývá při přenosu komprimováno gzipem, stejně tak CSS -- zatímco obrázky už se víc zkomprimovat nedají (nevím, jak je to u Flashe), takže měření rozbalených dat po přenesení má značnou systematickou chybu. Je potřeba měřit datový tok přímo na síti.
Podle mne je v tagu <h1> obsaženo celkem dost informace -- ,,tohle je hlavní nadpis``, a to zejména vzhledem k jeho délce.
Strukturální informace je velmi důležitá, po jejím odstranění dostáváme to, co ten skript vypíše jako obsah stránky -- uznejte, že tohle by přece nikdo nechtěl číst. V žádném případě tedy neměří množství užitečné informace.
Žádný skirpt neumí (s dostatečnou přesností) poznat, které značkování obsahuje důležitou strukturální informaci, a které jen okrasný šum.
Na stránce, která neobsauje absolutně žádnou presentaci, pouze párřádkový stylesheet a strukturální značkování textu, mi ten skript ukazuje obsah textu 60%. U velmi jednoduše formátovaných stránek (jen nadpisy a odstavce, seznamy pouze s dlouhými položkami, málo vyznačování v textu, žádné tabulky) by šlo asi dosáhnout většího poměru, např. http://www.gnu.org/licenses/gpl-faq.html obsahuje podle skriptu 80% textu, ale to už je extrém a u normálních stránek se nedá víc než zhruba 60% očekávat.
V podstate s vami souhlasim, az na posledni vetu. Nebudu se zde ohanet cisly (protoze nevim, ze ktereho prstu bych si je vycucnul :-), ale 60% mi i u bezneho webu prijde pomerne dost malo. Myslim, ze ten pomer by mohl byt ponekud vetsi...
BTW GNU.org je pomerne dobre navrzene (i kdyz ty tabulky by tam byt nemusely)...
HTML značkování je dost ukecané. Už korektní hlavička je dost dlouhá. Není mi proto jasné, jak chcete rozumně dosáhnout znatelně víc než těch 60%. Jedné dvě možnosti jsou dlouhé bloky hladkého (resp. pre) textu a absence globální navigace -- kterou prakticky nelze udělat bez nějakých tabulek, seznamů, ... obsahujích relativně větší množství značkování. Pokud ovšem nechcete skončt nějak takhle: http://www.faqs.org/rfcs/rfc2068.html (91,2% textu). (Nic proti, mně nevadí takové věci číst, ale má tak vypadat zpravodajský server?)
GNU.org je navržené poměrně dobře, ale extrémně střizlivě, a navigace je tam podle mne mizerná. Pro mne jsou globální navigační prvky (nějaké ty lištičky či tabulky na straně) pohodlím, za které jsem ochoten platit delší stránkou, a to zejména u serverů poskytujících větší množství stále se měnícího (přibývajícího) obsahu.
> Nic proti, mně nevadí takové věci číst, ale má tak vypadat zpravodajský server?
Presne tak. Komercni site takhle vypadat nemuze. Ale nebavme se o 60++%, podivejte se na Holovatyho stranku, i *velmi* kvalitne navrzeny weblogy maji cca 40%, coz je logicky. V Martinove i Holovatyho statistice je ten pomer treba 6 - 8%! =) To je zcela komicky! Pripominam ze to je ***bez*** obrazku!
Navrhnout to na více než 60% není při troše logice vůbec prblém. Mrkněte se na http://www.volny.cz/martin.konicek/proxomitron/ . Obsah textu na stránce je asi 62,5%, je tam navigace, formátování textu a podle několika názorů je to i přehledné :-D
nechápu, proč všichni dělají tak neefektivní stránky? V době CSS není problém udělat stránku maximálně efektivní, stačí jedny kaskádové styly, potom napsat co je třeba a hip-hip hurá na to :-)))
BTW jak jste přišli na to, že komerční stránky musí být přeplněné animacemi, videi apod? Každý vám určitě poví, že spíše ocení přehlednou stránku než nějakou patlanici. mrkněte se na stránky našich bank, načítají se na modemu i minutu jedna stránka, nevím jestli by někdo raději nepřehlídnul tu super animaci a neměl to načtené za 5 sekund?
Napsal jsem ,,znatelně víc, než 60%`` a za tím si stojím a 62,5% nepovažuji za znatelně víc. A to tam nemáte žádnou globální navigaci. http://trific.ath.cx/software/enca/ má 61,7% včetně globální navigace po site (a v MSIE vypadá i po několika úpravách CSS ponkěkud rozhozeně, protože design stojí výhradně na CSS a podpora CSS je v MSIE absolutně mizerná).
Nemá cenu diskutovat rozdíly řádu jednoho či dvou procent, kterých lze dosáhnout např. kratšími názvy CSS stylů a používáním <i> a <b> místo <em> a <strong>, ... Jiná věc by byla, kdybyste měl třeba 72,5% textu.
dva obrazky maji 71KB, kdy jeden z nich z puvodnich 32kb jde ztahnout na 10 bez vizualni ztraty (80% JPG).
71KB (nepocitam do toho cudliky).
Ztazena stranka ma 12kb a ciste text v ni bez tagu 6kb. At pocitam jak pocitam, 60% se nedopocitam.
Priste radsi mlc, nebo si budu myslet ze jses jen jeden z rady tech, co auditoria vyuzivaji pro zvysovani navstevnosti vlastnich nesmyslu a lhar v jednom. Apropo, stranky teda moc prehledny nejsou.
ČLÁNKY DO MAILU