Накладные расходы Google Analytics?

Ответ 1

Обновление 2018 года: где и как вы монтируете Google Analytics, меняется снова и снова. Текущий код gtag.js делает несколько вещей:

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

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

Это не означает, что здесь нет снижения производительности. Мы по-прежнему используем пропускную способность при загрузке сценария (он кэшируется локально в течение 15 минут), и это не маленькая куча сценариев, которые они вам выдают, поэтому есть некоторое время процессора для его обработки.

Но все это незначительно по сравнению (например) с современными интерфейсами.

Если вы собираетесь использовать абсолютный, самый урезанный веб-сайт, избегайте его полностью. Если вы пытаетесь защитить конфиденциальность своих пользователей, не используйте какие-либо сторонние сценарии... Но если мы говорим о среднем современном веб-сайте, вы получите гораздо меньший результат, чем gtag.js, если вы проблемы с производительностью

Ответ 2

Есть несколько отличных слайдов от Steve Souders (эксперт по оценке на стороне клиента) о:

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

Ответ 3

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

Загружаются две вещи:

• ga.js - это файл JavaScript, содержащий код. Это 9kb, поэтому первоначальная загрузка незначительна, и имя файла не является динамическим, поэтому оно кэшируется после первого запроса.

• 35-байтовый файл gif с динамическим url (через args строки запроса), поэтому каждый раз запрашивается. 35 байтов также является незначительной загрузкой (firebug говорит, что мне потребовалось 70 мс для него).

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

Ответ 4

По моему собственному опыту он добавил, что Google Analytics не изменила время загрузки.

Согласно FireBug, он загружается менее чем за секунду (648MS avg), и согласно этому некоторые из моих других тестов ~ 60% - 80% того времени передавали данные с сервера, что, конечно же, будет варьироваться от пользователя к пользователю.

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

GET /ga.js HTTP/1.1  
Host: www.google-analytics.com  
...  
If-Modified-Since: Mon, 22 Jun 2009 20:00:33 GMT  
Cache-Control: max-age=0  

HTTP/1.x 304 Not Modified  
Last-Modified: Mon, 22 Jun 2009 20:00:33 GMT  
Date: Sun, 26 Jul 2009 12:08:27 GMT  
Cache-Control: max-age=604800, public  
Server: Golfe  

Обратите внимание, что многие пользователи нажимают перезагрузку для новостных сайтов, форумов и блогов, которые они уже открыли в окне браузера, заставляя много браузеров блокироваться до получения ответа от Google. Как часто вы перезагружаете домашнюю страницу SO? Когда ответ Google Analytics идет медленно, пользователи сразу же заметят. (Есть множество решений, опубликованных в сети, для асинхронной загрузки ga.js script, особенно полезной для таких сайтов, но, возможно, не лучше, чем обновленные инструкции Google.)

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

Таким образом, сайты с использованием Google Analytics не должны использовать body.onload(). Вместо этого нужно использовать что-то вроде jQuery $(document).ready() или MooTools событие domready.

См. также Google Функциональный обзор, поясняющий, как Google Analytics собирает данные?, в том числе, как работает код отслеживания. (Это также делает официальным, что Google собирает содержимое файлов cookie сторонних производителей, то есть: файлы cookie с сайта, который вы посещаете.)

Обновление: в декабре 2009 года, Google выпустил асинхронный версия. Вышеупомянутое должно сказать всем, чтобы обновить только, чтобы быть уверенным, хотя обновление не решает все.

Ответ 8

Это действительно зависит от дня. Я просто добавляю это в блог. Я в Калифорнии, очень близко к их основным центрам обработки данных, в быстром бизнесе DSL с низкой задержкой, на разогнанном i5 с большим количеством оперативной памяти, работающей с последним ядром Linux и стабильным firefox.

здесь пример загрузки страницы:

Только Google Analytics добавила 5 секунд всего времени загрузки сети... чтобы получить 15Kb!

Вы можете видеть, что blogger.com обслуживает 34Kb за 300 миллионов секунд. Это на 32 раза быстрее!

Кроме того, посмотрите, как красная линия (которая представляет событие onLoad, а это означает, что на странице не более script, и поэтому браузер может, наконец, остановить индикаторы загрузки/вращения/etc)... посмотрите, как далеко вправо. что, вероятно, 3 секунды обработки обработки javascript мусора, которая там была. Очень необычно, что эта строка находится очень далеко от конца баров загрузки ресурсов. Я сделал отладку этого и это ошибка 1/3 аналитики, ошибка 2/3 блогера.... можно подумать, что материал google был быстрым.

Edit:

Еще несколько данных. Здесь запрос со всем кэшированием. первый из них был первым.

Я удалил googleplus дерьмо сверху по двум причинам, я пытался посмотреть, играют ли они какую-то часть в медленном событии onLoad (это не так), и потому что это в основном бесполезно.

Итак, с этим мы можем видеть, что сетевое время - это наименьшее из ваших забот. Даже на быстром компьютере с современным программным обеспечением, Google Analytics + blogger получает время обработки, все равно сбрасывает загрузку страницы за 7 секунд. Без блоггера просто проверьте этот сайт, я вижу 0,5 с задержкой после загрузки ресурсов и красной линии.

Ответ 9

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

Ответ 10

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

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

Ответ 11

Ничего заметного.

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

Кроме того, браузер будет загружать Google script параллельно вместе со всеми другими встроенными ресурсами, поэтому вы можете получить очень небольшое увеличение времени, необходимого для загрузки всего, в худшем случае (мы разговора в миллисекундах, незаметно. Если Google script загружается последним браузером или у вас не так много внешних ресурсов на вашей странице, или если внешние ресурсы вашей страницы кэшируются браузером или если Google script кэшируется браузером (крайне вероятно), тогда вы не увидите никакой разницы. Это просто абсолютно тривиально в целом, тот же эффект, что и грубо говоря, наложение дополнительной крошечной картинки на вашу страницу.

Единственный раз, когда это может иметь конкретное значение, - если у вас есть какое-то поведение, которое срабатывает в событии onLoad (которое ждет загрузки внешних ресурсов), а серверы Google работают медленно или медленно. Последнее вряд ли произойдет часто, но если это так, то onLoad даже не будет срабатывать до загрузки script. Вы можете обойти это в любом случае, используя различные события "при загрузке DOM", которые, как правило, более отзывчивы, так как вам не нужно ждать, пока ваши собственные сценарии/изображения загрузятся таким образом.

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

Ответ 12

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

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

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

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

Пожалуйста, напишите в дополнительной информации, если у вас есть и DATA, если у вас есть.

Ответ 13

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

Если это ваш сервер... то, очевидно, никакого влияния на серверы Google не оказывает.

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

Ответ 14

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

Ответ 15

Есть два аспекта.

• Аналитика script 's' (и gif) скачать
• Выполнение выполненных скриптов

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

Вот и твист.

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

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

Ответ 16

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

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

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