ugrás a tartalomhoz

Google Analytics követőkód külön js-ben

mz82 · 2013. Dec. 8. (V), 20.42
Szeretem elkerülni, hogy a html forráskódba javascript kód kerüljön. Tudom, hogy vannak hátrányai a külső js állományok használatának, de számomra mégis elegánsabb és fejlesztés szempontjából is átláthatóbb ha minden nyelv (html, css, javascript, php) elkülönült állományokban van kezelve.

Ebből kifolyólag az Analytics követőkódot én mindig hozzácsapom valamelyik .js állományomhoz, de olyan is előfordul, hogy készítek neki önálló js-t.
Valaki magyarázza már meg nekem, hogy mi a gyakorlati haszna, hogy a legtöbb weboldal Google Analytics kódot mindenáron a html forráskódba tuszkolja!

Főleg akkor nem értem, ha egyébként az oldal 8-10 külső js fájllal dolgozik.

Teljesítmény szempontjából nem rosszabb, ha a követőkódot minden egyes aloldal statikusan tartalmazza?

Én úgy tudom, hogy a keresőmotorok sem örülnek neki, ha a kód mennyisége túl magas tartalomhoz képest.

A kérdést úgy is feltehetném, hogy miért használjunk inline javascriptet, ha nem muszáj?
‹ jQuery tablázat betöltése Teljes méretű ablak magassága ›
 ■
1

Trehányság.

hunkris · 2013. Dec. 8. (V), 21.11
Trehányság.
2

külső fájlok

Poetro · 2013. Dec. 8. (V), 21.29
A Google dokumentáció azt "ajánlja" a legtöbb helyen, hogy rakjuk be az oldal kódjába. Mondjuk nem tudom, még mindig ez-e a helyzet, de pár évvel ezelőtt még igen.
A legfontosabb, csökkenteni kell az oldalon hivatkozott fájlok számát, mert ez a leginkább befolyásoló tényező az oldal letöltődési idejében. Ha egy kapcsolódás mondjuk 300ms, és a fájl letöltődési ideje 200ms, akkor minél több kapcsolódás van, annál rosszabbul járunk az összidő tekintetében (főleg mobil kapcsolat esetén). Ezért illik a fájlokat összefűzni, és típusonként 1-2 típust kiszolgálni.
3

Igen, a Google is ezt

mz82 · 2013. Dec. 8. (V), 21.42
Igen, a Google is ezt ajánlja, ezért gondoltam, hogy megkérdezem nálam okosabbaktól, hogy miért. :-)

A sok hivatkozott fájllal kapcsolatban igazad van. Csak nevetségesnek találom, amikor olyanok hivatkoznak a követőkód html-be szúrásánál erre a tényezőre, akik azt sem tudják mi az a CSS Sprite! :-) A 100 beolvasott apró, önálló kép egy nagyságrenddel jobban lassítja a weboldal megjelenítését.

Egyébként a js állományokat is cache-eli a böngésző, ezért szerintem emiatt akár gyorsabb is lehet a külső állomány, mivel ha html kódba van ágyazva, akkor az minden oldalhívásnál újra meg újra letöltődik.

Bocsi, ha úgy tűnik bolhából csinálok elefántot, de eldurrant az agyam egy "profi webdesignertől".
5

Attól, hogy 100 apró ikon

bamegakapa · 2013. Dec. 9. (H), 01.21
Attól, hogy 100 apró ikon külön fájlban lekérése valóban hülyeség (akár sprite, akár font okosabb lenne helyette), és valóban komolyabb probléma, még igaza van sajnos a fickónak :).
6

Nem igazán értelek. Miért is

mz82 · 2013. Dec. 9. (H), 01.39
Nem igazán értelek. Miért is van igaza?
A másik hozzászólásodnál épp azt írod, hogy ha nem jár plusz fájltöltéssel, akkor külön fájlba érdemes tenni a js-t. Vagy rosszul értettelek? Valaki le tudja írni mitől jobb az oldalanként generált html-be tenni a követőkódot, mint egy összefűzött külső js állományt használni?
7

Rosszul értetted

Pepita · 2013. Dec. 9. (H), 02.25
Ez a lényeg:
Az Analytics kódot jellemzően oda szoktam rakni például, illetve más apróbb JS hívásokat is, ezek nem jelentenek jelentős pluszt a HTML-ben (főleg gzippelve).
A külön fájl mindig külön fájltöltéssel jár.
Az Analytics kódot azért is javasolja gugli pont a </body> elé, mert ez is beránt még 1-2 js-t, de ezt akkor teszi, mikor már teljesen megjelent az oldalad, lefutottak (nagyobb részt) a te szkriptjeid. Ráér ő akkor is analizálni.
9

Alakul ez! Tényleg nem

mz82 · 2013. Dec. 9. (H), 10.22
Alakul ez! Tényleg nem kötekedni akarok, hanem megérteni!

Van abban különbség, ha a <head>-ben egyetlen js-em van, amiben minden script-em lefut követőkóddal együtt, vagy ha van egy js-em és külön még inline-ban a követőkód?
Mert én ezt nem értem, hogy ha így is úgy is van külön js, akkor mit is spórolok meg az inline cuccokkal?

Fárasztó vagyok? :-)
10

az inline téma rögtön lefut,

szabo.b.gabor · 2013. Dec. 9. (H), 10.30
az inline téma rögtön lefut, nem kell várni a plusz kérésre. hamarabb elindul az analytics kód, hamarabb és több eredményed lesz. ennyi.
12

Milyen plusz kérés van?

mz82 · 2013. Dec. 9. (H), 10.39
Milyen plusz kérés van ha így is úgy is van külső js fájl és csak abba van belefűzve a követőkód?
14

Hát pont annak az összefûzött

bamegakapa · 2013. Dec. 9. (H), 11.15
Hát pont annak az összefûzött külsõ jsfájlnak a lekérése :).
15

Oks, tehát egyről beszélünk

mz82 · 2013. Dec. 9. (H), 11.28
Oks, tehát egyről beszélünk és nincs plusz kérés. :-)
18

1. kérés html betölt.. inline

szabo.b.gabor · 2013. Dec. 9. (H), 11.49
1. kérés
html betölt..
inline js esetén elindul a futtatása.

2. kérés
js fájl betölt
ha itt van az anal kód, akkor csak itt kezd el futni, tehát egy kéréssel később..
21

Pedig van

Endyl · 2013. Dec. 9. (H), 12.14
A követőkód szempontjából "gyorsasági" sorrend:

Két egymást követő, blokkoló kérés:

<script src="sajat.js"></script>
<script src="koveto.js"></script>
A következő kettő nagyjából egy szinten lesz (a plusz egy kérés a saját js betöltése; akár benne van a követőkód, akár nincs, ugyanúgy le kell azt tölteni):

<script src="sajat.js"></script>
<script>
//inline koveto
</script>


<script src="sajat_plusz_koveto.js"></script>
Az előző esetekben a saját js letöltése mellett a saját js futtatása is megelőzi a követőkódot, ami lehetővé teszi nagy js és lassú hálózat mellett, hogy a látogató unalmában bezárja a lapot, mielőtt a követőkód lefutna, és így nincs mérés. Különösen, ha a nagy js a head-ben van, és a js-ek lefutásáig semmi tartalom nem jelenik meg, amit nézegethetne. Ezért célszerű a </body> elé pakolni ezeket.

A következő esetben nincs külön kérés, amint megvan a html vonatkozó része, minden egyéb előtt lefut a követőkód, és a lehető leghamarabb kezdődhet a mérés. Persze ha a követőkód hosztja felé is lassú a kapcsolat (és nem async módon szúrja be a saját extra kódjait), akkor itt is bezárhatja a lapot a látogató, de itt a lehető legkisebb az eshetősége:

<script>
//inline koveto
</script>
<script src="sajat.js"></script>
23

Kösz a melót! :-)

mz82 · 2013. Dec. 9. (H), 12.29
Kösz a melót! :-)
17

Gyorstárazás

Hidvégi Gábor · 2013. Dec. 9. (H), 11.44
Meg kell nézni, milyen fejlécekkel megy ki egy statikus fájl, mert nem mindig optimális az alapbeállítás. Ha például nincs megadva lejárati idő (Expires), az utolsó módosítás dátuma (Last-Modified), akkor hiába van a böngésző gyorstárában a fájl, minden alkalommal küld egy ellenőrző kérést a szerver felé, hogy változott-e valami, ami általában majdnem ugyanolyan lassú, mint amikor letöltöd a teljes állományt (kis fájlok esetében).
4

Pár soros kódrészleteknél

bamegakapa · 2013. Dec. 9. (H), 01.17
Pár soros kódrészleteknél kifejezetten jobban jársz, ha HTML-be rakod, mivel így drága requesteket spórolhatsz (minden megspórolt request számít!). Az Analytics kódot jellemzően oda szoktam rakni például, illetve más apróbb JS hívásokat is, ezek nem jelentenek jelentős pluszt a HTML-ben (főleg gzippelve). Ilyesminek külön fájlt nyitni pazarlás, hacsak nincs normális deploy ami összefűzi a JS fájlokat.

Bizonyos peremesetekben ráadásul jól jön, ha a kód akkor és ott fut le, amikor és ahol te azt akarod, várakozási idő nélkül.

Ezeket a speciális eseteket leszámítva természetesen külön JS fájlok használata a javasolt, úgy az olvashatóság/fenntarthatóság, mint a kesselhetőség szempontjából. Persze amikor már 8-10 darabig eljutsz, ideje az összefűzésen/minifikáláson alaposan elgondolkozni ;).

Ami nálam mindig kiveri a biztosítékot, az az inline eseménykezelők használata :).
8

azért jó a html-be rakni és a

szabo.b.gabor · 2013. Dec. 9. (H), 09.05
azért jó a html-be rakni és a head részbe (mivel async, így nem blokkolja az oldalad (pl ha offline a google)), mert ily módon tud a leghamarabb betöltődni, tehát olyan látogatásokat is eséllyel tud már logolni, amik azelőtt elhagyják az oldalt, hogy betöltődne.
11

Légyszi nézd meg a 9-es

mz82 · 2013. Dec. 9. (H), 10.37
Légyszi nézd meg a 9-es válaszom!
A külső js is a head-ben van <script src>-vel, akkor az blokkolja az oldal betöltődését?
Egyébként, ha a követőscript a localhost-on futó oldalon is bentvan, ami épp nem csatlakozik netre, az oldal akkor is gyönyörűen felépül, csak a google nyilván nem logol.
Milyen látogatás az, ami elhagyja az oldalt mielőtt betöltődne? :-)
13

A külsõ jst nem érdemes

bamegakapa · 2013. Dec. 9. (H), 11.12
A külsõ jst nem érdemes headbe rakni, mert blokkol. Ezeket a body záró tagje elé javasolt rakni. Kivéve ha valamiért nagyon fontos, hogy már a headben lefusson.

Az analytics kódot úgy érdemes elhelyezni, hogy mindenképp lefusson. Több adat. Ezért rakják simán a htmlbe, akár a headbe, hogy bármi történjék, lefusson. Lehet, hogy a nagy külsõ jsed meg sem érkezik, hálózati hiba, mittomén, de az analytics loggol mégis. Hát csupán ezért, amennyire én tudom.
16

Az első két mondattól azért

mz82 · 2013. Dec. 9. (H), 11.32
Az első két mondattól azért felhúztam a szemöldököm! Ezek után meg sem merem kérdezni, hogy milyen javascript számít nálad nagyon fontosnak???
Vagy hogy kukacoskodjak, ezzel az erővel az Analytics fontosabb mint mondjuk az oldal működését alapvetően érintő JQuery?

Nekem az jött át, hogy tulajdonképpen csak a szokás hatalma miatt kerül az a követőkód a html-be, egyébként semmi elméleti illetve gyakorlati haszna nincs.
19

Ha nem akarod megérteni,

bamegakapa · 2013. Dec. 9. (H), 11.56
Ha nem akarod megérteni, minden hiába. Higgadj le, olvass utána, aztán még beszélgethetünk.
25

Akkor tedd vissza a helyére

Pepita · 2013. Dec. 9. (H), 23.19
a szemöldököd is, meg amit mondtak neked, azt is. :)
Külső js-ről beszél végig.
Vagyis: nem a te szervereden / tárhelyeden van, és ha épp beszart a másik szerver, a te oldalad sem jelenik meg. Másképp, ha html-be rakod, akkor csak nem fog analizálni, de az oldalad szépen felépül, lefut, stb.

Ha már a JQuery-t említed, azt is célszerű letölteni, és a saját szerverről kiszolgálni. Egyébként nem ritkán gyorsabb is így a letöltés. (Persze a látogató sávszélétől is függ.)
20

a külső js és a blokkolás úgy

szabo.b.gabor · 2013. Dec. 9. (H), 12.02
a külső js és a blokkolás úgy értendő, hogy ha mondjuk a jquery-t cdn-ről húzod be egy külső szolgáltatótól és az a szolgáltató épp nem üzemel, akkor szopó van, mert meg kell várni a timeout-ot (30 sec pl) és csak utána fut tovább az oldal.
(function() {
	var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
	ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
	var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
ez egy analytics beszúró kódrész, ami annyit tesz, hogy beszúr neked még egy script tag-et. a ga.async = true miatt localon net nélkül sem blokkol. de mondjuk vedd ki ezt a részt és nézd meg úgy.

amúgy a javascript-et érdemes tényleg a </body> zárótag elé rakni, mert a vizuális megjelenés a gyorsasága fontosabb, mint az eseménykezelések betöltése (először látja a júzer, utána használja), tehát ha van egy nagy js-ed azt sem érdemes a head-be rakni.

ki az a felhasználó aki már akkor elhagyja az oldalt, amikor még be sem töltődött?

az aki nem szeretné kivárni a 4 másodperces betöltési időt pl és lelép. fontos, mert használni szeretné az oldalad, csak rájön, hogy neki nem megfelelő a minőség. és ha mondjuk egy GA nem jelzi neked ezeket, akkor észre sem veszed őket és azt hiszed minden ok.

pl ha az edigital nem lenne akkora név, akkor tuti nem használnám az oldalukat, mert nagyon lassú.
22

Köszi ez így már

mz82 · 2013. Dec. 9. (H), 12.27
Köszi ez így már elgondolkodtató!

Nem használok távoli domain-en lévő javascriptet. Az oldalaim általában 1-2 sec alatt teljesen felépülnek, ha már cache-elt, akkor 0.4-0.7 sec alatt.

Akkor tehát az az optimális, hogy Analytics statikusan <head>-ben, és a külső js pedig összefűzve a </body> előtt <script src>-vel.
24

igen.

szabo.b.gabor · 2013. Dec. 9. (H), 12.32
igen.