谷歌分析有性能开销吗？答案

【问题标题】：Does Google Analytics have performance overhead?谷歌分析有性能开销吗？
【发布时间】：2009-01-12 12:05:50
【问题描述】：

Google Analytics 对性能的影响程度如何？

我正在寻找以下内容：

基准（包括响应时间/页面加载时间等）
类似基准的链接或结果

在您的网站上测试 Google Analytics (GA) 的一种（可能的）方法：

从您自己的服务器提供 ga.js（Google Analytics JavaScript 文件）。
从 Google 每日（测试 1）和每周（测试 2）更新。

我很想看看这如何减少客户端网络服务器和 GA 服务器之间的通信。

有人做过这些测试吗？如果是这样，你能提供你的结果吗？如果没有，有没有人有更好的方法来测试使用 GA 的性能影响（或缺乏）？

【问题讨论】：

为什么人们将这个问题标记为“最喜欢的”而不给它投票？如果问题产生了有趣的答案，请为问题投票！
也许他们只是想看看人们的回应，但对主题并不完全感兴趣，（即他们正在考虑相关的事情）
对。值得一票。赞成票不是为了让你发笑的问题。这不是 YouTube。对可以丰富我们共同技术知识的问题进行投票。
我想不同的人有不同的投票标准，否则每个问题都会有大量的选票或被关闭。
重写问题以澄清、改进结构并去除句子片段。

标签： performance google-analytics benchmarking

【解决方案1】：

2018 年更新：您安装 Google Analytics（分析）的位置和方式一次又一次地发生了变化。当前的 gtag.js 代码做了几件事：

加载 gtag 脚本但异步（非阻塞）。这意味着它不会以任何其他方式降低您的页面速度，而不是带宽和处理速度。
在页面上创建一个名为window.datalayer 的数组
定义一个小的 gtag() 函数，它只会将你扔给它的任何东西推送到该数组中。
通过页面加载事件调用它。

加载主 gtag 脚本后，它会将这个数组与 Google 同步并监控它的变化。这是一个很好的系统，与以前的系统不同（例如，在</body> 之前填充代码）这意味着您可以在 DOM 呈现之前调用事件，并且脚本顺序并不重要，只要您先定义 gtag() .

这并不是说这里没有性能开销。我们在加载脚本时仍在使用带宽（它在本地缓存了 15 分钟），而且它们扔给您的脚本并不是一小堆，因此需要一些 CPU 时间来处理它。

但与（例如）现代前端框架相比，这一切都可以忽略不计。

如果您想要绝对的、最精简的网站，请完全避免使用它。如果您想保护用户的隐私，请不要使用任何第三方脚本...但是，如果我们谈论的是一个普通的现代网站，那么有很多比如果您遇到性能问题，请使用 gtag.js。

【讨论】：

Google 可能有更好的服务器，但他们不会尽可能提供 gzip 压缩的文件； 22k 不是一个大文件，它足够大，可以从 gzip 压缩中受益，尤其是纯文本（它在我的服务器上将其减少到 10k。）。
我不知道他们是否在 2 年前没有 gzip，但是，他们现在是，并且在撰写本文时它将文件大小从 30.92k 减少到 12.63k。
错了：GA 文件被标记为无缓存。没有人缓存它。
我很高兴找到这么简单的答案，但这是从 2009 年开始的。我不是说“旧的意味着坏”，我只是想知道：近年来有什么变化?
更新了最新的脚本。 @tacone 您的评论是在我最初回答之后几年。简单的事实是，谷歌在过去十年中反复改变了所有这些东西的工作方式。当前缓存为 900s。

【解决方案2】：

有一些 great slides Steve Souders（客户端性能专家）关于：

并行加载外部 JavaScript 文件的不同技术
它们对加载时间和页面呈现的影响
浏览器显示什么样的“进行中”指示器（例如状态栏中的“加载”、沙漏鼠标光标）。

【讨论】：

感谢您参考 Souders 的幻灯片，其中包含非常好的信息。

【解决方案3】：

我没有做过任何花哨的自动化测试或编程数字运算，但是使用带有 Firebug 插件和一对 JS 变量的老式 Firefox 来判断所有 GA 代码执行前后的时间差，这就是我的找到了。

下载了两个东西：

ga.js 是包含代码的 JavaScript 文件。这是 9kb，因此初始下载可以忽略不计，并且文件名不是动态的，因此在第一次请求后会被缓存。
带有动态 url 的 35 字节 gif 文件（通过查询字符串 args），因此每次都会请求。 35 字节的下载量也可以忽略不计（萤火虫说我花了 70 毫秒来下载它）。

就执行时间而言，我的第一个使用干净浏览器缓存的请求平均每次大约 330 毫秒，后续请求在 35 到 130 毫秒之间。

【讨论】：

当你说它花费了 70 毫秒时，你的意思是它增加了 70 毫秒到查看者点击链接和他们可以查看页面之间所花费的时间吗？如果是这种情况，那么从我所读到的内容来看，70 毫秒是非常重要的。我读到任何低于 100 毫秒的东西都被认为是瞬时的。因此，如果 70 毫秒已经用完，那么在结束明显延迟之前，您只剩下 30 毫秒来做所有其他事情。我完全不确定我所说的是否有道理，因为我不太了解这个话题，但至少从表面上看似乎合乎逻辑。

【解决方案4】：

根据我自己的经验，添加 Google-Analytics 并没有改变加载时间。

根据 FireBug 的说法，它在不到一秒的时间内加载（平均 648 毫秒），因此根据我的一些其他测试 ~60% - 80% 的时间是从服务器传输数据，这当然会因用户而异。

由于上述原因，我并不特别认为在本地缓存分析代码会改变加载时间。

我在 40 多个网站上使用 Google-Analytics 并没有导致任何甚至很小的速度变慢，大部分时间都花在获取图像上，由于它们的典型尺寸，这些图像是可以理解的。

【讨论】：

【解决方案5】：

您可以毫无问题地将 ga.js 托管在您的服务器上，但您的想法是您的用户将从他们可能访问过的一些其他站点缓存 ga.js。所以下载 ga.js，因为它非常流行，在很多情况下增加的开销很小（即它已经被缓存了）。

另外，由于网络拓扑的不同，DNS 查找在不同地方的成本并不相同。缓存行为会根据用户是否使用包含 ga.js 的其他网站而改变。

加载 javascript 后，ga.js 会与 Google 服务器进行通信，但这是一个异步过程。

希望这会有所帮助。

【讨论】：

【解决方案6】：

服务器端没有/最小的站点开销。

在客户端，页面可能需要一点时间（最多几秒钟）来完成显示页面。但是 - 根据我的经验，唯一没有加载的页面是谷歌的东西，所以用户可以很好地看到你的页面。你只是让页面顶部的悸动者颤动更长时间。

（注意：您需要将您的谷歌分析代码块放在任何提供的页面的底部，这样才能做到这一点。我不知道如果将代码块放在您的 HTML 顶部会发生什么）

【讨论】：

【解决方案7】：

来自 Google 的 traditional instructions 关于如何包含 ga.js 使用 document.write()。因此，即使浏览器会以某种方式异步加载外部 JavaScript 库，直到实际执行某些代码，document.write() 仍然会阻止页面加载。后面的asynchronous instructions 不直接使用document.write()，但可能insertBefore 也会阻塞页面加载？

但是，Google 将缓存的 max-age 设置为 86,400 seconds（为 1 天，甚至设置为 public，因此也适用于代理）。因此，由于许多站点加载相同的 Google 脚本，因此 JavaScript 通常会从缓存中获取。尽管如此，即使 ga.js 已被缓存，只需单击重新加载按钮，浏览器通常也会询问 Google 是否有任何更改。然后，就像ga.js 尚未缓存时一样，浏览器必须等待响应才能继续：

GET /ga.js HTTP/1.1
主机：www.google-analytics.com
...
If-Modified-Since: 2009 年 6 月 22 日星期一 20:00:33 GMT
缓存控制：max-age=0

HTTP/1.x 304 未修改
最后修改时间：2009 年 6 月 22 日星期一 20:00:33 GMT
日期：2009 年 7 月 26 日星期日 12:08:27 GMT
缓存控制：max-age=604800，公共
服务器：Golf

请注意，许多用户点击重新加载他们已经在浏览器窗口中打开的新闻网站、论坛和博客，导致许多浏览器在收到 Google 的响应之前被阻止。您多久重新加载一次 SO 主页？当 Google Analytics 响应缓慢时，这些用户会立即注意到。（网上有many solutions发布的异步加载ga.js脚本，对这类网站特别有用，但可能不再比谷歌的更新说明好。）

一旦加载并执行了 JavaScript，网络 bug（跟踪图像）的实际加载应该是异步的。因此，跟踪图像的加载不应阻止任何其他内容，除非页面使用body.onload()。在这种情况下，如果 web 错误无法及时加载，那么单击重新加载实际上会使事情变得更糟，因为单击重新加载也会使浏览器再次请求脚本，上面描述了 If-Modified-Since。 在重新加载之前浏览器只等待网络错误，而之后点击重新加载它还需要ga.js脚本的响应。

因此，使用 Google Analytics 的网站不应使用 body.onload()。相反，应该使用类似 jQuery 的 $(document).ready() 或 MooTools 的 domready event。

另请参阅 Google 的 Functional Overview，解释 Google Analytics 如何收集数据？，包括跟踪代码的工作原理。（这也表明 Google 会收集第一方 cookie 的内容。即：来自您正在访问的网站的 cookie。）

更新：in December 2009，谷歌发布了an asynchronous version。尽管upgrading does not solve everything，上述内容应该告诉大家升级只是为了确保。

【讨论】：

【解决方案8】：

这真的取决于一天。我只是将此添加到博客中。我在加利福尼亚，离他们的主要数据中心很近，使用快速低延迟的商业 DSL，使用超频 i5，有大量 RAM 运行最新的 linux 内核和稳定的 firefox。

这是一个示例页面加载：

仅 google-analytics 就增加了 5 秒的网络下载时间...获得 15Kb！

您可以看到 blogger.com 在 300 mili 秒内提供了 34Kb。速度提高了 32 倍！

另外，看看红线（代表 onLoad 事件，意思是页面上没有更多的脚本执行，因此浏览器最终可以停止加载指示器/旋转/等）...看看多远没错。这可能是那里发生的 3 秒垃圾 javascript 处理。这条线离资源下载栏的末端很远是非常罕见的。我已经完成了调试，这是 1/3 分析错误，2/3 博主错误。 ...人们会认为谷歌的东西很快。

编辑：

更多数据。这是一个缓存所有内容的请求。以上是第一次访问。

我从上面删除了 googleplus 废话有两个原因，我想看看他们是否在缓慢的 onLoad 事件中发挥了一些作用（他们不是），因为它大多是无用的。

因此，我们可以看到，网络时间是您最少的担忧。即使在装有现代软件的快速计算机上，收费谷歌分析 + 博主所花费的处理时间仍然会使您的页面加载超过 7 秒。没有博主，只检查这个网站，我看到资源加载后有 0.5 秒的延迟并且红线开始了。

【讨论】：

【解决方案9】：

从客户端的角度来看，将任何额外的 javascript 加载到您的页面会增加下载时间。您可以通过将其加载到页面底部来改善这一点，以便即使未加载 GA 也可以呈现您的页面。我会避免缓存，因为您将失去页面客户端缓存的优势。如果客户端从其他页面缓存了它，您页面的请求将由客户端本身填充。如果您将其更改为从您的站点加载，即使客户端已经拥有代码（很可能），它也需要下载。将任务添加到您的软件进程以避免从 Google 加载文件似乎是没有根据的，因为这可能是不必要的优化。很难对此进行测试，因为它总是会在本地更快地提供服务，但真正重要的是它对您的客户的运行速度有多快。如果您决定评估将其保留在本地，请确保您通过家庭互联网连接进行测试，而不是机架中服务器旁边的机器。

【讨论】：

【解决方案10】：

使用 FireBug 和 YSlow 自行检查。然而，您会发现 GA 的大小约为 9KB（实际上对于它的作用来说相当大），而且它有时加载速度也不是很快（我不知道是什么原因，我认为它可能是服务器有时会“窒息”）

由于Ajax Samples 上的性能问题，我们将其删除，但对于我们来说，超快和响应是优先级 1、2 和 3

【讨论】：

Thomas，你有没有关于删除 GA 代码后得到哪些改进的数字。就响应时间而言，以 %ages 或值本身为单位？
我喜欢每个人都这么聪明（包括我），但情况的经验是不同的（他们不总是吗？）。感谢您的回答，令人着迷。

【解决方案11】：

没有什么明显的。

对 Google 的调用（包括 DNS 查找、加载未缓存的 Javascript 以及实际的跟踪器调用本身）应由客户端浏览器在单独的线程中完成，以实际加载您的页面。当然，DNS 查找将由底层系统完成，据我所知，不会算作浏览器中的查找（浏览器对每个站点使用的请求线程数有限制）。

除此之外，浏览器将同时加载 Google 脚本以及所有其他嵌入式资源，因此在最坏的情况下（我们正在讨论毫秒级，不明显。如果谷歌脚本是浏览器最后加载的，或者你的页面上没有很多外部资源，或者你页面的外部资源被浏览器缓存了，或者谷歌的脚本被浏览器缓存了浏览器（极有可能），那么您将看不到任何区别。总体而言，这绝对是微不足道的，粗略地说，与在页面上粘贴额外的小图片效果相同。

大约唯一可能产生具体影响的情况是，如果您有一些行为触发 onLoad 事件（等待外部资源加载），并且 Google 服务器已关闭/缓慢.后者不太可能经常发生，但如果是这种情况，那么在下载脚本之前 onLoad 甚至不会触发。无论如何，您都可以通过使用各种“当 DOM 加载时”事件来解决这个问题，这些事件通常响应更快，因为您也不必等待自己的脚本/图像以这种方式加载。

如果您真的很担心对页面加载时间的影响，那么请查看Firebug 的“网络速度”部分，它将对此进行量化并为您绘制漂亮的图表。无论如何，我鼓励您自己做这件事，因为即使其他人向您提供您要求的数据和基准，它将对于您自己的网站完全不同。

【讨论】：

您确定“浏览器将与所有其他嵌入式资源并行加载 Google 脚本”吗？试过了吗？
页面渲染在
看看你的缓存清除后图片是否显示

【解决方案12】：

嗯，我已经在网上进行了广泛的搜索、研究和探索。但我没有发现任何支持或反对前提的统计数据。

但是，http://www.ga-experts.com 的这段摘录声称这是一个神话，即 GA 会降低您的网站速度。

呃，好吧，也许有点，但是我们谈论的是毫秒。遗传算法通过页面标记工作，并且任何时候您向网页添加更多内容，它会增加加载时间。然而如果您遵循最佳实践（添加 </body> 标签之前的标签）然后您的页面将首先加载。还有，熊请记住，任何基于网页标签的网页分析包（这是大多数）将以相同的方式工作

从上面的答案和所有其他来源，我觉得无论它导致的任何减速都不会被用户感知，因为脚本包含在页面底部。但是，如果我们谈论完整的页面加载，我们可能会说它会减慢页面加载时间。

如果有，请发布更多信息，如果有，请发布数据。

【讨论】：

有点奇怪的是，上述文章通常只在 Google Analytics（分析）服务器正常运行时进行测试。当这些服务器负载很重时，事情可能会更麻烦。如果服务器遇到问题，不耐烦的用户的大量重新加载可能会使事情变得更糟。

【解决方案13】：

我认为这不是您想要的，但您担心性能是什么？

如果它是您的服务器...那么显然没有影响，因为它驻留在 Google 服务器上。

如果您担心的是您的用户，那么也不会产生任何影响。只要您将它放在 body 标记上方，那么您的用户将不会收到比以前慢的任何东西......脚本最后加载并且对用户的外观没有影响。所以基本上没有等待任何东西，甚至继续浏览页面而没有注意到它仍在加载。

【讨论】：

【解决方案14】：

问题是 Google Analytics（分析）是否会导致您的网站变慢，答案是肯定的。目前，在撰写此 Google-Analytics.com 时，该网站无法正常工作，因此页面中包含该内容的网站不会加载页面，所以是的，它可能会减慢速度并导致您的网站甚至无法加载。 google-analytics.com 出现如此长的停机时间并不常见，目前已经超过 10 分钟，但这只是表明它是可能的。

【讨论】：

【解决方案15】：

它有两个方面。

分析脚本（和 gif）下载
下载的脚本执行

下载时间几乎总是小于 100 毫秒，这是可以接受的。

转折来了。

analytics.js 执行 250ms
再营销（如果启用）300 毫秒
人口统计（如果启用）200 毫秒

因此，再营销分析平均需要 750 毫秒。我觉得在性能开销方面这是一个巨大的数字。

【讨论】：

【解决方案16】：

我注意到 cPanel 中频繁的 I/O 和 CPU 过载导致：

网站无法访问错误

在我禁用 WP Analytics 插件后，这种情况就停止了。所以我认为它确实有一些影响。

【讨论】：