Szybkość witryny śledzenia dzięki Google Analytics dla UX i SEO

1. Dlaczego Google Analycis do testowania / śledzenia prędkości witryny?
2. Czy zbierasz wystarczającą ilość danych?
3. Obowiązkowe segmenty danych prędkości witryny
4. Metryki i wymiary prędkości witryny oraz sposób poprawy czasu ładowania strony

Biorąc pod uwagę, że szybkość witryny jest bezpośrednim czynnikiem dla stron docelowych AdWords, głównym czynnikiem wpływającym na optymalizację Usability / UX / Conversion Rate oraz bezpośredni lub niecelowy (nie sądzę, że istnieje konsensus co do tego) w SEO, nic dziwnego, że wielu obecnie specjaliści zwracają szczególną uwagę na czasy ładowania stron.

Dlaczego Google Analycis do testowania / śledzenia prędkości witryny?

Uważam, że raporty dotyczące szybkości witryny w Google Analytics dotyczą najbardziej niedocenianego raportu, jaki istnieje. Wiele osób tak naprawdę nie chodzi i nie ogranicza się do narzędzi takich jak PingDom, WebPageTest.org, WebSiteTest.com, PageScoring lub innych podobnych narzędzi, a nawet gorzej - ogranicza się tylko do lokalnych narzędzi testujących, takich jak YSlow i wtyczka Chrome PageSpeed. Chociaż są to z pewnością świetne narzędzia , mają swoje ograniczenia. Jedną z nich jest fakt, że nie są one dobrym przybliżeniem dla przeciętnego użytkownika.

Google Analytics rozwiązuje to za Ciebie. Zbiera dane od rzeczywistych użytkowników, którzy są w pewien sposób zainteresowani Twoją witryną. W ten sposób gromadzi dane z rzeczywistych maszyn (komputer stacjonarny, tablet, laptop, telefon komórkowy itp.) Pod rzeczywistym obciążeniem, na rzeczywistych połączeniach internetowych (różniących się przepustowością i wydajnością) oraz rzeczywistych ludzi siedzących za nimi, na które wpływ ma szybkość ładowania witryny ( odzwierciedlenie w odbiciach, czasie na stronie, stronach / odwiedzinach itp.). Żadne z wyżej wymienionych narzędzi nie zbliża się do tego poziomu analizy. Mówię tylko, że tylko Google Analytics lub podobne narzędzie może dostarczyć taki zrzut ekranu:

Szybkość witryny i korelacja współczynnika odrzuceń

Czy zbierasz wystarczającą ilość danych?

Kiedy po raz pierwszy przyjrzysz się raportowi prędkości Twojej witryny, możesz być trochę przerażony. Częściowo wynika to z niestosowania obowiązkowych segmentów, które wkrótce dotknę, ale w większości przypadków problem jest spowodowany domyślnym ustawieniem Google Analytics, które gromadzi tylko dane prędkości ładowania stron dla około 1% (tak, jeden procent) użytkowników . Oznacza to, że jeśli masz średnio 1000 użytkowników dziennie, tylko 10 (tak, to „dziesięć”) z nich prześle dane ładowania stron do GA. Potrzebujesz tylko jednego użytkownika z wolniejszym połączeniem, przeglądarką lub czymkolwiek, aby przesunąć średni czas ładowania o kilka sekund.

Aby rozwiązać ten problem, jeśli używasz Universal Analytics , musisz ustawić wartość zmiennej „setSiteSpeedSample”. Jeśli korzystasz z naszego zestawu narzędzi, możesz to łatwo zrobić za pomocą nasz Kreator kodu Analytics . Jeśli nie, oto jeden sposób, aby to osiągnąć. Zmodyfikuj wywołanie ga ('create'), tak aby zawierało zmienną siteSpeedSampleRate:

ga ('create', 'UA-XXXX-Y', {'cookieDomain': 'domain.com', 'siteSpeedSampleRate': 100});

Powyższy kod dotyczy Universal Analytics (biblioteka analytics.js). Jeśli nadal używasz biblioteki asynchronicznej ga.js, musisz dodać następujący wiersz po zainicjowaniu śledzenia i przed wywołaniem _trackPageview:

_gaq.push (['_ setSiteSpeedSampleRate', 100]);

Ustawienie parametru siteSpeedSampleRate na 100 instruowałoby Google Analytics, aby spróbowało zebrać dane dotyczące szybkości stron od każdego użytkownika witryny. Możesz użyć bardziej konserwatywnej wartości, jeśli Twoja witryna codziennie zawiera miliony wywołań GA (odsłon, wydarzeń, zdarzeń czasowych itp.) I obawiasz się, że osiągną swoje wolne kwoty na koncie. Zapewnia to uzyskanie wystarczającej ilości danych do właściwej analizy. W ten sposób zajęłoby to znacznie mniej czasu między pracami nad optymalizacją szybkości witryny a potwierdzeniem wyników.

Nawet jeśli to zrobisz, nie otrzymasz danych o prędkości witryny dla wszystkich użytkowników. To jest ponieważ:

Szybkość witryny można śledzić tylko z przeglądarek obsługujących interfejs czasowy nawigacji HTML5 lub z zainstalowanego paska narzędzi Google Toolbar. Zazwyczaj obejmuje to: Chrome, Firefox 7 i nowsze wersje, Internet Explorer 9 i nowsze wersje, przeglądarkę Android 4.0 i wyższe, a także wcześniejsze wersje Internet Explorera z zainstalowanym Google Toolbar. (cytat z plików pomocy Google)

Jednak w momencie pisania tego artykułu wiele przeglądarek obsługuje interfejs czasowy nawigacji, co oznacza, że ​​w większości przypadków gromadzone są wystarczające dane.

Obowiązkowe segmenty danych prędkości witryny

Po zebraniu co najmniej tygodnia danych prędkości witryny, nadszedł czas na analizę! Nadal możesz być zszokowany tym, jak powolna jest Twoja witryna. Nie obawiaj się jednak, ponieważ wyjaśnienie może być bardziej trywialne niż przypuszczasz.

Przeglądając raporty prędkości witryny w Google Analytics, należy zawsze segmentować najpierw według kraju, a następnie według typu urządzenia (lub obu). Te dwa mają największy wpływ na średnie wartości, które widzisz.

Oto przykład danych podzielonych według typu urządzenia :

Szybkość witryny na różnych typach urządzeń

Różnice są bardzo znaczące i wydają się być obecne w większości stron, z którymi pracowałem. Częściowym powodem jest moc przetwarzania urządzenia, inna część polega na tym, że różne typy urządzeń zwykle różnią się typem używanego połączenia internetowego. We wszystkich przypadkach liczby są na tyle różne w 99% przypadków, że mogę powiedzieć, że obowiązkowe jest wyświetlanie ich w oddzielnych wiadrach przez cały czas.

A oto podział według krajów :

Szybkość witryny według kraju

Powyższe dane pochodzą z amerykańskiej witryny zorientowanej na technologię z rynkiem pierwotnym w USA i nieco w Europie. Jak widzisz, jeśli szukałeś tylko na łączną wartość 7:80, możesz dojść do wniosku, że prawdopodobnie jest problem ze stroną lub serwerem. Jednak w przypadku podziału na kraje wyraźnie widać, że na głównym rynku w USA strona jest dość żwawa, a dla Europy jest OK. To Indie i inne kraje o prawdopodobnie powolnych interentach, starych komputerach PC lub innych problemach, które ściągają metrykę, ale i tak nas to nie obchodzi (w tym konkretnym przypadku).

W niektórych przypadkach wskazane jest zbadanie wydajności przez dostawcę usług internetowych . Zwłaszcza w dużych krajach z wieloma dostawcami mogą występować znaczne różnice w wartościach szybkości stron między nimi, a jeśli ważny dostawca pozostaje w tyle, możesz rozważyć użycie centrum danych, które ma lepszą łączność z nim lub skonfigurowanie serwerów lustrzanych do obsługi ci dostawcy usług internetowych są bliżej swoich użytkowników końcowych.

Metryki i wymiary prędkości witryny oraz sposób poprawy czasu ładowania strony

Aby zrozumieć metryki, musisz mieć ogólne pojęcie o specyfikacji czasu nawigacji HTML5. Jeśli tego nie zrobisz, skorzystaj z Google i poświęć trochę czasu na studiowanie. Oto ważniejsze dane i moje krótkie zalecenia dotyczące tego, co możesz zrobić, jeśli wartość jest wysoka, a czas ładowania strony jest zły:

• Strona Load Sample: Liczba odsłon strony, które zostały pobrane w celu obliczenia średniego czasu ładowania strony. Upewnij się, że opierasz swoje decyzje na wystarczająco dużej próbce ładowania strony.
• Średni czas ładowania strony: średni czas (w sekundach) ładowania strony, od rozpoczęcia odsłon strony (np. Kliknięcie łącza strony), aby załadować zakończenie w przeglądarce. Jest to kombinacja / suma wszystkich innych wskaźników.
• Śr. Czas odpowiedzi serwera: czas na odpowiedź serwera na żądanie użytkownika, w tym czas sieciowy od lokalizacji użytkownika do serwera. Jeśli osiągasz słabe wyniki, spróbuj skrócić czas przetwarzania zaplecza (zoptymalizuj skrypty i zapytania SQL, zastosuj buforowanie) lub umieść serwer bliżej użytkowników.
• Śr. Czas pobierania strony: czas pobrania strony. Jeśli masz opóźnienia w tym obszarze, spróbuj zmniejszyć początkowy rozmiar danych (html). Zacznij od kompresji, minifikacji, usuwania inline CSS i JS, chyba że jest to całkowicie konieczne.
• Śr. Czas interaktywny dokumentu: Średni czas (w sekundach), jaki przeglądarka potrzebuje do przeanalizowania dokumentu (DOMInteractive), w tym czas sieciowy od lokalizacji użytkownika do serwera. W tym momencie użytkownik może współdziałać z modelem obiektu dokumentu, nawet jeśli nie jest w pełni załadowany.
• Śr. Czas załadowania treści dokumentu: Średni czas (w sekundach), jaki przeglądarka potrzebuje do przeanalizowania dokumentu i wykonania skryptów odroczonych i wstawionych do analizatora składni (DOMContentLoaded), w tym czasu sieciowego od lokalizacji użytkownika do serwera. Przetwarzanie dokumentu jest zakończone, model obiektu dokumentu jest gotowy, ale odnośne arkusze stylów, obrazy i podramki mogą nie zostać załadowane. To zdarzenie jest często punktem wyjścia dla wykonywania szkieletu javascript, np. Wywołania zwrotnego JQuery onready () itp.

To narzędzie jest naprawdę pomocny w radzeniu sobie z najpoważniejszymi problemami z ostatnich dwóch metryk. Istnieje jeszcze kilka wskaźników, na które prawdopodobnie nigdy nie będziesz musiał patrzeć. Pamiętaj, że jeśli weźmiesz pod uwagę obszary, w których chcesz zwiększyć prędkość, zawsze powinieneś najpierw wybrać najwolniejsze metryki prędkości (te o dużych wartościach czasów ładowania).

Pamiętaj, aby podzielić dane według stron. Może się okazać, że tylko kilka stron zachowuje się źle, a reszta to mistrzowie. Pamiętaj, że średnie często ukrywają prawdziwe spostrzeżenia, więc sprawdź strony lub grupy podobnych stron w poszukiwaniu wzorców czasu wolnego ładowania.

O raporcie szybkości witryny w Google Analytics można powiedzieć więcej, ale uważam, że powyższe jest czymś więcej niż doskonałym początkiem.

Szczęśliwa optymalizacja prędkości witryny!