Чи має Google Analytics накладні витрати?


83

Наскільки Google Analytics впливає на ефективність?

Я шукаю наступне:

  • Тести (включаючи час відгуку / час завантаження сторінки та ін.)
  • Посилання або результати на подібні контрольні показники

Один (можливий) метод тестування Google Analytics (GA) на вашому сайті:

  1. Обслуговуйте ga.js (файл JavaScript Google Analytics) із власного сервера.
  2. Оновлення від Google Щодня (тест 1) та Щотижня (тест 2).

Мені було б цікаво побачити, як це зменшує зв'язок між веб-сервером клієнта та сервером GA.

Хтось проводив якісь із цих тестів? Якщо так, чи можете ви надати свої результати? Якщо ні, чи є у когось кращий метод для тестування результативності (або її відсутності) для використання GA?


4
Чому люди позначають запитання як «улюблене», не проголосувавши? Якщо питання дає цікаві відповіді, проголосуйте за питання!
Ден Розенстарк

2
Можливо, вони просто хочуть побачити, що люди говорять у відповідь, але їх не зовсім цікавить тема (тобто вони думають про щось пов’язане)
UnkwnTech

3
Правильно. Що заслуговує на підтримку. Прихильники не стосуються питань, які викликають у вас сміх. Це не YouTube. Голоси - за питання, які збагачують наші спільні технічні знання.
Ден Розенстарк

1
Я припускаю, що різні люди мають різні критерії збільшення голосів, інакше кожне питання мало б ІМЕНІЗНУ кількість голосів або було б закритим.
UnkwnTech

2
Перепишіть запитання, щоб з’ясувати, покращити структуру та позбутися фрагментів речень.
Джордж Стокер

Відповіді:


35

Оновлення 2018 року : Де і як ви монтуєте Analytics, змінювалося знову і знову і знову. Поточний код gtag.js робить кілька речей:

  1. Завантажте скрипт gtag, але асинхронний (не блокуючий). Це означає, що це не сповільнює вашу сторінку будь-яким іншим способом, крім пропускної здатності та обробки.
  2. Створіть масив на сторінці, що називається window.datalayer
  3. Визначте невелику gtag()функцію, яка просто штовхає все те, що ви в неї кидаєте, у цей масив.
  4. Викликає це з подією завантаження сторінки.

Після завантаження основного скрипта gtag він синхронізує цей масив з Google і відстежує зміни. Це хороша система, і на відміну від попередніх систем (наприклад, заповнення коду безпосередньо перед цим </body>), це означає, що ви можете викликати події до відображення DOM, і порядок сценаріїв насправді не має значення, якщо ви визначаєте gtag()спочатку.

Це не означає, що тут немає накладних витрат. Ми все ще використовуємо пропускну здатність для завантаження скрипта (він зберігається у локальному кеші протягом 15 хвилин), і це не мала купа скриптів, які вони вам кидають, тому є трохи часу на обробку процесора.

Але це все незначно порівняно з (наприклад) сучасними фронтенд-фреймворками.

Якщо ви йдете на абсолютний, максимально скорочений веб-сайт, повністю його уникайте. Якщо ви намагаєтеся захистити конфіденційність своїх користувачів, не використовуйте сторонні скрипти ... Але якщо ми говоримо про середньостатистичний сучасний веб-сайт, то набагато нижчі плоди, ніж gtag.js, якщо ви потрапляння проблем з продуктивністю.


3
У Google можуть бути кращі сервери, але вони не доставляють файл заархівований, якщо це можливо; 22k - це не величезний файл, він досить великий, щоб отримати вигоду від gzipping, особливо, якщо це звичайний текст (на моєму сервері його скорочується до 10k).
Росс

6
Я не знаю, чи не робили вони gzipping 2 роки тому, але зараз вони є, і це зменшує розмір файлу з 30,92 тис. До 12,63 тис.
Ягель

2
Так неправильно: файл GA позначено як no-cache. Ні в кого не кешовано.
таконе

1
Я радий знайти таку просту відповідь, але це з 2009 року. Я не кажу, що "старе означає погане", мені просто цікаво: чи щось змінилося за останні роки?
Лазар Любенович

1
Оновлено для останнього сценарію. @tacone Ваш коментар був через кілька років після моєї оригінальної відповіді. Простий факт: протягом останнього десятиліття Google неодноразово змінював принцип роботи всього цього. Поточний кеш становить 900 с.
Олі

11

Є кілька чудових слайдів Стіва Соудерса (експерта з питань роботи з клієнтами) про:

  • Різні методи паралельного завантаження зовнішніх файлів JavaScript
  • їх вплив на час завантаження та візуалізацію сторінки
  • які індикатори "в процесі" відображає браузер (наприклад, "завантаження" у рядку стану, курсор миші з пісочним годинником).

дякую за посилання на слайди Souders, чудову інформацію, що міститься в них.
Сабунку

7

Я не робив жодного вишуканого автоматизованого тестування або програмного зминання чисел, але використовуючи старий добрий Firefox з плагіном Firebug і парою змінних JS, щоб визначити різницю в часі до і після виконання всього коду GA, ось що я знайшов.

Завантажуються дві речі:

  1. ga.js - це файл JavaScript, що містить код. Це 9 кб, тому початкове завантаження незначне, а ім’я файлу не динамічне, тому воно кешоване після першого запиту.

  2. 35-байтовий gif-файл із динамічною URL-адресою (через аргументи рядка запиту), тому про це вимагається кожного разу. 35 байтів - це також незначне завантаження (firebug каже, що мені знадобилося 70 мс, щоб розрядити його).

Що стосується часу виконання, мій перший запит із чистим кешем браузера становив в середньому близько 330 мс кожного разу, а наступні запити були між 35 і 130 мс.


Коли ви говорите, що це зайняло 70 мс, ви маєте на увазі, що це додало 70 мс до часу, який пройшов між переглядачем, натиснувши посилання, і сторінкою, яку вони можуть переглянути? Якщо це так, то 70 мс є дуже значущим з того, що я прочитав. Я читав, що все, що менше 100 мс, сприймається як миттєве. Отже, якщо було використано 70 мс, у вас залишиться лише 30 мс, щоб виконати всі інші речі, перш ніж закінчиться з помітною затримкою. Я зовсім не впевнений, чи має сенс сказане мною, оскільки я не дуже добре розумію тему, але це виглядає логічним, принаймні поверхово.
user3425506

5

З мого власного досвіду, додавання Google-Analytics не змінило час завантаження.

За даними FireBug, він завантажується менше ніж за секунду (в середньому 648 мс), і, відповідно, деякі інші мої тести ~ 60% - 80% того часу передавали дані із сервера, які, звичайно, будуть відрізнятися від користувача до користувача.

Я не думаю, що локальне кешування коду аналітики значно змінить час завантаження з вищевказаних причин.

Я використовую Google-Analytics на більш ніж 40 веб-сайтах, і це ніколи не є причиною будь-якого, навіть невеликого, уповільнення, найбільше часу витрачається на отримання зображень, що через їх типові розміри зрозуміло.


5

Ви можете розмістити ga.js на своїх серверах без будь-яких проблем, але ідея полягає в тому, що ваші користувачі матимуть ga.js кешованим з іншого веб-сайту, який вони, можливо, відвідували. Тож завантаження ga.js, оскільки воно настільки популярне, у багатьох випадках додає дуже мало накладних витрат (тобто воно вже кешоване).

Крім того, пошук DNS не коштує однаково в різних місцях через топологію мережі. Поведінка кешування зміниться залежно від того, чи користувачі використовують інші сайти, що містять ga.js, чи ні.

Після завантаження javascript ga.js взаємодіє із серверами Google, але це асинхронний процес.

Сподіваюся, це допомагає.


3

На стороні сервера немає / мінімальних накладних витрат на сайт.

HTML для Google Analytics - це три рядки JavaScript, які ви розміщуєте внизу веб-сторінки. Це насправді нічого і не споживає більше ресурсів сервера, ніж повідомлення про авторські права.

На клієнтській сторінці сторінка може зайняти трохи часу (до декількох секунд), щоб закінчити показ сторінки. Однак - з мого досвіду, єдиним бітом незавантаженої сторінки є матеріали Google, тому користувачі можуть бачити вашу сторінку чудово. Ви просто отримуєте пульс у верхній частині сторінки, який пульсує трохи довше.

(Примітка: Вам потрібно розмістити свій код коду Google Analytics у нижній частині будь-яких обслуговуваних сторінок, щоб це було так. Я не знаю, що станеться, якщо блок коду розміщений у верхній частині вашого HTML)


3

У традиційних інструкції від Google про те , як включити ga.jsвикористання document.write(). Отже, навіть якщо браузер якось асинхронно завантажує зовнішні бібліотеки JavaScript, доки насправді не буде виконано якийсь код, document.write()він все одно заблокує завантаження сторінки. Пізніші асинхронні інструкції не використовують document.write()безпосередньо, але, можливо, insertBeforeтакож блокують завантаження сторінки?

Однак Google встановлює кеш-пам’яті max-ageна 86 400 секунд (це 1 день і навіть встановлюється як загальнодоступний , що також застосовується до проксі-серверів). Отож, оскільки багато сайтів завантажують той самий сценарій Google, JavaScript часто витягується з кешу. Тим не менше, навіть коли ga.jsкешовано, просто натискання кнопки перезавантаження часто змушує браузер запитувати Google про будь-які зміни . І тоді, як і коли ga.jsще не було кешовано, браузер повинен чекати відповіді, перш ніж продовжувати:

ОТРИМАЙТЕ /ga.js HTTP / 1.1  
Ведучий: www.google-analytics.com  
...  
Якщо модифіковано-з: Понеділок, 22 червня 2009 р. 20:00:33 GMT  
Керування кешем: max-age = 0  

HTTP / 1.x 304 Не змінено  
Останнє оновлення: Mon, 22 Jun 2009 20:00:33 GMT  
Дата: неділя, 26 липня 2009 р. 12:08:27 GMT  
Керування кешем: max-age = 604800, загальнодоступний  
Сервер: Гольф  

Зверніть увагу, що багато користувачів натискають кнопку перезавантажити для новинних сайтів, форумів та блогів, які вони вже відкрили у вікні браузера, змушуючи багатьох браузерів блокувати, поки не отримає відповідь від Google . Як часто ви перезавантажуєте домашню сторінку SO? Коли відповідь Google Analytics повільна, тоді такі користувачі відразу помітять. (У мережі опубліковано багато рішень для асинхронного завантаження ga.jsсценарію, особливо корисних для таких сайтів, але, можливо, вже не кращих, ніж оновлені інструкції Google.)

Після завантаження та виконання JavaScript фактичне завантаження веб-помилки (зображення відстеження) має бути асинхронним. Отже, завантаження зображення для відстеження не повинно блокувати нічого іншого, якщо тільки сторінка не використовуєbody.onload() . У цьому випадку, якщо веб-помилка не вдається завантажити негайно, натискання кнопки перезавантажити насправді погіршує ситуацію, оскільки натискання кнопки перезавантаження також призведе до того, що браузер знову запитає сценарій, як If-Modified-Sinceописано вище. До перезавантаження браузер чекав лише веб-помилки, тоді як після натискання кнопки перезавантаження він також потребує відповіді на ga.jsсценарій.

Отже, сайти, що використовують Google Analytics, не повинні використовуватиbody.onload() . Натомість слід використовувати щось на кшталт події jQuery $ (document) .ready () або domready MooTools .

Див. Також Функціональний огляд Google , який пояснює, як Google Analytics збирає дані? , включаючи те, як працює код відстеження . (Це також робить офіційним, що Google збирає вміст сторонніх файлів cookie. Тобто: файли cookie з веб-сайту, який ви відвідуєте.)


Оновлення: у грудні 2009 року Google випустив асинхронну версію . Вищезазначене повинно сказати всім, щоб оновити, щоб бути впевненим, хоча оновлення не вирішує все .


3

Це дійсно залежить від дня. Я просто додаю це до блогу. Я перебуваю в Каліфорнії, дуже близько до їх основних центрів обробки даних, на швидкому DSL із низьким рівнем затримки, на розігнаному i5 з великою кількістю оперативної пам'яті, на якому працює останнє ядро ​​Linux та стабільний Firefox.

ось зразок завантаження сторінки: введіть тут опис зображення

лише Google-аналітика додала 5 секунд лише часу завантаження мережі ... щоб отримати 15 Кб!

Ви можете побачити, як blogger.com обслуговує 34 Кб за 300 мільйонів секунд. Це в 32 рази швидше!

Крім того, подивіться, як Червона лінія (яка представляє подію onLoad, тобто на сторінці більше не виконується сценарій, а отже браузер може остаточно зупинити показники завантаження / обертання / тощо) ... подивіться, як далеко справа є. це, мабуть, 3 секунди обробки сміття javascript, що там сталося. Дуже рідко трапляється, що цей рядок знаходиться дуже далеко від кінця рядків завантаження ресурсів. Я налагодив це, і це 1/3 помилки аналітики, 2/3 помилки блогера. ... можна подумати, що речі в Google були швидкими.

Редагувати:

Ще трохи даних. Ось запит із усім кешованим. вищевказаний був першим візитом.

Я видалив сміття googleplus згори з двох причин, я намагався зрозуміти, чи вони грали якусь роль у повільній події onLoad (вони не є), і тому, що це в основному марно.

введіть тут опис зображення

Отже, з цього ми можемо бачити, що мережевий час - це найменше з ваших турбот. Навіть на швидкому комп’ютері з сучасним програмним забезпеченням, платний Google Analytics + блогер, який займає час обробки, все одно скине завантаження вашої сторінки за 7 секунд. Без блогера, просто перевірте цей самий сайт, я бачу 0,5 секунди затримки після завантаження ресурсів і появи червоної лінії.


2

Завантаження будь-якого додаткового javascript на вашу сторінку збільшить час завантаження з точки зору клієнта. Ви можете покращити це, завантаживши його внизу сторінки, щоб ваша сторінка відображалася, навіть якщо GA не завантажується. Я б уникнув кешування, оскільки ви втратите перевагу кеш-пам’яті клієнта для вашої сторінки. Якщо клієнт кешує його з іншої сторінки, запит на вашу сторінку буде заповнений самим клієнтом. Якщо ви зміните його для завантаження зі свого сайту, його буде потрібно завантажити, навіть якщо клієнт уже має код (що, ймовірно). Додавання завдання до ваших програмних процесів, щоб уникнути завантаження файлу від Google, здається невиправданим, що може бути непотрібною оптимізацією. Було б важко перевірити це, оскільки воно завжди працювало б швидше на місцевому рівні, але насправді важливо, наскільки швидко це працює для ваших клієнтів.


2

Використовуйте FireBug та YSlow, щоб перевірити самі. Проте ви виявите, що розмір GA становить близько 9 КБ (що насправді є досить значним для того, що він робить), і що він іноді НЕ завантажується дуже швидко (з яких причин я не знаю, я думаю, що це може бути сервери іноді "задихаються"

Ми видалили його через проблеми з продуктивністю в наших зразках Ajax , але знову ж таки для нас бути надшвидкими та чуйними було пріоритетом 1, 2 та 3


Томасе, чи маєш ти цифри щодо того, які покращення ти отримав після видалення коду GA. З точки зору часу відгуку, у% віків чи самих значень?
MN

Мені подобається, як усі такі розумні (і я в тому числі), але емпірична ситуація РІЗНА (чи не завжди?). Дякую за вашу відповідь, захоплююче.
Dan Rosenstark

1

Нічого помітного.

Виклик до Google (включаючи пошук DNS, завантаження Javascript, якщо він ще не кешований, і фактичні виклики трасера) повинен здійснюватися браузером клієнта в окремому потоці для фактичного завантаження вашої сторінки. Звичайно, пошук DNS здійснюватиметься базовою системою, і, наскільки мені відомо, він не буде вважатися пошуком у браузері (браузери мають обмеження на кількість потоків запитів, які вони будуть використовувати для кожного сайту).

Окрім цього, браузер завантажує скрипт Google паралельно разом з усіма іншими вбудованими ресурсами, тож ви потенційно отримаєте надзвичайно незначне збільшення часу, необхідного для завантаження всього, в гіршому випадку (ми говоримо в порядку мілісекунд, непомітно. Якщо сценарій Google завантажується браузером останнім часом, або на вашій сторінці немає багато зовнішніх ресурсів, або якщо зовнішні ресурси вашої сторінки кешовані браузером, або якщо сценарій Google кешований браузером ( надзвичайно ймовірно), тоді ви не побачите жодної різниці. Це просто абсолютно тривіально в цілому, такий самий ефект, як наклеювання зайвої крихітної картинки на вашу сторінку, грубо кажучи.

Приблизно єдиний раз, коли це може зробити конкретну різницю, це якщо у вас є якась поведінка, яка запускається під час події onLoad (яка чекає завантаження зовнішніх ресурсів), а сервери Google працюють повільно / повільно. Останнє навряд чи трапляється часто, але якби це було так, тоді onLoad навіть не запускатиметься, поки сценарій не буде завантажений. Ви в будь-якому випадку можете обійти це, використовуючи різні події "при завантаженні DOM", які, як правило, є більш чуйними, оскільки вам також не потрібно чекати, поки ваші власні сценарії / зображення завантажаться таким чином.

Якщо вас дуже турбує вплив на час завантаження сторінки, тоді загляньте до розділу "Чиста швидкість" Firebug , який дасть вам кількісну оцінку та складе гарний графік. Я б радив вам зробити це для себе в будь-якому випадку, оскільки навіть якщо інші люди дадуть вам цифри та орієнтири, які ви вимагаєте, це буде зовсім іншим для вашого власного сайту.


1
Ви впевнені, що "браузер завантажує скрипт Google паралельно разом із усіма іншими вбудованими ресурсами"? Спробували?
Арне Евертссон,

1
Візуалізація сторінки призупиняється при виявленні тегу <script>, паралельно нічого не робиться, наприклад, спробуйте щось на зразок: <script> while(true){}</script> <p> <img src = "/ picture.jpg" / > </p> і подивіться, чи відображається зображення після очищення кешу
Jake McGraw

1

Ну, я шукав, досліджував і широко розповсюджував у мережі. Але я не знайшов жодних статистичних даних, які б стверджували чи то на користь, чи то проти цієї передумови.

Однак у цьому уривку з http://www.ga-experts.com стверджується, що це міф про те, що GA уповільнює роботу вашого веб-сайту.

Помилка, добре, можливо, трохи, але ми говоримо про мілісекунди. GA працює шляхом позначення сторінок, і щоразу, коли ви додаєте більше вмісту на веб-сторінку, це збільшує час завантаження. Однак якщо ви дотримуєтеся найкращих практик (додавання тегу перед </body>тегом), тоді ваша сторінка завантажиться першою. Також майте на увазі, що будь-який пакет веб-аналітики на основі тегів сторінок (який є більшістю) буде працювати однаково

З наведених вище відповідей та всіх інших джерел я відчуваю, що будь-яке уповільнення, яке воно спричиняє, не сприймається користувачем, оскільки сценарій міститься внизу сторінки. Але якщо говорити про повне завантаження сторінки, можна сказати, що це уповільнює час завантаження сторінки.

Будь ласка, розмістіть у додатковій інформації, якщо у вас є, і ДАНІ, якщо у вас є.


1
Трохи дивно, що статті, подібні до наведеної вище, часто перевіряють лише тоді, коли сервери Google Analytics працюють нормально. Справи можуть бути більш складними, коли ці сервери перебувають під великим навантаженням. І якщо сервери відчувають проблеми, багато перезавантаження нетерплячих користувачів можуть погіршити ситуацію.
Arjan

0

Я не думаю, що це те, що ви шукаєте, але для чого вас турбує продуктивність?

Якщо це ваш сервер ... то, очевидно, це не впливає, оскільки він знаходиться на серверах Google.

Якщо ваших користувачів це турбує, тоді це також не вплине. Поки ви розміщуєте його безпосередньо над тегом body, ваші користувачі не отримуватимуть нічого повільніше, ніж раніше ... сценарій завантажується останнім і не впливає на зовнішній вигляд користувача. Тож там по суті нічого не чекаючи і навіть продовжуючи переглядати сторінку, не помічаючи, що вона все ще завантажується.


0

Питання полягало в тому, чи спричинить Google Analytics роботу вашого веб-сайту, і відповідь так. На даний момент на момент написання цієї статті Google-Analytics.com не працює, тому сайти, які містять те, що на своїх сторінках, не завантажуватимуть сторінки, так що так, це може сповільнитись і призвести до того, що ваш сайт навіть не завантажиться. Нерідко випадки, коли google-analytics.com не працює так довго, що зараз пройшло більше 10 хвилин, але це просто показує, що це можливо.


0

У цьому є два аспекти.

  1. Завантажити скрипт Analytics (і gif)
  2. Виконання завантажених скриптів

Час завантаження майже завжди менше 100 мс, що є прийнятним.

Ось поворот.

  1. виконання analytics.js 250 мс
  2. ремаркетинг (якщо увімкнено) 300 мс
  3. демографічні (якщо ввімкнено) 200 мс

Тож аналітика з ремаркетингом займає в середньому 750 мс. Я відчуваю, що це величезна кількість, коли справа стосується накладних витрат.


-2

Я помітив часте введення-виведення та перевантаження процесора в cPanel, що спричинило:

Недосяжна помилка сайту

І це припинилося після того, як я вимкнув плагін WP Analytics. Тому я вважаю, що це має певний вплив.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.