Klára Boháčková Kunová
Konzultantka
Vyplatí se přejít na asynchronní kód Google Analytics?
Vydáno na blogu Digitální analytika, CRO a UX
Jako dva velké přínosy asynchronního kódu společnost Google prezentuje: kratší celková doba načítání stránek, lepší statistiky o uživatelích s krátkými návštěvami. Z jakého důvodu Google slibuje tato zlepšení? V čem je asynchronní kód lepší? Podívejme se na základní rozdíl mezi oběma kódy. Tradiční kód Google Analytics vs. asynchronní Klasický kód Google Analytics, který se běžně […]
Jako dva velké přínosy asynchronního kódu společnost Google prezentuje:
- kratší celková doba načítání stránek,
- lepší statistiky o uživatelích s krátkými návštěvami.
Z jakého důvodu Google slibuje tato zlepšení? V čem je asynchronní kód lepší? Podívejme se na základní rozdíl mezi oběma kódy.
Tradiční kód Google Analytics vs. asynchronní
Klasický kód Google Analytics, který se běžně používal před asynchronním (a který má na svých stránkách dodnes vysoké procento webů), se tradičně umisťoval do spodní části stránky, těsně před koncovou značku </body>. Pokud uživatel přišel na stránku s takto vloženým kódem, nemusela se jeho návštěva zaznamenat. Důvodem bylo umístění kódu ve spodní části stránky, neboť se nemusel stihnout načíst celý HTML kód včetně kódu Google Analytics.
Vkládání klasického kódu Google Analytics do části </body> nebylo nutnou podmínkou a data se dobře sbírala i tehdy, pokud byl kód umístěn v hlavičce. To mohlo vést ke zpomalení načítání stránek, protože stránka čekala s vykreslením, než se navázal HTTP požadavek na neznámý server (takže se navíc zpracovával DNS požadavek) a než se stáhnul a interpretoval skript z cizího serveru.
Oproti tomu asynchronní kód lze vkládat mezi značky <head> a </head>, aniž by vykreslování stránky čekalo na jeho načtení. Proto by měl tento typ kódu urychlit dobu načítání stránek. Z naší zkušenosti se to však nepotvrdilo.
Naše testování rychlosti asynchronního kódu
Měřili jsme dobu načítání stránek dvanácti webů s počtem stránek v řádu tísíců, na kterých byl nejdříve umístěn tradiční kód Google Analytics, a poté asynchronní. Ani v jednom z případů jsme nenaměřili významně kratší dobu načítání stránky, v průměru doba načítání zůstala stejná.
Asynchronní měřicí kód není nutné vkládat do hlavičky, lze ho umístit prakticky kdekoliv (třeba i do patičky). Pak ale přijdete o výhodu, že se vám zaznamenají informace o návštěvnících, kteří na stránce strávili velmi málo času a odešli dříve, než se stihnul načíst celý HTML kód.
Další výhody přechodu na asynchronní kód si přečtěte v článku Jak přejít na asynchronní měřicí kód v Google Analytics.
Dobrý den,
měl bych ke článku pár připomínek.
V textu Vám očividně chybí některé HTML tagy ,nebo názvy tagů, např. ve větě :
„se tradičně umisťoval do spodní části stránky, těsně před koncovou značku .“ chybí před tečkou slovo BODY, případně název tagu, .<./.B.O.D.Y.>.
těch chybějících HTML tagů je tam více.
Zvěřejněný článek byste si po sobě mohli přečíst, pokud mohu doporučit.Chtěl bych se také zeptat, jakým způsobem jste měřili zmíněných 12 webů s tisíci stránkami. Testovat všechny stránky asi bylo relativně časově náročné.
Použili jste nějaký reprezentativní vzorek podmnožiny stránek z webů? Typové stránky? Náhodné? Všechny?
Jak jste testovali načítání stránek z webu? Pomocí PHP? Nebo nějakého online nástroje? Nebo desktopové aplikace? Či jinak?Mrzí mě, že je článek zcela bez dat, což nechápu, když právě o datech tento článek pojednává.Vámi změřená data by mne vcelku zajímala, protože mám subjektivní názor, že v některých případech asynchronní kód funguje daleko spolehlivěji, než tradiční, a to např v těchto případech:
– když jsou servery Googlu velmi pomalé a nestihnou ihned odeslat odpověď na požadavek GATC.
– když uživatel odejde ze stránky dříve, než se celá načte (načítání stránky podle mého nározu může zpomalit, když máte na webu cizí iframy, reklamní bannery z jiného webu, nebo Twitter a Facebook Social aplikace – jako Like It button, atd.).Změřeno to ovšem nemám, do toho jsem se nepouštěl.Budu se těšit, jestli svůj článek trochu doplníte, jinak se z mého pohledu jedná spíše, s prominutím, „o-článek-narychlo-vypublikovaný-v-pátek-před-koncem-šichty,-než-půjdu-konečně-do-hospody,-nebo-domů“. :-)S pozdravem,
Ja.rek
Dobrý den,děkuji za připomínky k HTML tagům. Vždy při úpravě článků náš redakční systém převede znaky < a > na < a > a následně tag nezobrazí. :-( Už jsem to opravil.Na zbytek vám odpoví Klára Boháčková v pondělí. Článek vyšel již ve čtvrtek v poledne. Diskutovali jsme o tom ve firmě, měli jsme data, a tak jsme si řekli, že by bylo dobré ona data publikovat i pro veřejnost.
Super, už se těším na pondělí.
Dobrý den,měření probíhala prostřednictvím několika různých serverů v časovém období cca 2 měsíce (provedli jsme dvě kontrolní měření). Vzorek dat byl 80 % stránek, přičemž hlavní stránky byly měřeny vždy.Data klientů zapojených do testování zveřejňovat nemůžeme (jsme vázáni smlouvou). V osmi případech se jednalo o data e-shopů.
Dobrý den, rád bych se zeptal, jestli tím posledním komentářem chápete článek jako kompletní a doplněný o data, o kterých mluví Robert Němec?
Já ta data stále postrádám. :-) (Nemyslím data o webech klientů, ale obecná data o tom, kolik milisekund trvalo stažení a interpretace JavaScriptu na webech s asynchronním GATC a kolik to trvalo s tradičním GATC – nic, co by vypovídalo o )A ještě poznámka – Chápu dobře, že mezi měřeními uplynuly 2 měsíce? Tzn., že se mezitím mohly změnit poměry na serveru a ryclost zásadně zkreslit?Mimo dat bych se ještě rád zeptal, který nástroj jste použili pro stažení a změření rychlosti stežení a interpretace JavaScriptového GATC kódu. Rád bych si to zkusil i na svých webech, takže by mi tip na aplikaci pomohl.Ja.rek
Pokud jsou weby klientů v podobně špatném technickém stavu jako tyto stránky, zpoždění generované suboptimálním měřícím kódem je ten úplně nejmenší problém, pod úrovní statistické chyby:http://www.webpagetest.org/res…http://www.webpagetest.org/res…
Bohužel ano, Jarku. I když jsem se těšil, že zde v pondělí zveřejníme podrobná data, bohužel jsme k tomu nedostali souhlas. Prostě nesmíme explicitně zveřejňovat žádná čísla.Omlouvám se, mrzí mě to. :-( Chtěli jsme se aspoň podělit o poznatek. Nikde neříkáme, že je to velké měření zahrnující stovky webů. Jsou to různé weby klienta napříč Evropou.Co se týká měření, proběhlo stylem úterý starý kód, středa nový. Pak za dva měsíce úterý nový, středa den starý.Z veřejně dostupných nástrojů zkuste třeba Google Webmaster Tools, my zde máme ještě nástroje od webhostera pro zjišťování rychlosti.
Petře, přiznávám, že náš redakční systém je velmi starý a jeho vývoj jsme před mnoha lety ukončili. Pokud se nemýlím, na tomto CMS už žádný web nejede.A weby klienta rozhodně ne (jednalo se o různé weby klienta napříč Evropou).Na druhou stranu by se nám vzhledem k našemu objemu provozu rozhodně nevyplatilo optimalizovat rychlost stahování.Navíc koukám, že náš web je na tom ve vašem testu jenom o čtyři, respektive tři body hůře než hlavní stránka Seznamu. To je dobré. :-)Měření jsme prováděli pro jednoho nadnárodního klienta, který má různé weby v různých zemích Evropy. Neříkáme, že je to dokonalý výzkum. Jsou to data, která máme k dispozici a říkali jsme si, že bychom se o tento poznatek mohli podělit. Jakékoli podrobnosti nám bohužel klient zakázal zveřejňovat.
Petře, mám pro vás dobrou zprávu.Všiml jsem si, že jste měřil údaje se splashem. Ten jsme včera odstranili, takže doba načítání je nyní podstatně kratší oproti původním výsledkům:http://www.webpagetest.org/res…Aktuálně je doba načítání více jak poloviční oproti http://www.idnes.cz pro první návštěvu a o více jak 50 % rychlejší pro druhou návštěvu (http://www.webpagetest.org/res….Ty špatné výsledky byly způsobeny splashem. Podívejte se na to prosím nyní.
Srovnávání s iDNESem je irelevantníVypnuté cachování obsahu je stále blbě.Skutečné zrychlování webu pomocí opravy jeho konfigurace vypadá asi takto:Oprava chybného nastavení e-shopu http://www.silver.ag:Původní stav:
http://www.webpagetest.org/res…
První zobrazení: 12.646 sekund
Opakované zobrazení: 11.444 sekundPo opravě nastavení HTTP komprese, cachování a persistentních spojení
(keep-alive):
http://www.webpagetest.org/res…
První zobrazení: 6.326 s ekund
Opakované zobrazení: 2.311 sekundPrvní načtení stránky http://www.silver.ag (s prázdnou cache v browseru) se
tedy zrychlilo dvojnásobně.Opakované zobrazení se zrychlilo pětinásobně.Vývojáři a administrátoři webu se změnám bránili, nakonec se však
většinu změn podařilo provést.Chybí ještě jedna důležitá změna, přesun statického obsahu na
separátní hostnames (css.silver.ag, js.silver.ag, gif.silver.ag…), k
té by mělo dojít později => očekávám další zrychlení webu
Mimochodem, procházel jsem si nyní Google Webmaster Tools (GWT). GWT hlásí, že „Načítání je rychlejší než u 91 % ostatních webů.“ Je bráno období za posledních pět měsíců. Během této doby se web stále pohyboval v zelené zóně, kromě první poloviny únoru, kdy to na chvíli vystřelilo krátkodobě prudce vysoko (nevím, asi něco na Ignumu).
http://pagespeed.googlelabs.co…