Czy Google Analytics generuje narzut wydajności?

83

W jakim stopniu Google Analytics wpływa na wydajność?

Szukam następujących:

  • Benchmarki (w tym czasy odpowiedzi / czasy ładowania stron i inne)
  • Linki lub wyniki do podobnych testów porównawczych

Jedna (możliwa) metoda testowania Google Analytics (GA) w Twojej witrynie:

  1. Udostępniaj ga.js (plik JavaScript Google Analytics) z własnego serwera.
  2. Aktualizacja z Google Daily (test 1) i Weekly (test 2).

Chciałbym zobaczyć, jak to zmniejsza komunikację między serwerem klienta a serwerem GA.

Czy ktoś przeprowadził któryś z tych testów? Jeśli tak, czy możesz podać swoje wyniki? Jeśli nie, czy ktoś ma lepszą metodę testowania wydajności (lub jej braku) w używaniu GA?

MN
źródło
4
Dlaczego ludzie oznaczają pytanie jako „ulubione” bez głosowania za nim? Jeśli pytanie zawiera interesujące odpowiedzi, zagłosuj na nie za!
Dan Rosenstark
2
Może po prostu chcą zobaczyć, co ludzie mówią w odpowiedzi, ale nie są do końca zainteresowani tematem (tj.
Myślą
3
Dobrze. Co zasługuje na pochwałę. Głosy za pozytywnymi opiniami nie służą do rozśmieszania pytań. To nie jest YouTube. Głosy za upodobania dotyczą pytań, które wzbogacają naszą wspólną wiedzę techniczną.
Dan Rosenstark
1
Przypuszczam, że różni ludzie mają różne kryteria głosów pozytywnych, w przeciwnym razie każde pytanie miałoby NIEZWYKŁĄ liczbę głosów lub zostało zamknięte.
UnkwnTech
2
Przepisano pytanie, aby wyjaśnić, poprawić strukturę i pozbyć się fragmentów zdań.
George Stocker,

Odpowiedzi:

35

Aktualizacja 2018 : gdzie i jak montujesz Analytics ciągle się zmieniało. Obecny kod gtag.js robi kilka rzeczy:

  1. Załaduj skrypt gtag, ale asynchroniczny (bez blokowania). Oznacza to, że nie spowalnia to Twojej strony w żaden inny sposób niż przepustowość i przetwarzanie.
  2. Utwórz tablicę na stronie o nazwie window.datalayer
  3. Zdefiniuj małą gtag()funkcję, która po prostu wypycha wszystko, co do niej rzucisz, do tej tablicy.
  4. Nazywa to zdarzeniem pageload.

Po załadowaniu głównego skryptu gtag synchronizuje tę tablicę z Google i monitoruje ją pod kątem zmian. To dobry system iw przeciwieństwie do poprzednich systemów (np. Wrzucanie kodu tuż przed </body>nim) oznacza, że ​​możesz wywoływać zdarzenia zanim DOM się wyrenderuje, a kolejność skryptów tak naprawdę nie ma znaczenia, o ile zdefiniujesz ją jako gtag()pierwszą.

Nie oznacza to, że nie ma tu narzutu wydajności. Nadal używamy przepustowości podczas ładowania skryptu (jest buforowany lokalnie przez 15 minut) i nie jest to mały stos skryptów, które rzucają na ciebie, więc jest trochę czasu procesora na jego przetwarzanie.

Ale to wszystko jest nieistotne w porównaniu z (np.) Nowoczesnymi frameworkami frontendowymi.

Jeśli wybierasz absolutną, najbardziej okrojoną stronę internetową, unikaj jej całkowicie. Jeśli próbujesz chronić prywatność swoich użytkowników, nie używaj żadnych skryptów stron trzecich ... Ale jeśli mówimy o przeciętnej nowoczesnej stronie internetowej, jest znacznie mniej wiszących owoców niż gtag.js, jeśli jesteś uderzanie w problemy z wydajnością.

Oli
źródło
3
Google może mieć lepsze serwery, ale nie dostarczają spakowanego pliku, jeśli to możliwe; 22k nie jest dużym plikiem, jest wystarczająco duży, aby skorzystać z gzipowania, szczególnie jest to zwykły tekst (zmniejsza go do 10 KB na moim serwerze).
Ross
6
Nie wiem, czy 2 lata temu nie były gzipowane, ale tak jest teraz i zmniejsza to rozmiar pliku z 30,92 KB do 12,63 KB w chwili pisania tego tekstu.
Yahel,
2
Tak źle: plik GA jest oznaczony jako brak pamięci podręcznej. Nikt go nie zapisał w pamięci podręcznej.
tacone
1
Cieszę się, że mogę znaleźć tak prostą odpowiedź, ale to jest z 2009 roku. Nie mówię, że „stare znaczy złe”, tylko się zastanawiam: czy coś się zmieniło w ostatnich latach?
Lazar Ljubenović
1
Zaktualizowano dla najnowszego skryptu. @tacone Twój komentarz powstał kilka lat po mojej oryginalnej odpowiedzi. Prosty fakt jest taki, że Google wielokrotnie zmieniało sposób działania tego wszystkiego w ciągu ostatniej dekady. Obecna pamięć podręczna to 900s.
Oli
11

Jest kilka świetnych slajdów autorstwa Steve'a Soudersa (eksperta ds. Wydajności po stronie klienta) na temat:

  • Różne techniki równoległego ładowania zewnętrznych plików JavaScript
  • ich wpływ na czas ładowania i renderowanie strony
  • jakiego rodzaju wskaźniki „w toku” wyświetla przeglądarka (np. „ładowanie” na pasku stanu, kursor myszy w kształcie klepsydry).
orip
źródło
dziękuję za odniesienie do slajdów Soudersa, doskonałe informacje na nich zawarte.
Sabuncu
7

Nie wykonałem żadnych wymyślnych automatycznych testów ani programowego obliczania liczb, ale używając starego dobrego Firefoksa z wtyczką Firebug i parą zmiennych JS do określenia różnicy czasu przed i po wykonaniu całego kodu GA, oto co znalazłem.

Pobierane są dwie rzeczy:

  1. ga.js to plik JavaScript zawierający kod. To jest 9kb, więc początkowe pobieranie jest pomijalne, a nazwa pliku nie jest dynamiczna, więc jest buforowana po pierwszym żądaniu.

  2. 35-bajtowy plik gif z dynamicznym adresem URL (za pośrednictwem argumentów w postaci ciągu zapytania), więc jest to wymagane za każdym razem. 35 bajtów to również pomijalne pobieranie (firebug twierdzi, że dl zajęło mi 70 ms).

Jeśli chodzi o czas wykonania, moje pierwsze żądanie z czystą pamięcią podręczną przeglądarki trwało średnio około 330 ms za każdym razem, a kolejne żądania miały długość od 35 do 130 ms.

Bogaty
źródło
Kiedy mówisz, że zajęło to 70 ms, czy masz na myśli, że dodało to 70 ms do czasu, jaki upłynął między kliknięciem łącza przez przeglądającego a wyświetleniem strony? Jeśli tak jest, to 70 ms jest bardzo znaczące z tego, co przeczytałem. Czytałem, że wszystko poniżej 100 ms jest postrzegane jako natychmiastowe. Więc jeśli 70 ms zostało zużyte, pozostało tylko 30 ms na wykonanie wszystkich innych rzeczy, zanim skończy się zauważalne opóźnienie. Wcale nie jestem pewien, czy to, co powiedziałem, ma sens, bo nie rozumiem tematu zbyt dobrze, ale przynajmniej powierzchownie wydaje się to logiczne.
user3425506
5

Z własnego doświadczenia wynika, że ​​dodanie Google-Analytics nie zmieniło czasów ładowania.

Według FireBug ładuje się w mniej niż sekundę (średnio 648MS), a więc niektóre z moich innych testów ~ 60% - 80% tego czasu dotyczyło przesyłania danych z serwera, co oczywiście będzie się różnić w zależności od użytkownika.

Nie wydaje mi się, aby lokalne buforowanie kodu analitycznego znacznie zmieniło czas ładowania z powyższych powodów.

Korzystam z Google-Analytics na ponad 40 witrynach internetowych i nigdy nie spowodowało to żadnego, nawet niewielkiego spowolnienia, najwięcej czasu spędzam na uzyskiwaniu obrazów, które ze względu na ich typowe rozmiary są zrozumiałe.

UnkwnTech
źródło
5

Możesz hostować ga.js na swoich serwerach bez żadnych problemów, ale pomysł jest taki, że twoi użytkownicy będą mieć buforowany plik ga.js z innej witryny, którą mogli odwiedzić. Pobieranie kodu ga.js, ponieważ jest tak popularne, w wielu przypadkach powoduje bardzo niewielkie obciążenie (tj. Zostało już zapisane w pamięci podręcznej).

Ponadto wyszukiwania DNS nie kosztują tyle samo w różnych miejscach ze względu na topologię sieci. Zachowanie pamięci podręcznej zmienia się w zależności od tego, czy użytkownicy korzystają z innych witryn, które zawierają kod ga.js, czy nie.

Po załadowaniu javascript ga.js komunikuje się z serwerami Google, ale jest to proces asynchroniczny.

Mam nadzieję że to pomoże.

Dan Rosenstark
źródło
3

Po stronie serwera nie ma / minimalne obciążenie witryny.

Kod HTML dla Google Analytics to trzy wiersze kodu JavaScript, które umieszczasz u dołu strony. To nic takiego i nie zużywa więcej zasobów serwera niż informacja o prawach autorskich.

Po stronie klienta zakończenie wyświetlania strony może zająć trochę (do kilku sekund) czasu. Jednak - z mojego doświadczenia wynika, że ​​jedyny fragment strony, który nie został załadowany, to rzeczy Google, więc użytkownicy mogą doskonale widzieć Twoją stronę. Po prostu pulsujący u góry strony pulsuje trochę dłużej.

(Uwaga: aby tak się stało, musisz umieścić blok kodu Google Analytics u dołu każdej obsługiwanej strony. Nie wiem, co się stanie, jeśli blok kodu zostanie umieszczony na górze kodu HTML)

seanyboy
źródło
3

Te tradycyjne instrukcje od Google, w jaki sposób to ga.jswykorzystanie document.write(). Tak więc, nawet jeśli przeglądarka w jakiś sposób asynchronicznie ładuje zewnętrzne biblioteki JavaScript, dopóki jakiś kod nie zostanie faktycznie wykonany, document.write()nadal będzie blokować ładowanie strony. Późniejsze instrukcje asynchroniczne nie używają document.write()bezpośrednio, ale może insertBeforerównież blokują ładowanie strony?

Jednak Google ustala, pamięć podręczna użytkownika max-agedo 86,400 sekund (wynosi 1 dzień, a nawet ustawić jako publiczny , więc zastosowanie również do serwerów proxy). Tak więc, ponieważ wiele witryn ładuje ten sam skrypt Google, kod JavaScript jest często pobierany z pamięci podręcznej. Mimo to, nawet gdy ga.jsjest w pamięci podręcznej, po prostu kliknięcie przycisku ponownego ładowania często powoduje, że przeglądarka pyta Google o jakiekolwiek zmiany . A potem, tak jak wtedy, gdy ga.jsnie było jeszcze w pamięci podręcznej, przeglądarka musi poczekać na odpowiedź przed kontynuowaniem:

POBIERZ /ga.js HTTP / 1.1  
Host: www.google-analytics.com  
...  
Jeśli zmodyfikowano od: pon., 22 czerwca 2009 r., 20:00:33 GMT  
Cache-Control: max-age = 0  

HTTP / 1.x 304 nie zmodyfikowano  
Ostatnia modyfikacja: pon., 22 czerwca 2009 r., 20:00:33 GMT  
Data: niedziela, 26 lipca 2009, 12:08:27 GMT  
Cache-Control: max-age = 604800, public  
Serwer: Golfe  

Zwróć uwagę, że wielu użytkowników klika wczytaj ponownie w celu wyświetlenia witryn z wiadomościami, forów i blogów, które już otworzyli w oknie przeglądarki, przez co wiele przeglądarek blokuje się do czasu otrzymania odpowiedzi od Google . Jak często ponownie ładujesz stronę główną SO? Gdy odpowiedź Google Analytics jest powolna, tacy użytkownicy od razu to zauważą. (W sieci opublikowanych jest wiele rozwiązań asynchronicznego ładowania ga.jsskryptu, co jest szczególnie przydatne w tego typu witrynach, ale może nie jest już lepsze niż zaktualizowane instrukcje Google).

Po załadowaniu i wykonaniu kodu JavaScript faktyczne ładowanie błędu internetowego (obrazu śledzącego) powinno być asynchroniczne. Tak więc ładowanie obrazu śledzenia nie powinno blokować niczego innego, chyba że strona używabody.onload() . W takim przypadku, jeśli błąd sieciowy nie załaduje się szybko, kliknięcie przeładuj faktycznie pogarsza sprawę, ponieważ kliknięcie przeładuj spowoduje również, że przeglądarka ponownie zażąda skryptu, zgodnie z If-Modified-Sincepowyższym opisem. Przed przeładowaniem przeglądarka tylko czekała na błąd sieciowy, natomiast po kliknięciu przeładuj również potrzebuje odpowiedzi dla ga.jsskryptu.

Dlatego witryny korzystające z Google Analytics nie powinny używaćbody.onload() . Zamiast tego należy użyć czegoś takiego jak $ (document) .ready () z jQuery lub zdarzenie domready MooTools .

Zobacz także Omówienie funkcji Google , wyjaśniające, w jaki sposób Google Analytics zbiera dane? , w tym jak działa kod śledzenia . (Oznacza to również, że Google zbiera zawartość własnych plików cookie, czyli plików cookie z odwiedzanej witryny).


Aktualizacja: w grudniu 2009 firma Google wydała wersję asynchroniczną . Powyższe powinno nakazywać wszystkim aktualizację dla pewności, chociaż aktualizacja nie rozwiązuje wszystkiego .

Arjan
źródło
3

To naprawdę zależy od dnia. Właśnie dodam to do bloga. Jestem w Kalifornii, bardzo blisko ich głównych centrów danych, na szybkim biznesowym DSL o niskich opóźnieniach, na przetaktowanym i5 z dużą ilością pamięci RAM, na którym działa najnowsze jądro Linux i stabilny Firefox.

oto przykładowe ładowanie strony: wprowadź opis obrazu tutaj

Samo Google Analytics dodało 5 sekund tylko czasu pobierania sieciowego ... aby uzyskać 15Kb!

Można zobaczyć blogger.com serwowane 34KB w 300 mili sekund. To 32x szybciej!

Zobacz także, jak czerwona linia (która reprezentuje zdarzenie onLoad, co oznacza, że ​​na stronie nie wykonuje się już skryptu, a przeglądarka może w końcu zatrzymać wskaźniki ładowania / obroty / itp.) ... spójrz, jak daleko w prawo jest. to prawdopodobnie 3 sekundy przetwarzania javascript śmieci, które miały tam miejsce. Bardzo rzadko zdarza się, że ta linia znajduje się bardzo daleko od końca pasków pobierania zasobów. Skończyłem debugować to i jest to błąd analizy 1/3, błąd blogera 2/3. ... można by pomyśleć, że rzeczy w Google są szybkie.

Edytować:

Trochę więcej danych. Oto żądanie ze wszystkim w pamięci podręcznej. powyższa była pierwsza wizyta.

Usunąłem bzdury googleplus z góry z dwóch powodów, próbowałem sprawdzić, czy odgrywają jakąś rolę w zdarzeniu slow onLoad (nie są) i ponieważ jest w większości bezużyteczny.

wprowadź opis obrazu tutaj

Dzięki temu możemy zobaczyć, że czas sieci jest najmniejszym z Twoich zmartwień. Nawet na szybkim komputerze z nowoczesnym oprogramowaniem, płatny czas przetwarzania Google Analytics + Blogger będzie nadal zrzucał ładowanie strony po 7 sekundach. Bez blogera, po prostu sprawdź tę stronę, widzę 0,5 sekundy opóźnienia po załadowaniu zasobów i uruchomieniu czerwonej linii.

gcb
źródło
2

Załadowanie dodatkowego javascript na twoją stronę wydłuży czas pobierania z punktu widzenia klienta. Możesz to poprawić, ładując go na dole strony, aby strona była renderowana, nawet jeśli GA nie jest załadowana. Unikałbym buforowania, ponieważ straciłbyś przewagę pamięci podręcznej klienta dla swojej strony. Jeśli klient zapisał ją w pamięci podręcznej z innej strony, żądanie Twojej strony zostanie wypełnione przez samego klienta. Jeśli zmienisz go, aby ładował się ze swojej witryny, będzie to wymagało pobrania, nawet jeśli klient ma już kod (co jest prawdopodobne). Dodanie zadania do procesów oprogramowania w celu uniknięcia ładowania pliku z Google wydaje się nieuzasadnione ze względu na to, co może być niepotrzebną optymalizacją. Trudno byłoby to przetestować, ponieważ zawsze działałoby szybciej lokalnie, ale najważniejsze jest to, jak szybko działa dla Twoich klientów.

tvanfosson
źródło
2

Skorzystaj z FireBug i YSlow, aby sprawdzić samodzielnie. Odkryjesz jednak, że GA ma rozmiar około 9 KB (co właściwie jest dość znaczące w stosunku do tego, co robi) i że czasami NIE ładuje się bardzo szybko (z jakich powodów nie wiem, myślę, że może to być serwery czasami się dławią)

Mamy usunięto go ze względu na problemy z wydajnością na naszych próbek Ajax , ale potem znowu dla nas jest bardzo szybki i czuły był priorytet 1, 2 i 3

Thomas Hansen
źródło
Thomas, czy masz jakieś liczby co do ulepszeń uzyskanych po usunięciu kodu GA. Jeśli chodzi o czasy odpowiedzi, w% wieku lub same wartości?
MN
Uwielbiam to, że wszyscy są tacy sprytni (łącznie ze mną), ale empiria sytuacji jest RÓŻNA (czyż nie zawsze?). Dzięki za naszą odpowiedź, fascynująca.
Dan Rosenstark
1

Nic zauważalnego.

Wywołanie do Google (łącznie z wyszukiwaniem DNS, ładowaniem kodu JavaScript, jeśli nie jest jeszcze zapisane w pamięci podręcznej, oraz same wywołania śledzące) powinno być wykonywane przez przeglądarkę klienta w osobnym wątku, aby faktycznie załadować Twoją stronę. Z pewnością wyszukiwanie DNS zostanie wykonane przez system bazowy i, według mojej wiedzy, nie będzie liczyło się jako wyszukiwanie w przeglądarce (przeglądarki mają ograniczenie liczby wątków żądań, z których będą korzystać na witrynę).

Poza tym przeglądarka załaduje skrypt Google równolegle wraz ze wszystkimi innymi osadzonymi zasobami, więc potencjalnie uzyskasz bardzo niewielki wzrost czasu potrzebnego do pobrania wszystkiego, w najgorszym przypadku (mówimy w kolejności milisekund, niezauważalne. Jeśli skrypt Google jest ładowany jako ostatni przez przeglądarkę lub nie masz wielu zasobów zewnętrznych na stronie lub jeśli zewnętrzne zasoby strony są buforowane przez przeglądarkę lub jeśli skrypt Google jest przechowywany w pamięci podręcznej przeglądarki ( bardzo prawdopodobne), wtedy nie zobaczysz żadnej różnicy. Jest to po prostu absolutnie trywialne, taki sam efekt, jak umieszczenie dodatkowego małego obrazka na swojej stronie, z grubsza mówiąc.

Jedynym przypadkiem, w którym może to mieć konkretną różnicę, jest zachowanie, które uruchamia się w zdarzeniu onLoad (które czeka na załadowanie zasobów zewnętrznych) i serwery Google działają wolno / wolno. To drugie raczej nie zdarza się często, ale gdyby tak było, to onLoad nawet nie zostanie uruchomiony, dopóki skrypt nie zostanie pobrany. I tak możesz obejść ten problem, używając różnych zdarzeń „po załadowaniu DOM”, które są generalnie bardziej responsywne, ponieważ nie musisz też czekać na załadowanie w ten sposób własnych skryptów / obrazów.

Jeśli naprawdę martwisz się wpływem na czas ładowania strony, zajrzyj do sekcji „Szybkość sieci” w programie Firebug , która obliczy to i narysuje ładny wykres. Mimo wszystko zachęcałbym Cię do zrobienia tego dla siebie, ponieważ nawet jeśli inne osoby podadzą Ci liczby i testy, o które prosisz, będzie to zupełnie inne dla Twojej witryny.

Andrzej Doyle
źródło
1
Czy na pewno „przeglądarka załaduje skrypt Google równolegle wraz ze wszystkimi innymi osadzonymi zasobami”? Spróbował tego?
Arne Evertsson
1
Renderowanie strony zatrzymuje się po wykryciu tagu <script>, nic nie jest wykonywane równolegle, na przykład spróbuj czegoś takiego: <script> while(true){}</script> <p> <img src = "/ picture.jpg" / > </p> i zobacz, czy zdjęcie pokazuje się po wyczyszczeniu pamięci podręcznej
Jake McGraw,
1

Cóż, szukałem, badałem i obszernie analizowałem w sieci. Ale nie znalazłem żadnych danych statystycznych, które przemawiałyby za lub przeciw temu założeniu.

Jednak ten fragment z http://www.ga-experts.com twierdzi, że to mit, że GA spowalnia twoją witrynę.

No dobrze, może trochę, ale mówimy o milisekundach. GA działa na zasadzie tagowania stron i za każdym razem, gdy dodasz więcej treści do strony internetowej, wydłuży to czas ładowania. Jeśli jednak zastosujesz się do sprawdzonych metod (dodawanie tagu przed </body>tagiem), Twoja strona zostanie załadowana jako pierwsza. Należy również pamiętać, że każdy pakiet do analizy sieciowej oparty na tagach strony (który stanowi większość) będzie działał w ten sam sposób

Na podstawie powyższych odpowiedzi i wszystkich innych źródeł wydaje mi się, że jakiekolwiek spowolnienie, które powoduje, nie jest postrzegane przez użytkownika, ponieważ Skrypt znajduje się na dole strony. Ale jeśli mówimy o całkowitym wczytywaniu strony, możemy powiedzieć, że spowalnia to czas ładowania strony.

Napisz więcej informacji, jeśli masz i DANE, jeśli je masz.

MN
źródło
1
To trochę dziwne, że artykuły takie jak powyższy często testują tylko wtedy, gdy serwery Google Analytics działają poprawnie. Sprawy mogą być bardziej kłopotliwe, gdy te serwery są mocno obciążone. A jeśli serwery mają problemy, wiele przeładowań niecierpliwych użytkowników może jeszcze pogorszyć sytuację.
Arjan
0

Nie sądzę, że tego właśnie szukasz, ale o co martwisz się wydajnością?

Jeśli jest to Twój serwer ... to oczywiście nie ma wpływu, ponieważ znajduje się na serwerach Google.

Jeśli martwisz się o swoich użytkowników, również nie ma to wpływu. Dopóki umieścisz go tuż nad tagiem body, użytkownicy nie będą otrzymywać niczego wolniej niż wcześniej ... skrypt jest ładowany jako ostatni i nie ma wpływu na wygląd dla użytkownika. Więc zasadniczo nie czekam na nic, a nawet kontynuuje przeglądanie strony, nie zauważając, że nadal się ładuje.

youdontmean much
źródło
0

Pytanie brzmiało, czy Google Analytics spowolni Twoją witrynę, a odpowiedź brzmi tak. W tej chwili w chwili pisania tego artykułu Google-Analytics.com nie działa, więc witryny, które mają to na swoich stronach, nie ładują stron, więc tak, może to spowolnić i spowodować, że Twoja witryna nawet się nie ładuje. Rzadko zdarza się, że witryna google-analytics.com nie działa tak długo, bo obecnie wynosi ponad 10 minut, ale to tylko pokazuje, że jest to możliwe.

Rozwiązania randkowe
źródło
0

Ma to dwa aspekty.

  1. Pobieranie skryptu Analytics (i pliku GIF)
  2. Wykonywanie pobranych skryptów

Czas pobierania jest prawie zawsze krótszy niż 100 ms, co jest akceptowalne.

Nadchodzi zwrot akcji.

  1. Wykonanie analytics.js 250 ms
  2. re-marketing (jeśli jest włączony) 300 ms
  3. demograficzne (jeśli włączone) 200ms

Tak więc analiza z re-marketingiem zajmuje średnio 750 ms. Czuję, że jest to ogromna liczba, jeśli chodzi o narzuty wydajnościowe.

Joseph Kulandai
źródło
-2

Zauważyłem częste przeciążenie we / wy i procesora w cPanel skutkujące:

Błąd niedostępności witryny

I to ustało po wyłączeniu wtyczki WP Analytics. Więc myślę, że ma to jakiś wpływ.

user11952079
źródło