Czy Google Analytics generuje narzut wydajności?

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?

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ą.

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).

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.

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.

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.

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)

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 .

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:

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.

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.

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.

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

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.

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.

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.

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.

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.

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.