Есть ли у Google Analytics накладные расходы на производительность?

83

В какой степени Google Analytics влияет на производительность?

Я ищу следующее:

  • Тесты (включая время отклика / время загрузки страницы и др.)
  • Ссылки или результаты на аналогичные тесты

Один (возможный) метод тестирования Google Analytics (GA) на вашем сайте:

  1. Подавайте ga.js (файл JavaScript Google Analytics) со своего сервера.
  2. Обновление из Google Daily (тест 1) и Weekly (тест 2).

Мне было бы интересно увидеть, как это снижает связь между клиентским веб-сервером и сервером GA.

Кто-нибудь проводил какие-либо из этих тестов? Если да, можете ли вы предоставить свои результаты? Если нет, есть ли у кого-нибудь лучший метод тестирования производительности (или ее отсутствия) при использовании GA?

MN
источник
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 - это не огромный файл, он достаточно велик, чтобы извлечь выгоду из сжатия, особенно в виде обычного текста (на моем сервере он сокращается до 10k).
Росс,
6
Я не знаю, не выполняли ли они сжатие 2 года назад, но теперь они есть, и на момент написания этой статьи размер файла уменьшился с 30,92k до 12,63k.
Yahel
2
Так неправильно: файл GA помечен как не кешируемый. Ни у кого это не кешируется.
tacone
1
Я счастлив найти такой простой ответ, но это с 2009 года. Я не говорю, что «старое значит плохое», мне просто интересно: изменилось ли что-нибудь за последние годы?
Lazar Ljubenović
1
Обновлено для последнего скрипта. @tacone Ваш комментарий был через несколько лет после моего первоначального ответа. Простой факт: Google неоднократно менял принцип работы всего этого за последнее десятилетие. Текущий кеш - 900 с.
Оли
11

Стив Содерс (эксперт по производительности на стороне клиента) сделал несколько отличных слайдов о:

  • Различные методы параллельной загрузки внешних файлов JavaScript
  • их влияние на время загрузки и рендеринг страницы
  • какие индикаторы «в процессе» отображает браузер (например, «загрузка» в строке состояния, курсор мыши в виде песочных часов).
orip
источник
Спасибо за ссылку на слайды Содерса, за содержащуюся в них отличную информацию.
Sabuncu 06
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, он загружается менее чем за секунду (648MS в среднем), и, согласно некоторым другим моим тестам, ~ 60% - 80% этого времени передавало данные с сервера, что, конечно, будет варьироваться от пользователя к пользователю.

Я не думаю, что локальное кэширование кода аналитики сильно изменит время загрузки по указанным выше причинам.

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

UnkwnTech
источник
5

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

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

После загрузки javascript ga.js взаимодействует с серверами Google, но это асинхронный процесс.

Надеюсь это поможет.

Дэн Розенстарк
источник
3

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

HTML для Google Analytics - это три строки javascript, которые вы размещаете внизу своей веб-страницы. На самом деле это ничего, и он не потребляет больше ресурсов сервера, чем уведомление об авторских правах.

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

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

seanyboy
источник
3

В традиционных инструкции от Google о том , как включить ga.jsиспользование document.write(). Таким образом, даже если браузер каким-то образом будет асинхронно загружать внешние библиотеки JavaScript до тех пор, пока какой-то код действительно не будет выполнен, document.write()он все равно заблокирует загрузку страницы. Более поздние асинхронные инструкцииdocument.write() напрямую не используются , но, возможно,insertBefore также блокируют загрузку страницы?

Однако Google устанавливает для кеша max-ageзначение 86400 секунд (это 1 день и даже установлено как общедоступное , что также применимо к прокси). Таким образом, поскольку многие сайты загружают один и тот же скрипт Google, JavaScript часто будет извлекаться из кеша. Тем не менее, даже если ga.jsон кэширован, просто нажатие кнопки перезагрузки часто заставляет браузер спрашивать Google о любых изменениях . А затем, как и в случае, когда еще ga.jsне было кэшировано, браузер должен дождаться ответа, прежде чем продолжить:

ПОЛУЧИТЬ /ga.js HTTP / 1.1  
Хост: www.google-analytics.com  
...  
If-Modified-Since: понедельник, 22 июня 2009 г., 20:00:33 GMT  
Cache-Control: max-age = 0  

HTTP / 1.x 304 без изменений  
Последнее изменение: понедельник, 22 июня 2009 г., 20:00:33 GMT  
Дата: вс, 26 июля 2009 г., 12:08:27 GMT  
Cache-Control: 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 + blogger, все равно будет сбрасывать загрузку вашей страницы за 7 секунд. Без блоггера просто проверьте этот самый сайт, я вижу задержку 0,5 секунды после загрузки ресурсов и красной линии.

gcb
источник
2

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

tvanfosson
источник
2

Используйте FireBug и YSlow, чтобы убедиться в этом сами. Однако вы обнаружите, что размер GA составляет около 9 КБ (что на самом деле довольно существенно для того, что он делает) и что он также иногда НЕ загружается очень быстро (по каким причинам я не знаю, я думаю, что это может быть сервера иногда "задыхаются")

Мы удалили его из-за проблем с производительностью в наших образцах Ajax , но, опять же, для нас сверхбыстрость и отзывчивость были приоритетом 1, 2 и 3.

Томас Хансен
источник
Томас, есть ли у вас какие-либо цифры относительно того, какие улучшения вы получили после удаления кода GA? С точки зрения времени отклика, в% возрастов или самих значений?
MN
Мне нравится, как все такие умные (включая меня), но эмпирические данные ситуации РАЗНЫЕ (не всегда ли?). Спасибо за наш ответ, замечательный.
Дэн Розенстарк,
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> и посмотрите, отображается ли изображение после очистки кеша
Джейк МакГроу,
1

Что ж, я искал, исследовал и широко освещал в сети. Но я не нашел никаких статистических данных, которые утверждали бы в пользу или против этой предпосылки.

Однако этот отрывок из http://www.ga-experts.com утверждает, что это миф, что GA замедляет работу вашего сайта.

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

Из приведенных выше ответов и из всех других источников я считаю, что любое замедление, которое оно вызывает, не воспринимается пользователем, поскольку сценарий включен в нижней части страницы. Но если мы говорим о полной загрузке страницы, мы можем сказать, что это замедляет время загрузки страницы.

Пожалуйста, разместите дополнительную информацию, если у вас есть и ДАННЫЕ, если они у вас есть.

MN
источник
1
Немного странно, что статьи, подобные приведенной выше, часто тестируются только тогда, когда серверы Google Analytics работают нормально. Проблемы могут быть сложнее, когда эти серверы сильно загружены. И если на серверах возникают проблемы, многочисленные перезагрузки нетерпеливых пользователей могут усугубить ситуацию.
Arjan
0

Я не думаю, что это то, что вы ищете, но чего вы беспокоитесь о производительности?

Если это ваш сервер ... то, очевидно, нет никакого влияния, поскольку он находится на серверах Google.

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

youdontmeanmuch
источник
0

Вопрос был в том, вызовет ли Google Analytics замедление работы вашего сайта, и ответ положительный. Прямо сейчас на момент написания этого Google-Analytics.com не работает, поэтому сайты, у которых есть это на своих страницах, не будут загружать страницы, так что да, это может замедлиться и привести к тому, что ваш сайт даже не загрузится. Google-analytics.com не работает так долго, что сейчас составляет более 10 минут, но это просто показывает, что это возможно.

Решения для знакомств
источник
0

У этого есть два аспекта.

  1. Скачать скрипт аналитики (и гифку)
  2. Выполнение загруженных скриптов

Время загрузки почти всегда меньше 100 мс, что приемлемо.

А вот и поворот.

  1. analytics.js выполнение 250 мс
  2. ремаркетинг (если включен) 300 мс
  3. демографические (если включено) 200 мс

Таким образом, аналитика с ремаркетингом занимает в среднем 750 мс. Я считаю, что это огромное число, когда речь идет о накладных расходах.

Джозеф Куландай
источник
-2

Я заметил частую перегрузку ввода-вывода и процессора в cPanel, в результате чего:

Ошибка недоступности сайта

И это прекратилось после того, как я отключил плагин WP Analytics. Так что я считаю, что это имеет какое-то влияние.

user11952079
источник