11 stycznia 2011

Rekomendacje SEO, a poprawne działanie Google Analytics

Skrypty JavaScript osadzane są w kodzie strony w pliku zewnętrznym bądź "inline", czyli w źródle strony. Zarówno plików zewnętrznych jak i bloków JavaScript osadzonych "inline" może w dokumencie HTML występować wiele, co powoduje znaczne zwiększenie objętości kodu w stosunku do treści. Pod względem przyjazności dla wyszukiwarki jest to sytuacja wpływająca negatywnie na SEO. Dlatego też...

Często jedną z rekomendacji SEO, mającą na celu przyśpieszenie ładowania strony i ograniczenie ilości kodu w źródle, jest przeniesienie skryptów JavaScirpt do zewnętrznego pliku. Przeniesienie wszystkich skryptów do jednego pliku ma tę zaletę, że w źródle strony ogranicza się do jednej linijki kodu, a w kontekście komunikacji z serwerem, na którym znajduje się strona, sprowadza się do wysłania jednego żądania. Istnieje jednak ryzyko, że część skryptów przestanie działać poprawnie ponieważ wymaga do działania innych skryptów, które powinny być ładowane wcześniej. Problem ten dotyczy synchronicznego kodu Google Analytics - starego kodu, który jeszcze w dużym stopniu występuje na stronach. Standardowo kod ten ma postać:

<script type="text/java_script">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/java_script'%3E%3C/script%3E"));
</script>
<script type="text/java_script">
var pageTracker = _gat._getTracker("UA-XXXXXX-YY");
pageTracker._trackPageview();
</script>

Kod jest osadzany za pomocą dwóch znaczników pobierany jest plik ga.js z serwera Google Analytics, natomiast w drugim bloku definiowany jest kod śledzący i zliczane są odwiedziny. Bardzo ważne jest, aby plik ga.js został załadowany przed zdefiniowaniem trackera, bo w przeciwnym wypadku obiekt _gat odpowiedzialny za utworzenie trackera nie zostanie wykryty i pojawi się błąd, a w konsekwencji odwiedziny nie zostaną zliczone. Istotne jest też, aby plik ga.js i kod śledzący trackera definiować w dwóch oddzielnych blokach .... Wykonywanie skryptów na stronie internetowej następuje blokami definiowanymi przez parę wspomnianych znaczników , kolejno jeden blok po drugim - nie może się wykonać kolejny blok, jeśli nie zakończy się wykonywać poprzedni. Kolejność wykonywania jest dokładnie taka, jak kolejność bloków w dokumencie. Mało tego, jeśli w dowolnym bloku pojawi sie kod podobny do tego:

document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/java_script'%3E%3C/script%3E"));

definiujący dynamicznie kolejny blok JavaScript, następny w kolejności wykona się blok dynamiczny, a dopiero po nim kolejna sekcja kodu JavaScript.

Z tego sposobu działania wynika konieczność umieszczenia synchronicznego kodu śledzącego Google Analytics w dwóch oddzielnych znacznikach i to w dokładnie takiej kolejności, ponieważ najpierw musi zostać załadowany plik ga.js z serwera Google, by w następnym kroku można było utworzyć obiekt trackera i zliczyć odwiedziny. Kolejność odwrotna spowoduje błąd, ponieważ w momencie tworzenia trackera obiekt _gat odpowiedzialny za jego utworzenie nie będzie jeszcze istniał. Umieszczenie w jednym bloku zarówno definicji pliku ga.js jak i kodu trackera również spowoduje taki błąd. Podobna sytuacja wystąpi kiedy będziemy chcieli przenieść wszystko do jednego zewnętrznego pliku - w momencie wykonywania skryptu z pliku zewnętrznego obiekt _gat nie będzie załadowany do pamięci podręcznej, ponieważ pobranie pliku ga.js nastąpi dopiero w momencie zakończenia aktualnie przetwarzanego bloku JavaScript.

Stąd też następujący kod:

var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/java_script'%3E%3C/script%3E"));
var pageTracker = _gat._getTracker("UA-XXXXXX-YY");
pageTracker._trackPageview();

niezależnie od tego czy będzie umieszczony w zewnętrznym pliku JavaScript czy wewnątrz strony (znaczniki ) nie będzie działał poprawnie.

Jeśli więc konieczne jest umieszczenie skryptów JavaScript w plikach zewnętrznych np. ze względu na rekomendacje SEO dotyczące skryptów JS, zawsze należy zastosować dwa odrębne pliki

<script type="text/javascript" src="gahost.js"></script>
<script type="text/javascript" src="gatracker.js"></script>

umieszczając w pierwszym procedurę ładowania pliku ga.js:

var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/java_script'%3E%3C/script%3E"));

i w drugim definicję trackera:

var pageTracker = _gat._getTracker("UA-XXXXXX-YY");
pageTracker._trackPageview();


--

Konrad Dopieralski


Udostępnij:

11 komentarzy:

Anonimowy pisze...

rekomendacje SEO, a tekst został umieszczony w grafice :)

blueranki pisze...

Poniewaz jednak w nazwie pliku jest najwazniejsze slowo kluczowe... uznajemy te grafike za przyjazna dzialaniom SEO ;)

Grzegorz Getka pisze...

Czytając ten artykuł ma wątpliwości, czy osoba go pisząca ma jakiekolwiek pojęcie o frontendzie, a w szczególności JS :/

Redakcja bluerank.blogspot.com pisze...

Czytając ten komentarz Redakcja ma wątpliwości, czy osoba go pisząca ma jakiekolwiek pojęcie o tym, co właściwie chciałaby zarzucić autorowi artykułu.

Grzegorz Getka pisze...

Szybkość ładowania się nie zależy wyłącznie od ilości kodu JS, ale przede wszystkim od tego co w tym kodzie jest. Idąc tokiem myślenia prezentowanym w artykule wynika, że np. lepiej jest stosować metodę live, zamiast metody delegate, ponieważ napis "live" jest krótszy od "delegate", a w praktyce jest na odwrót. Przede wszystkim należy zwrócić uwagę na to jak wygląda kod JavaScript. Przeniesienie kodu JS do zewnętrznego pliku nie zawsze jest szybszym rozwiązaniem, to zależy od typu strony...

bluerank pisze...

Celem artykułu było zwrócenie uwagi na jeden ze szczególnych przypadków osadzania synchronicznego kodu Google Analytics - w pliku zewnętrznym wraz z jego poprawną implementacją. Autor komentarza nie zauważył, że to jest własnie clou opisywanego problemu. Osadzanie kodu w pliku zewnętrznym było tylko przyczyną zaistniałego problemu i powodem powstania artykułu.

Temat szybkości ładowania dokumentu został poruszony jedynie w kontekście rekomendacji SEO. Abstrahując od tego, czy jest to dobre czy złe rozwiązanie - w przypadku rekomendacji SEO każdy element JS jest rozpatrywany indywidualnie, uogólniając jednak można powiedzieć, że przeniesienie kodu JS do zewnętrznego pliku jest stosowaną rekomendacją audytu SEO mającą na celu przyśpieszenie ładowania dokumentu.

I w końcu to co najważniejsze - należy w tym przypadku zauważyć, że autor komentarza pomylił dwa czynniki: szybkość ładowania dokumentu HTML z szybkością jego generowania (to co się dzieje już po pobraniu wszystkich plików z serwera), w której to istotne znaczenie odgrywa jakość kodu ("... to jak wygląda kod..."). W przypadku szybkości ładowania (czas ładowania - trwający od momentu zgłoszenia żądania do serwera do momentu pobrania pliku) najważniejsza jest wielkość pliku, kompresja, dostępność serwera / pliku, czyli czynniki bardzo techniczne, a wygląd kodu nie ma najmniejszego znaczenia. Oczywiście, pośrednio może mieć znaczenie jeśli twórca kodu zawrze w 1000 wierszach to, co można by zawrzeć w 3, ale tylko pośrednio bo w rzeczywistości wzrasta wielkość pliku ;)

Grzegorz Getka pisze...

Niczego nie pomyliłem. Google zbiera dane także o tym, co dzieje się na stronie po załadowaniu plików JS. Dowód jest prosty, a mianowicie indeksacja stron, do których prowadzą linki wrzucane przez JS. Napiszę nawet więcej... Google indeksuje linki wrzucane na stronę przez setTimeout. Jak to robi? Prawdopodobnie, dzięki googlebotowi parsującego kod JS. Kod GA omówiony w artykule pochodzi chyba sprzed kilku lat... Aktualnie kod GA to tylko jeden element script z kilkoma linijkami kodu. Artykuł nosi tytuł "Rekomendacje SEO", więc jak rozumiem Wy rekomendujecie przerzucenie kodu GA do zewnętrznego pliku. W ten sposób spowalniacie ładowanie się strony... Zwiększacie liczbę żądań do serwera. Czas odpowiedzi serwera jest o wiele dłuższy niż załadowanie kodu strony zawierającego kilka linijek kodu GA. I na zakończenie, czemu moje komentarze pojawiają się z takim opóźnieniem i jednocześnie z Waszą odpowiedzią. To taki PR?

Aneta Mitko pisze...

"(...) czemu moje komentarze pojawiają się z takim opóźnieniem i jednocześnie z Waszą odpowiedzią. To taki PR?"

Panie Grzegorzu

Swoje komentarze (tak jak ten ostatni zreszta) dodaje Pan zwykle poznym wieczorem. Osoba, ktora odpowiada za moderacje (to akurat ja :) nie pracuje przez cala dobe. Prosze wiec wybaczyc i zrozumiec ewentualne opoznienia.

Co do odpowiedzi natomiast... sa one po prostu natychmiastowe. Zabieram sie za moderacje, odpowiadam od razu jesli cos wymaga odpowiedzi czy ustosunkowania sie lub prosze o zredagowanie komentarza odpowiednia osobe z zespolu Bluerank. Nie widze w tym nic niestosownego. Czy to taki PR? Tak - zadnego komentarza nie pozostawiamy bez odpowiedzi dluzej, niz to naprawde konieczne... bo nawet nie wypada inaczej.

PS
Do merytorycznych kwestii przez Pana poruszonych odniesie sie (najszybciej jak to bedzie mozliwe) autor wpisu.

Pozdrawiam
Aneta

bluerank pisze...

Panie Grzegorzu

Uchylając rąbka tajemnicy...

Rekomendujemy jako optymalne rozwiązanie przenoszenie kodu JavaScript do jak najmniejszej liczby plików zewnętrznych. Klient, który dostał taką rekomendację potraktował to mocno dosłownie i przeniósł także kod Analyticsa, co spowodowało, że GA przestał zliczać odwiedziny. Naturalnie jesteśmy zdania, iż bycie aż takim JavaScript-owym purystą jest zbyteczne, aczkolwiek przedstawione rozwiązanie... rozwiązuje problem - stąd case.

pierwsza pozycja pisze...

Faktycznie, nie należy być aż takim JavaScript-owym purystą ;))
Trochę poprawiliście mi humor z rana :)

A tak swoją drogą, mam pytanie odnośnie komentarza:
"Poniewaz jednak w nazwie pliku jest najwazniejsze slowo kluczowe... uznajemy te grafike za przyjazna dzialaniom SEO ;)"

Dlaczego case+konrada to plik o rozszerzeniu .BMP?
Tyle na blogach seo pisze się o optymalizacji kodu oraz grafiki, a zamieszczony jest obrazek ważący jakieś 360KB, zamiast np. plik graficzny w formacie gif, ważący po optymalizacji ok 30kb. Toż w tym przypadku można by zaoszczędzić mnóstwo transferu (ponad 330kb x ilość pobrań obrazka). Oczywiście blogger.com jest platformą darmową, więc nie ma się czym martwić o transfer, ale mimo wszystko waga grafiki jest dość spora.
Ciekawi mnie też ile macie w takim razie wejść z wyszukiwania grafiki na słowo case?
Grafika jest w wynikach, dopiero przy zawężonym wyszukiwaniu - tylko dla plików bmp.
Byłbym wdzięczny za odpowiedź.

Aneta Mitko pisze...

Dla wygody czytelnikow oraz aby wszystko bylo rzeczywiscie calkowicie zgodne z zasadami optymalizacji... lekkie, latwe i przyjemne w odbiorze i pobieraniu :) obrazek zostal zastapiony tekstem. Przepraszam, jesli przez ten czas gdy wisiala tu grafika, przyczynilismy sie do jakiegokolwiek dyskomfortu naszych uzytkownikow (ktorym notabene dziekujemy za komentarze).

PS
Zdecydowanie stawiamy na ludzi! Wiecej wejsc mamy na Konrada ;-))

Pozdr
Aneta