Відстеження швидкості сайту за допомогою Google Analytics для UX та SEO
- Чому Google Analycis для тестування / відстеження швидкості сайту?
- Ви збираєте достатньо даних?
- Обов'язкові сегменти даних щодо швидкості сайту
- Показники швидкості та розміри сайту та способи покращення часу завантаження сторінки
Враховуючи, що швидкість сайту є прямим фактором для цільових сторінок AdWords, основний фактор оптимізації зручності використання / UX / коефіцієнту переходів, а також прямого або непрямого (я не думаю, що є консенсус щодо цього) фактору в SEO, не дивно фахівці нині приділяють пильну увагу часу завантаження сторінки.
Чому Google Analycis для тестування / відстеження швидкості сайту?
Я вважаю, що звіти щодо швидкості сайту в Google Analytics стосуються найбільш недооціненого звіту. Багато людей дійсно не йдуть туди і не обмежуються лише інструментами, такими як PingDom, WebPageTest.org, WebSiteTest.com, PageScoring або деякими подібними інструментами, або навіть гірше - обмежуються лише засобами локальної тестування, такими як YSlow і Chrome PageSpeed плагін. Хоча це, звичайно, чудові інструменти , вони мають свої обмеження. Це те, що всі вони поділяють той факт, що вони не є гарним наближенням для вашого середнього користувача.
Google Analytics вирішує це для вас. Він збирає дані від фактичних користувачів, які дійсно цікавляться вашим сайтом. Таким чином, він збирає дані з реальних машин (настільні, планшетні, ноутбуки, мобільні пристрої тощо) під фактичним навантаженням, на фактичні підключення до Інтернету (різної пропускної здатності та продуктивності), а фактичні люди, що сидять за ними, перебувають під впливом швидкості завантаження вашого сайту ( відображається у відскоку, час на сайті, сторінках / відвідування тощо). Жоден з вищезазначених інструментів не наближається до такого рівня аналізу. Я хочу сказати, що лише такі дані Google Analytics або подібний інструмент можуть надати вам такий знімок екрана:
Швидкість сайту та співвідношення коефіцієнтів відмов
Ви збираєте достатньо даних?
Коли ви вперше подивитеся на звіт про швидкість вашого сайту, ви можете трохи злякатися. Частина цього пояснюється невикористанням обов'язкових сегментів, про які я коротко розповім, але в більшості випадків проблема, викликана налаштуванням за умовчанням Google Analytics, яка збирає дані про швидкість завантаження лише приблизно 1% (так, один відсоток) користувачів . Це означає, що якщо у вас є 1000 користувачів на день в середньому, тільки 10 (так, це "десять") з них будуть відправляти дані про завантаження даних на GA. Вам потрібен лише один користувач з більш повільним з'єднанням, браузер або будь-який інший для переміщення середнього часу завантаження на кілька секунд.
Щоб вирішити це, якщо ви використовуєте Універсальна аналітика , потрібно встановити значення змінної швидкості "setSiteSpeedSample". Якщо ви використовуєте наш інструментарій, ви можете легко зробити це за допомогою майстра коду Analytics . Якщо ви цього не зробите, ось один із способів досягти цього. Змініть виклик ga ('create'), щоб включити змінну siteSpeedSampleRate:
ga ('create', 'UA-XXXX-Y', {'cookieDomain': 'domain.com', 'siteSpeedSampleRate': 100});
Вищевказаний код призначено для універсальної аналітики (бібліотека analytics.js). Якщо ви все ще використовуєте бібліотеку async ga.js, вам слід додати наступний рядок після ініціювання трекера і перед викликом _trackPageview:
_gaq.push (['_ setSiteSpeedSampleRate', 100]);
Якщо встановити siteSpeedSampleRate до 100 , програма Google Analytics зможе спробувати зібрати дані швидкості сторінки від кожного відвідувача вашого сайту. Ви можете використовувати більш консервативне значення, якщо ваш сайт має мільйони дзвінків GA (перегляди сторінок, події, події часу тощо) щодня, і ви боїтеся досягти своїх безкоштовних квот облікового запису. Це гарантує, що ви отримаєте достатньо даних для правильного аналізу. Крім того, буде потрібно набагато менше часу між роботою по оптимізації швидкості сайту і підтвердженням результатів таким чином.
Навіть якщо ви зробили це, ви не отримаєте дані про швидкість сайту для всіх ваших користувачів. Це тому, що:
Швидкість сайту можна відстежувати лише з веб-переглядачів, які підтримують інтерфейс HTML5 Navigation Timing або встановлені панель інструментів Google. Як правило, це включає: Chrome, Firefox 7 і вище, Internet Explorer 9 і вище, браузер Android 4.0 і вище, а також попередні версії Internet Explorer з встановленою панеллю інструментів Google. (цитата з файлів довідки Google)
Однак під час написання цієї статті багато браузерів підтримують інтерфейс навігації, що означає, що в більшості випадків збирається достатньо даних.
Обов'язкові сегменти даних щодо швидкості сайту
Після того як ви зібрали принаймні тиждень даних про швидкість сайту, нарешті пора проаналізувати! Ви все ще можете бути вражені тим, наскільки повільним є ваш сайт. Не бійтеся, але пояснення може бути більш тривіальним, ніж ви вважаєте.
Переглядаючи звіти про швидкість сайту в Google Analytics, завжди слід спочатку вибирати сегмент за країною, а потім за типом пристрою (або обох). Ці два мають найбільший вплив на середні значення, які ви бачите.
Ось приклад даних, сегментованих за типом пристрою :
Швидкість сайту на різних типах пристроїв
Відмінності дуже значущі і, як правило, присутні у всьому, з яким я працював. Однією з причин цього є обчислювальна потужність пристрою, інша частина полягає в тому, що різні типи пристроїв зазвичай відрізняються типом підключення до Інтернету, який вони використовують. У всіх випадках цифри в 99% випадків достатньо різні, що дозволяє мені сказати, що обов'язково переглядати їх у окремих ковшах весь час.
А ось розбивка за країнами :
Швидкість сайту за країною
Дані наведені на веб-сайті, що орієнтований на техніку, з первинним ринком у США та дещо в Європі. Як ви бачите, якщо ви шукали лише загальну величину 7:80, ви можете зробити висновок, що існує ймовірність проблеми з веб-сайтом або сервером. Однак, при сегментації по країнах ясно видно, що для основного ринку в США сайт досить швидкий, а для Європи це ОК-іш. Це Індія та інші країни з імовірними повільними інтерентами, старими ПК або іншими проблемами, які тягнуть метрику вниз, але ми не піклуємося про них у будь-якому випадку (у цьому випадку).
У деяких випадках доцільно досліджувати роботу провайдера . Особливо у великих країнах з багатьма провайдерами можуть існувати значні відмінності між значеннями швидкості сторінки, і якщо важливий провайдер відстає, ви можете розглянути можливість використання центру обробки даних, який має краще підключення до нього або налаштовувати дзеркальні сайти. цих провайдерів ближче до кінцевих користувачів.
Показники швидкості та розміри сайту та способи покращення часу завантаження сторінки
Щоб зрозуміти показники, потрібно мати приблизне уявлення про специфікацію Timing Navigation Timing. Якщо ви цього не зробите, використовуйте Google і витрачайте деякий час на його вивчення. Нижче наведено більш важливі показники та мої короткі рекомендації щодо того, що ви можете зробити, якщо значення є високим і зашкоджують час завантаження сторінки:
- Зразок завантаження сторінки: кількість переглядів сторінок, які були відібрані для обчислення середнього часу завантаження сторінки. Переконайтеся, що ви базуєте свої рішення на досить великій вибірці завантаження сторінки.
- Середня тривалість завантаження сторінки: середня тривалість часу (у секундах) завантаження цієї сторінки, починаючи з перегляду сторінки (наприклад, натисніть посилання на сторінку), щоб завантажити її у браузері. Це комбінація / сума всіх інших показників.
- Сер. Час відповіді сервера: час, коли ваш сервер реагує на запит користувача, включаючи мережевий час від місця розташування користувача до вашого сервера. Якщо ви тут неефективні, спробуйте скоротити час обробки бекенда (оптимізуйте сценарії та SQL-запити, використовуйте кешування) або помістіть сервер ближче до користувачів.
- Сер. Час завантаження сторінки : час завантаження сторінки. Якщо ви відстаєте в цій області, спробуйте зменшити початковий розмір даних (html). Почніть із стиснення, зменшення, видалення вбудованого CSS & JS, якщо це не потрібно.
- Сер. Документ Інтерактивний час: середній час (у секундах), який приймає браузер для аналізу документа (DOMInteractive), включаючи час мережі від місця розташування користувача до вашого сервера. У цей час користувач може взаємодіяти з об'єктною моделлю документа, навіть якщо він не повністю завантажений.
- Сер. Час завантаження вмісту документа: середній час (у секундах), який приймає браузер, щоб розібрати документ і виконати відкладені та вставлені сценарії (DOMContentLoaded), включаючи час мережі від місця розташування користувача до вашого сервера. Розбір документа закінчується, об'єктна модель документа готова, але посилання на таблиці стилів, зображення та підкадри можуть не завершитися завантаженням. Ця подія часто є відправною точкою для виконання скрипту JavaScript, наприклад, зворотного виклику onready () JQuery і т.д.
Цей інструмент дійсно корисно у вирішенні найсерйозніших питань з останніми двома показниками. Існує ще кілька показників, на які ви, напевно, ніколи не подивитеся. Пам'ятайте, що коли ви розглядаєте, в яких областях потрібно збільшити швидкість, слід завжди орієнтуватися на найповільніші метрики швидкості (ті з великими значеннями часу завантаження).
Переконайтеся, що дані сегментуються по сторінках. Може виявитися, що лише деякі ваші сторінки ведуть себе погано, а решта - чемпіони. Пам'ятайте, що середні показники часто приховують реальні уявлення, тому розглядайте сторінки або групи подібних сторінок для шаблонів повільних таймінгів завантаження.
Існує ще одне, що можна сказати про звіт про швидкість сайту в Google Analytics, але я вважаю, що це більше, ніж відмінний початок.
Оптимізація швидкості сайту!
Чому Google Analycis для тестування / відстеження швидкості сайту?Ви збираєте достатньо даних?
Чому Google Analycis для тестування / відстеження швидкості сайту?