AbcMonitor a NetMonitor (diskuse)

[=^..^= AmigaPower®]

Nevšiml jsem si na žádném českém webu, že by je netmonitor, respektive gemius.pl zpomaloval. Proč jenom nás?

Gemius.pl zpomaluje skoro všechno kde se nachází, vypozoroval jsem to na více stránkách, věř mi, že ábíčko je na tom s rychlostí ještě dobře...

Děje se to za záhadných okolností a bez žádné logiky, nezáleží to na čase. Já bych to laicky svedl na přetížení jejich serverů...

[=^..^= AmigaPower®]

PS: český weby (kromě ábíčka) moc nesleduju, šlo mi o zkušenosti z těch polských (kočičích).

[letec]

Jak se pozná, jestli jakýsi ten gemius.pl zpomaluje načítání nebo nikoliv ? S žádným gemius.pl jsem se nikdy nesetkal.

Co se týče zpomaleného načítání, tak to prý někdy dělá jakýsi google - analytics nebo něco takového.

[Luk]

Co se týče zpomaleného načítání, tak to prý někdy dělá jakýsi google - analytics nebo něco takového.

Nezažil jsem, aby to brzdil kód Google Analytics. Mám ho na několika webech a nikdy jsem nenarazil na jev, na který narážím tady na abíčku. Ostatně, nebylo by od věci nechat puštěný Wireshark a po tom zaseknutí se podívat, jak probíhala komunikace.

[brk]

Koukal jsem do Adblocku a na abíčku blokiji pouze právě Google Analytics, takže já s tím v minulosti určitě nějaké problémy měl. Zkusím to vyhodit, ať nekur... statistiky.

No a pak taky flash, ale ten blokuji Flashblockem plošně. Tuhle technologii nemám rád. Nechám si ve Firefoxu otevřených několik desítek panelů a procesor na 100% kvůli těmhle nesmyslům.

[=^..^= AmigaPower®]

Jak se pozná, jestli jakýsi ten gemius.pl zpomaluje načítání nebo nikoliv ?

...že ti dole na stavový liště 2 minuty svítí "čekám na hit.gemius.pl"

[multi]

toho googlu jsem si take vsiml hl na slabsim stroji

[alium]

můžu potvrdit, že spousta českých stránek, na které chodím s tím má problémy..

[dad]

jestli jsem to dobre pochopil, tak kdyz budu neco blokovat, tak tim mohu uskodit abclinuxu. Nemohl by tedy nekdo poradit, jak se da to blokovani nastavit?

[abr]

Co mas za prohlizec?

[YYY]

Pokud to neni ironie, tak nechapu vasi snahu skodit.

[jirkaqwe]

Asi měl spíš na mysli jak konkrétně nastavit prohlížeč např Firefox s Adblock plus a NoScript aby nekazil abíčku statistiky navštěvnosti a abíčko nepřicházelo o peníze.

[Leoš Literák]

Inzerenti nejsou hloupi, takze jakakoliv hratka s blokovanim / nezobrazovanim reklam ci mericich kodu ma dopad. Napriklad kdyz budete stahovat reklamy, ale nezobrazovat je (coz pry adblock umi), tak budete kazit statistiky uspesnosti reklam a inzerent ztrati zajem priste k nam nejakou reklamu zadat. Pro nas je tedy nejlepsi, kdyz takove tooly vubec pouzivat nebudete

[David Ježek]

mě nezbývá než s drzostí době vlastní připomenout toto.

[Martin Mareš]

Jaký je rozdíl mezi tím, když nechám AdBlock reklamu stáhnout a nezobrazit, a když se zobrazí, a já na ni stejně nekliknu? Reklamy na Abíčku blokované nemám, ale snad už ani nepamatuji, že by mne nějaká zaujala a klikl jsem na ni.

[petr_p]

To se řešilo minule.

[trekker.dk]

Akorát to zde nemá souvislost - když se obrázek stáhne, tak už nikdo nepozná, jestli ho prohlížeč zobrazuje nebo ne.

[petr_p]

Není pravda.

Za prvé v dnešním javascriptovém marastu se obrázky natahují přes klientský skript, který zrovna tak může (více méně) kontrolovat, zda obrázek a jeho nadřízené elementy nejsou skryté.

Za druhé rozumný zadavatel „měří“ účinnost reklamní kampaně vzhledem k nově získaným tržbám, aby věděl, jestli nevyhazuje peníze oknem (webového prohlížeče).

Netvrdím, že se tak skutečně ve významnějším množství děje, ale ta možnost tu je.

[Filip Jirsák]

To je stejné, jako když se díváte v televizi na reklamu a výrobek si pak nekoupíte. Když se reklama zobrazí, poskytlo médium inzerentovi svůj prostor a inzerent zaplatí. To, že vás reklama nezaujala a vy jste na ni nekliknul, to už ať si inzerent vyřídí s tím, u koho si reklamu nechal vyrobit.

[Filip Jirsák]

Aha, neumím číst. Mi to bylo divné, že by se Martin Mareš ptal na takovouhle prkotinu… I v tom stáhnu/nezobrazí a stáhnu/zobrazí/nekliknu je pro inzerenta samozřejmě rozdíl, jenom se to hůř měří. Ale pokud si třeba bude významná část lidí z Abíčka reklamy stahovat ale nezobrazovat, inzerentům ve statistikách vyjde, že Abíčko má nižší konverzní poměr – méně lidí, kteří reklamu vidí, na ni klikne. To může být způsobeno buď právě stahováním a nezobrazováním reklam, nebo i tím, že čtenáři Abíčka prostě míň klikají na reklamy. Z pohledu inzerenta je to ale jedno a to samé, a samozřejmě bude požadovat nižší cenu za zobrazení, protože inzerenta samozřejmě zajímá cena za proklik (resp. ještě lépe cena za provedení obchodu). Pokud víte, že nikdy na žádnou reklamu nekliknete, je to jedno, jestli si jí necháte zobrazit nebo ne. Pokud připustíte, že by se mohla vyskytnout i taková reklama, která vás zaujme, pak už to jedno není.

[trekker.dk]

Pokud připustíte, že by se mohla vyskytnout i taková reklama, která vás zaujme, pak už to jedno není.

V tom případě nechávám zobrazování obrázků stahovaných z adarbo a spol. zablokované, ještě jsem nenarazil na reklamu, která by mě zaujala něčím jiným, než že mě rozčiluje to blikání.

[Filip Jirsák]

Já jsem samozřejmě psal o rozdílu stáhnout/nezobrazit a zobrazit/nekliknout. Počet stažení reklamy se nejsnáze měří a interpretuje, takže to budou první čísla, na která se každý inzerent podívá. Takže blokováním stahování reklamy poškodíte web nejvíce.

Podle mne je blokování reklamy stejné, jako třeba jízda v MHD načerno. Sice se jeden další neplatící cestující nebo blokující čtenář v systému prakticky nepozná, náklady na něj jsou takřka nulové, ale když se takhle bude chovat čím dál víc lidí, ten systém se postupně zhroutí, protože ti platící nebudou schopni ufinancovat čím dál početnější skupinu neplatících. Pokud někomu nějaká reklama vadí, může o tom diskutovat s vydavatelem, s inzerentem, může o tom napsat do blogu, nebo může na server přestat chodit – ale pokoutně blokovat reklamu, ale zároveň dál konzumovat obsah, to mi nepřipadá fér.

[M. Lox]

To je, obávám se, stejný problém jako se sdílením filmů a hudby: Nikde nic nechybí, dělá to každý a stejně je reklama nemorální, tak proč bychom ji neblokovali. Já souhlasím s vámi, ale dost lidí si myslí opak.

[trekker.dk]

Já jsem samozřejmě psal o rozdílu stáhnout/nezobrazit a zobrazit/nekliknout.

Jak se to vylučuje s "V tom případě nechávám zobrazování obrázků stahovaných z adarbo a spol. zablokované"? (Teda až na ten detail, že, jak jsem zjistil, se ani nestahují)

Podle mne je blokování reklamy stejné, jako třeba jízda v MHD načerno.

To v žádném případě není. U MHD je smlouva mezi cestujícím a provozovatelem, cestující je podle ní povinen za přepravu zaplatit.

Na druhou stranu web pouze nabízí nějaký obsah a jeho stažení je dobrovolné. A vzhledem k principu tohoto stahování je dobrovolné i to, které části webu si stáhnu.

pokoutně blokovat reklamu, ale zároveň dál konzumovat obsah, to mi nepřipadá fér.

To už je něco jiného.

[Filip Jirsák]

Nikdy to nemůžete zablokovat dokonale. Třeba si Abíčko nechá udělat průzkum, vy se přiznáte, že Abíčko čtete, a zase budete ve statistikách započítán. Jediná možnost je, že byste Abíčko blokoval úplně a přestal na něj úplně chodit. Ve všech ostatních případech přijde jen o měřeného čtenáře, ne o skutečného...

[abr]

Gemius mi pije krev uz hodne dlouho. Jejich admini by s tou pomalosti mohli neco delat.

[Luk]

Dělá to pořád (na Centrum nechodím, na Lupu jen občas). Nejhorší je to u diskusí - dokud se to nenačte, nejde (aspoň u Opery) skočit na první nový diskusní příspěvek. Proto pak musím mačkat STOP, aby skoky fungovaly.

[Prcek]

Já zase musím mačkat RELOAD . U nás ve škole se objevila Fedora 10 a KDE4, tak jsem si k tomu sednul, že konečně vyzkouším nový KDE. Když chci zobrazit nějakou stránku z abclinuxu.cz, tak to strašně dlouho loaduje a stránka se nechce načíst - jakmile dám ale reload, tak se načte. Problém je, že při reloadu přijdu o nepřečtené příspěvky, no a taky je to dost otravné pořád klikat na reload .

[Luk]

Problém je, že při reloadu přijdu o nepřečtené příspěvky, no a taky je to dost otravné pořád klikat na reload

Nepřečtené příspěvky občas zmizí i bez reloadu. Uvažuji to ohlásit jako bug, ale nevím o žádných konkrétních okolnostech, za kterých se to vyskytuje.

[Leoš Literák]

Nemuze to byt omezenim poctu navstivenych diskusi,? Tusim je to neco kolem 60-80. Ty nejstarsi proste odpadnou pryc a tudiz system nevi, ze jste je navstivili a nema podle ceho urcit, zda hvezdicku zobrazit ci ne.

[Luk]

Může být. Tyhle souvislosti jsem nikdy nezkoumal.

[Michal Vyskočil]

Když chci zobrazit nějakou stránku z abclinuxu.cz, tak to strašně dlouho loaduje a stránka se nechce načíst - jakmile dám ale reload, tak se načte.

To je bug#180631 - bylo to opravené až po vydání 4.2. Bohužel se mi tato regrese objevila těsně před vydáním 4.2, takže to bylo nahlášené relativně pozdě a opravené až po vydání. Zkus kontaktovat maintainery KDE ve Fedoře, ať aplikují r926999.

[Jiří Benc]

Konkrétně gemius.pl mi přesně tohle dělal na několika zcela různých webech. Většinou byl rozumně rychlý, ale náhodně přicházely chvíle, kdy zablokoval načítání stránky i na několik desítek vteřin. Z mého pohledu tedy pánové z netmonitoru pěkně kecají. Dál už jsem závislosti nezkoumal, skončil v adblocku. Omlouvám se za to, že kazím abíčku statistiky, ale nervy mám jen jedny.

Vzal jsem ho dočasně na minulost, pokud se nepolepšil, poputuje zpátky.

[neaktivni]

+1

[slush]

AbcLinuxu je jediny web, kde mam podmíněně vypnutý AdBlock. Sice mě ty všechny gemiusy otravují a nejraději bych je zakázal, ale AbcLinuxu je plné geeků, kteří pravděpodobně bez AdBlocku nedají ani ránu, takže každý zaevidovaný hit se počítá.

Na webech typu idnes a aktuálně na výjimky kašlu, tam je dost BFU, co o AdBlocku nemají páru .

[letec]

Co to je AdBlock ?

[Zdenek]

Ani nemusi byt AdBlock. Gemius script je totiz v javascriptu, takze staci NoScript a ma po zizalkach a jako bonus nemate ani ten silenej editor

[Vojtěch Trefný]

Taky to tak mám -- tvrdě blokuju, ale pár vybraných webů mám na whitelistu (abíčko taky). Jediné, co tady "blokuju" je flash (nemám flashplugin).

[bazil]

když už jsme tu u blokování, jak je to s flashblockem? ten flash natáhne, ale nepřehraje, ne?

[slush]

Ne, flash se ani nestahuje. Ale z pohledu reklamnich kampani to neni dulezite, protoze samotne pocitadlo, jestli se reklama zobrazila nebo ne byva zpravidla v samostatnem JavaScriptu u reklamy a ten se provede i s FlashBlockem.

[snajpa]

To je dobře, protože zbavit flashblocku (pro jakoukoliv stránku) mě nikdo nedonutí. Jiné reklamy neblokuju (teda v prohlížeči, to že si jich nevšímám, je věc druhá).

[bazil]

taky mě to potěšilo, nerad bych vypínal flashblock, i když pro abíčko bych to asi udělal ...

[Leoš Literák]

Jeste bych k abcmonitoru dodal, ze nejaktivnejsi uzivatel ma 8552 monitoru, druhy 3121, treti 2002, ctvrty 1692 a paty 994.

[Käyttäjä 11133]

Je v top 5 Heron?

[Heron]

Předpokládám (vzhledem k tomu, jak jsou ta čísla malá), že jsem na prvním místě. Funkci sledovat považuji za vysoce užitečnou a používám ji na každý objekt (článek, blog, atd) který mě zaujme. Denně aktivuji určitě přes 10 sledování. Prostě se mi nové komentáře mnohem lépe čtou v emailovém klientu než kdybych měl refreshovat stránku v prohlížeči.

[Jendа]

Prostě se mi nové komentáře mnohem lépe čtou v emailovém klientu než kdybych měl refreshovat stránku v prohlížeči.

Tak to každý používáme ABCMonitor jinak . Já si sledované objekty, co mi přijdou mailem, otvírám v prohlížeči (hlavně proto, abych viděl celé vlákno).

[Leoš Literák]

Jo, vyhrals

[filbar]

Teď jsem narazil na jiný bug. Pokud zadám do prohlížeče adresu https://abclinuxu.cz, tak na mě vyskočí hláška o neplatném certifikátu. Pouze pokud pouziju https://www.abclinuxu.cz, tak to najede normálně.

[Luk]

To je dáno vlastností certifikátu. Není to wildcard certifikát (který je výrazně dražší než "obyčejný" certifikát), proto je jen na jednu doménu, a to www.abclinuxu.cz. Je proto v pořádku, že to řve. Bug je ovšem jednoznačně to, že to z abclinuxu.cz nepřesměrovává na www.abclinuxu.cz.

[Leoš Literák]

Ale presmerovava, zkousel jsem http i https (ktere ale presmeruje na http://www.abclinuxu.cz)

[Luk]

Tak beru zpět (viz níže). Ovšem mělo by to přesměrovávat na https://www.abclinuxu.cz.

[Leoš Literák]

Svet neni dokonaly, smirte se s tim Pro mne je existence https velky ustupek, ladit takoveto drobnosti se mi opravdu nechce Kdo zna rozdil mezi https a http, ten bude schopen to s tam doplnit rucne. Navic stejne to URL na 97% zadaval rucne nebo z bookmarku, protoze vsude uz mnoho let presmerovavame na www.

[Filip Jirsák]

I kdyby to přesměrovávalo, nejprve se ověřuje certifikát a teprve pak se provede přesměrování. I přesměrování musí být bezpečné. Takže tu hlášku by to neodstranilo.

[Luk]

Pravda, už ten první požadavek se posílá přes SSL. Proto to zařve tak jako tak.

[Radovan Garabík]

To nie je bug, ale normálna očakávaná reakcia.

[Kroko]

Mě to na Kubuntu 8.04 a FF 3.x žádné problémy nedělá a abclinuxu se načítá pokaždé v pořádku.

[jirkaqwe]

Nešlo by udelat nějaké upozornění, že prohlížeč blokuje statistiku navštěvnosti, třeba malá červená ikonka. Po kliknutí na upozornění by se objevila nápověda jak se má případně prohlížeč nastavit, aby to neblokovalo. Třeba to tu řada lidí blokuje a ani o tom neví.

[User682]

zdravim Leosi,

uvadis v blogu, ze je pro Vas kriticke mit zisky z reklamy a ze je velmi spatne, kdyz navstevnici blokuji reklamy.

Tak ci tak si myslim, ze tech par procent lidi, co blokuji reklamy neni dulezitych a nestoji to za to resit. To je podle me zbytecne vysilovani.

Pochybuji, ze lide budou zodpovedni a ze jim pomuze domluva.

Porovnam -li ceny ve Vasem media-kitu, tak jste v plusu i s naklady (nechci resit).

Nebo se mylim ? A pokud ano, tak v cem ?

[filbar]

Proč se přestala zobrazovat ta ikonka ve výpisu u sledovaných diskusí? Byla to docela super věc jak si zvýraznit sledovanou diskusi.

[Dan Ohnesorg]

Abicko neni urcite jedine, kdo ma problem s obcasnym nedodanim obsahu ze strany gemihnusu. Nicmene abicko to taha fakt hodne na zacatku, takze skutecne zustane cele viset, takle vypada abicko:

http://www.ohnesorg.cz/foto/screenshot10.png

A takle vypada lupa, kde uz je zobrazen text, zatimco se ceka az na strane gemiusu po uspesnem connectu prideli nejaky worker, ktery ho odbavi.

http://www.ohnesorg.cz/foto/screenshot9.png

[filbar]

Co to je za soft v těch screenech?

[Dan Ohnesorg]

Jmenuje se to YSlow, plugin do firefoxu 3, vyvijeji to v yahoo pro ladeni vykonu jejich web serveru. Poskyuje to furu informaci, od tehle grafu pomalosti/rychlosti, pres pocty objektu, informace o tom jak se cachuji.... proste takovy profiler.

[Luk]

Hmmm, zkoušel jsem to, a pro chvilkové marné bitvě a chvilkovém googlení jsem zjistil, že to není funkce YSlow, nýbrž samotného Firebugu (na kterém je YSlow postaven). Takže jsem to hledal jinde, než to bylo.

[Dan Ohnesorg]

A tady je abicko, kdyz se zamysli:

 

www.ohnesorg.cz/foto/screenshot11.png

[trekker.dk]

Jako zrovna teď - a nejenom ábíčko, ale všechny stránky, které stahují něco z adarbo2.bbmedia.cz.

Za poslední dva dny je to podruhý, takže adarbo jde do blacklistu na firewallu.

[Robert Krátký]

Příloha:

• gemius.png (46108 bytů)

Taky přikládám jeden čerstvý a velmi frustrující screenshot. Čekal jsem na gemius 8(!) minut. Ostatní weby (i gemiusové) fungovaly dobře.

[Luboš Doležel (Doli)]

Poslal jsem stížnost do Arba. Sice to chvíli potom začalo fungovat, ale není možné, aby kvůli jejich mizerným systémům nám nejel web...

[Luboš Doležel (Doli)]

A dodal bych, že Firefox lže. Pokud tvrdí, že čeká na Gemius, mám ověřené, že ve skutečnosti čeká na něco jiného - tady to vážně bylo Arbo.

[trekker.dk]

iptables -A FORWARD -p tcp -s 192.168.253.3 -d 62.168.44.124 -j REJECT --reject-with tcp-reset
iptables -A FORWARD -p tcp -s 192.168.253.3 -d 62.168.44.125 -j REJECT --reject-with tcp-reset

A je uklizeno.

[Filip Jirsák]

A je uklizeno.

Neřekl bych. Spíš jste zametl smetí pod postel.

[trekker.dk]

Moje smetí to není, tudíž jsem ho nemohl zamést.

Když už jsme se vrhli na přirovnání, tak bych spíš řekl, že jsem řekl vrátnému, aby smetí nepouštěl přes vrátnici.

[Filip Jirsák]

Právě že jste nikomu nic neřekl. Jako programátor i správce sítě miluju uživatele, kteří když narazí na problém, místo aby ho oznámili autorovi aplikace (nebo administrátorovi), dělají svoje partyzánské úpravy a brblaj všude možně, jenom ne tam, kde by měli. Jak se asi má provozovatel toho reklamního kódu dozvědět, že je něco špatně, když mu nic neřeknete a jenom ustřihnete komunikaci? To myslíte, že jim to nahlásí a pomůže odhalit problém někdo, kdo o počítačích vůbec nic neví?

[trekker.dk]

Právě že jste nikomu nic neřekl.

Ale? Tak to abych si ten skript pro nastavování firewallu překontroloval. Hm, zajímavé, vždycky jsem si myslel, že když příkaz iptables selže, tak taky vypíše proč.

Jak se asi má provozovatel toho reklamního kódu dozvědět, že je něco špatně, když mu nic neřeknete a jenom ustřihnete komunikaci?

To je jeho problém. Jestliže kvůli načítání reklam musím pět minut čekat na zobrazení celé stránky, tak neváhám ani chvíli a volím nejjednodušší a nejrychlejší řešení. Nebýt to reklamy ale něco užitečného, tak bych možná investoval ten čas a hlásil chybu, ale takhle fakt ne.

[Leoš Literák]

Kdyz se takhle zachovaji vsichni, budou nam klesat prijmy z reklamy a my nebudeme tusit proc. Minimalne upozornit provozovatele na problem by bylo solidarni a ve svem dusledku prinosne i pro tebe. Jak bychom asi zareagovali, kdyz bychom nemeli penize na honorare? (upozornuji, ze jde o hypoteticky priklad) A podobne kdyz najdes chybu treba ve firefoxu, z dlouhodobeho hlediska je lepsi ji nahlasit nez nadavat v hospode

[trekker.dk]

Kdyz se takhle zachovaji vsichni, budou nam klesat prijmy z reklamy a my nebudeme tusit proc.

Ale jo. Ve chvíli, když by všichni zablokovali brzdící adarbo, tak by jim asi došlo, že někde udělali chybu. Nebo možná ne, ale je to jedno, protože by tak jako tak šli od válu - kdo by objednával reklamu od někoho, komu se reklama nezobrazuje - a na jejich místo by nastoupila jiná firma. A ti by se třeba poučili a zajistili bezproblémový chod této "služby"

A nebo taky ne, v takovém případě GOTO 10

A podobne kdyz najdes chybu treba ve firefoxu, z dlouhodobeho hlediska je lepsi ji nahlasit nez nadavat v hospode

Což jsem, alespoň podle mého názoru, vyjádřil větou "Nebýt to reklamy ale něco užitečného, tak bych možná investoval ten čas a hlásil chybu"

[Robert Krátký]

Což jsem, alespoň podle mého názoru, vyjádřil větou "Nebýt to reklamy ale něco užitečného, tak bych možná investoval ten čas a hlásil chybu"

Potíž je v tom, že pro AbcLinuxu.cz jsou reklamy užitečné - jakkoliv se nám nelíbí - protože to je jediný zdroj příjmů.

[petr_p]

Čekání na skript je vlastnost HTML+JS nebo chyba prohlížeče? Přijde mi úchylné, že prohlížeč, který se snaží o paralelní progresivní zpracování, nedokáže stahovat třeba obrázky, které jsou už v přítomném kódu deklarované a jsou umístěné na funkčním serveru.

[Jendа]

IMHO vlastnost. Prohlížeč nemůže dál vykreslovat obsah stránky, protože by ten JS mohl volat třeba document.write() a až by se natáhl, už by ta část, kam se mělo zapsat, byla vykreslená.

[Filip Jirsák]

Čekání na skript, který nemá nastaveno defer=true, je normované chování prohlížeče – prohlížeč nemůže tušit, zda v tom skriptu nebude třeba document.write() (a v těch reklamních skriptech dost často je), takže musí přerušit parsování HTML a nejprve načíst a vykonat skript.

[petr_p]

prohlížeč nemůže tušit, zda v tom skriptu nebude třeba document.write()

Prohlížeč netuší spoustu věcí a dokáže spekulativně vykreslovat i tak (chybějící obrázky, veškeré javaskriptové aplikace).

Skripty se často procházejí po stromě, takže před jejich vykonáním musí být strom již hotový. To je samozřejmě neřešitelný případ, když skriptů běží více, takže běh nad rozpracovaným stromem musí být nějak implementován.

Proč toho nevyužít a nerozeběhnout parsování a vykreslování spekulativně vedle čekání na stažení dalších dokumentů – obzvláště, když se čekání ukáže dost dlouhé v řádu několika sekund?

[Filip Jirsák]

Prohlížeč netuší spoustu věcí a dokáže spekulativně vykreslovat i tak (chybějící obrázky, veškeré javaskriptové aplikace).

Je rozdíl v dotažení obrázku a v kompletním přebudování celého DOM stromu. Ten skript totiž nemusí vypsat jen uzavřený tag (uzel v DOMu), ale může vypsat cokoli -- dohromady s volnými pravidly pro parsování HTML a "domýšlení" uzavíracích a chybějících tahů to pak může znamenat, že ten skript úplně změní stukturu dokumentu.

Skripty se často procházejí po stromě, takže před jejich vykonáním musí být strom již hotový. To je samozřejmě neřešitelný případ, když skriptů běží více, takže běh nad rozpracovaným stromem musí být nějak implementován.

To je řešitelný případ a jedna ze základních věcí práce s JS v prohlížeči. Skript, který pracuje s DOMem, musí počkat na dobu, než je DOM vybudován -- a je k tomu dost událostí. Pokud jde o tenhle druh skriptu, je rozumné, aby autor skriptu přidal onen atribut defer. Ale musí to udělat autor, prohlížeč nemůže tušit, co v tom skriptu bude.

Proč toho nevyužít a nerozeběhnout parsování a vykreslování spekulativně vedle čekání na stažení dalších dokumentů – obzvláště, když se čekání ukáže dost dlouhé v řádu několika sekund?

Protože za místem vložení skriptu je jenom náhodné smetí, teprve až se skript vykoná, dá se to, co je za ním, interpretovat jako HTML kód. Myslíte, že následující kód může prohlížeč parsovat dál a výstup skriptu tam nějak doplnit?

<script>
document.write("<"+"!--");
</script>

<img src="obrazek.jpg" />

<script>
document.write("--"+">");
</script>

<table>
<tr><td></td></tr>

<script>
document.write("<"+"/table"+"><"+"table"+">");
</script>

<tr><td></td></tr>
</table>

[petr_p]

Rozumím, že skript může strom úplně předělat, ale to přeci nebrání prohlížeči vykreslit strom před skriptem a znovu po skriptu.

Vždyť bohaté ajaxové aplikace přesně tohle dělají. Proč by nemohl prohlížeč dělat „náhledy“ v časech, kdy skript nic nedělá?

Dokážu si představit, že při paralelním zpracování mohou nastat ošklivé souběhy, ale to je snad problém skriptů, že nepoužívají nějakou formu synchronizace.

Nakonec se může stát, že se první skript zacyklí a co pak? Tohle je to úžasné HTML, které se umí zotavit z chyb a vykreslovat se za běhu, jak tvrdí zastánci volného HTML?

Beru to jako polemiku se současným standardem, který v podstatě říká, dělejte to sekvenčně, ať programátoři nemají bolesti hlavy.

Mám tedy chápat reklamní kódy v Ábíčku jako lenost jejich programátorů?

(Mimochodem konstrujce typu "<"+"!--" je co? Chorobný strach, profesionální deformace nebo sarkasmus?)

[Leoš Literák]

 

Mám tedy chápat reklamní kódy v Ábíčku jako lenost jejich programátorů?

(Mimochodem konstrujce typu "<"+"!--" je co? Chorobný strach, profesionální deformace nebo sarkasmus?)

 Abicko reklamni kody nepise, naopak do nich nesmi nijak zasahovat.

 

[petr_p]

Mám tedy chápat reklamní kódy v Ábíčku jako lenost jejich programátorů?

Mám tedy chápat reklamní kódy v Ábíčku jako lenost jejich programátorů reklamních kódů?

Tohle jsem neřekl:

Mám tedy chápat reklamní kódy v Ábíčku jako lenost jeho programátorů Ábíčka?

[Leoš Literák]

Ok, nebylo to zrejme.

[Filip Jirsák]

Ale AJAXové aplikace mění DOM, ten skript může vypsat takový kód, který úplně změní to, jakým způsobem se z HTML stane DOM. Takže prohlížeč by se nejprve prokousal náhodným shlukem znaků, interpretoval to jako HTML, vykreslil, pak by zpracoval JS, vše předchozí zahodil a vykreslil znovu něco úplně jiného. Přitom pokud skript neovlivňuje parsování stránky, stačí, aby autor přidal jeden atribut, a hned je to vyřešené.

Nakonec se může stát, že se první skript zacyklí a co pak?

Aspoň trochu rozumný prohlížeč má ochranu proti zacyklení skriptu -- třeba počítá počet instrukcí, a pokud překročí určitý počet, dovolí uživateli skript zastavit.

Beru to jako polemiku se současným standardem, který v podstatě říká, dělejte to sekvenčně, ať programátoři nemají bolesti hlavy.

Ne, současný přístup říká: nepokoušej se uhodnout, jak ten skript asi bude vypadat, ale použij informaci, kterou ti dal programátor v atributu defer.

Mám tedy chápat reklamní kódy v Ábíčku jako lenost jejich programátorů?

Vzhledem k tomu, že ty kódy zpravidla používají document.write(), tak je čekání na skript správné. Jinak by kód musel vypadat tak, že by se na příslušné místo vložil třeba div s nějakým ID, a ten by si pak vyhledal skript v DOMu -- to by šlo dělat i bez čekání na skript. Ovšem zase by se muselo řešit, jakým způsobem vložit do jedné stránky víc reklamních pozic.

[petr_p]

Takže prohlížeč by se nejprve prokousal náhodným shlukem znaků, interpretoval to jako HTML, vykreslil, pak by zpracoval JS, vše předchozí zahodil a vykreslil znovu něco úplně jiného.

Přesně tak.

Rozdíl mezi dotahujícím skriptem a obrázkem je ten, že obrázek nemění strom, takže se ušetří parsování, ale stránka se stejně musí překreslit, protože nový obrázek může třeba vytlačit plovoucí boxy.

Přitom pokud skript neovlivňuje parsování stránky, stačí, aby autor přidal jeden atribut, a hned je to vyřešené.

Je to vyřešené, jen když věci jdou dobře. Pokud ne, uživatel nedostane nic. Kolikrát se mi už stalo, že v „Zobrazit zdrojový kód“ jsem obsah měl, ale na plátně jsem neměl nic.

Aspoň trochu rozumný prohlížeč má ochranu proti zacyklení skriptu

A proto bych chtěl takové chování i v případě čekání na Godota.

Jedním řešením je nabídnout vykreslení nedoskriptované stránky, druhým řešením je zobrazovat stránku průběžně.

Vzhledem k tomu, že ty kódy zpravidla používají document.write(), tak je čekání na skript správné.

Když jsem viděl zde uvedená schémata zpoždění, tak jsem se zhrozil. Prohlížeč 15 sekund nic nedělal. Za tu dobu už mohl uživatel vyhodnotit, že ho stránka nezajímá a opustit ji. Proto mi přijde současný způsob špatný.

Jinak by kód musel vypadat tak, že by se na příslušné místo vložil třeba div s nějakým ID, a ten by si pak vyhledal skript v DOMu -- to by šlo dělat i bez čekání na skript.

To už BBmedia dělá.

Nebo taky je možné identifikátor přiřadit elementu script a nově vytvářené elementy připojovat ze něj ve směru osy following-sibling. Nebo se lze orientovat podle script[@src].

Ovšem zase by se muselo řešit, jakým způsobem vložit do jedné stránky víc reklamních pozic.

Za to dnes je stránka prošpikována elementy script, které volají jedinou funkci na vložení pozice.

Pokud se web vydá cestou klientského skriptování a všelijakých kombinovaných stránek, které si vypůjčují kód a obsah odevšad (mesh-up), bude problém se zlobivými skripty nabírat na síle a vývojáři webových prohlížečů se jím budou muset zabývat. Občas nedestupný reklamní server je jen první vlaštovka.

[Leoš Literák]

Mohli bychom se vratit k tematu? Tedy za jakych okolnosti vam gemius zpomaluje stranky? Minimalne je vhodne nahlasit presny cas, trosku pokrocilejsi svou IP adresu, stredne pokrocili vystup z pingu a traceroute no a guruove zmenu konfigurace na strane gemiusu Tohle je reseni, (pomoci) zjistit, v cem je problem.

[Filip Jirsák]

Tak například já hlásím, že jsem takové zpomalování nikdy nezaznamenal, a nic neblokuju. A to ani ve Windows, ani v Linuxu, v obou případech Firefox 3, ISP je jednou Sloane a podruhé PragoNet.

Smyslem tohoto příspěvku není vyprovokovat všechny, kterým to funguje, aby také napsali komentář, ale zjistit, v čem je rozdíl oproti těm ,kterým to nefunguje.

[Jendа]

UPC, Iceweasel 3, také jsem ho ještě nikdy nezaznamenal. Respektive občas je ve stavovém řádku "čekám na blabla.gemius.pl", ale stránka už je skoro celá načtená. Neblokuju, jenom nemám nainstalovaný Flash plugin.

Mimochodem - ten gemiusí skript něco vypisuje? Nejde dát až na konec stránky?

[Prcek]

S tím Gemiusem to nemá asi nic společného, ale poslední dobou se mi stává, že při odesílání příspěvku do diskuze to chvíli (asi 5 vteřin) visí, než se stránka odešle. Při náhledu to nedělá. Že by tak dlouho trval zápis do databáze? Pozoroval to ještě někdo?

[Prcek]

Tak zrovna při posílání tohohle příspěvku to neviselo, tak možná je chyba někde u mě v prohlížeči nebo v připojení.

[Jendа]

Ne, mě to taky dělá. Hlavně ve špičce...

[Vojtěch Horký]

Pozoroval to ještě někdo?

Občas. Ale nedokážu vysledovat nějakou pravidelnost, takže jsem proti tomu nic nepodnikal. Prostě Brownův pohyb na síti .