Google Analytics是否有性能开销？

Question

Google Analytics在多大程度上会影响效果？

我正在寻找以下内容：

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

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

1. 从您自己的服务器上提供ga.js（Google AnalyticsJavaScript文件）。
2. 从Google Daily（测试1）和Weekly（测试2）更新。

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

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

Answer 1

2018更新：您在何处以及如何安装Google Analytics已经一次又一次地改变。当前的gtag.js代码做了一些事情：

1. 加载gtag脚本但是异步（非阻塞）。这意味着它不会以带宽和处理之外的任何其他方式减慢页面速度。
2. 在名为window.datalayer
的页面上创建一个数组
3. 定义一个小gtag()函数，只需将你抛出的任何内容推送到该数组中。
4. 使用pageload事件调用。

加载主gtag脚本后，它会将此阵列与Google同步并监控其变化。它是一个很好的系统，与以前的系统不同（例如，在</body>之前填充代码），这意味着您可以在DOM渲染之前调用事件，并且只要您定义{{，脚本顺序并不重要1}}首先。

这并不是说这里没有性能开销。我们仍然在加载脚本时使用带宽（它在本地缓存15分钟），并且它们不是一大堆脚本，它们会向你抛出，所以有一些CPU时间处理它。

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

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

Answer 2

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

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

Answer 3

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

下载了两件事：

1. ga.js是包含代码的JavaScript文件。这是9kb，因此初始下载可以忽略不计，文件名不是动态的，所以它在第一次请求后被缓存。

2. 带有动态网址的35字节gif文件（通过查询字符串args），因此每次都会请求此文件。 35字节的下载量也可以忽略不计（萤火虫说它花了我70分钟来完成它）。

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

Answer 4

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

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

由于上述原因，我没有预先认为在本地缓存分析代码会大大改变加载时间。

我在超过40个网站上使用Google-Analytics而没有任何原因，甚至是小的减速，花费大部分时间来获取图像，由于它们的典型尺寸，这是可以理解的。

Answer 5

您可以在服务器上托管ga.js而不会出现任何问题，但我们的想法是，您的用户将从他们可能访问过的某些其他网站缓存ga.js。所以下载ga.js，因为它如此受欢迎，在许多情况下增加了很少的开销（即，它已经被缓存）。

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

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

希望这会有所帮助。

Answer 6

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

Google Analytics的HTML是您放置在网页底部的三行JavaScript。它并不是真的，并且不会消耗比版权声明更多的服务器资源。

在客户端，页面可能需要一点时间（最多几秒）才能完成页面显示。但是 - 根据我的经验，未加载页面的唯一部分是Google的内容，因此用户可以完全看到您的页面。你只是让页面顶部的悸动者悸动了一会儿。

（注意：您需要将Google分析代码块放在任何提供的页面的底部，以便达到这种情况。我不知道如果代码块放在HTML的顶部会发生什么情况< / p>

Answer 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  
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响应缓慢时，此类用户会立即注意到。 （网上发布many solutions异步加载ga.js脚本，对这类网站特别有用，但可能不再比谷歌的更新说明更好。）

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

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

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

---

更新：in December 2009，Google发布了an asynchronous version。上面应该告诉大家升级只是为了确保upgrading does not solve everything。

Answer 8

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

Answer 9

使用FireBug和YSlow自行检查。然而，你会发现GA的大小约为9KB（实际上它实际上非常重要）并且它有时也不会非常快地加载（出于什么原因我不知道，我认为它可能是服务器“有时会”窒息“

由于Ajax Samples上的性能问题，我们删除了，但是我们超快并且响应优先级为1,2和3 < / p>

Answer 10

这取决于当天。我只是将它添加到博客中。我在加利福尼亚州，非常接近他们的主要数据中心，在快速低延迟的商业DSL上，在超频的i5上运行最近的Linux内核和稳定的Firefox，有足够的RAM。

这是一个示例页面加载：

google-analytics单独添加5 秒只是网络下载时间......获得15Kb！

您可以在300 mili 秒内看到blogger.com提供34Kb的服务。这快了32倍！

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

编辑：

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

我从上面删除了googleplus废话有两个原因，我试图看看他们是否在缓慢的onLoad事件中扮演某些角色（他们不是），因为它几乎没用。

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

Answer 11

没有什么值得注意的。

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

除此之外，浏览器将与所有其他嵌入式资源并行加载Google脚本，因此在最糟糕的情况下（我们正在谈论），您可能会略微增加下载所有内容所需的时间如果谷歌脚本是由浏览器最后加载的，或者您的页面上没有很多外部资源，或者浏览器缓存了您网页的外部资源，或者Google的脚本是通过缓存的，那么毫秒级是不可理解的。浏览器（极有可能）那么你就不会看到任何差异了。总的来说，这是非常微不足道的，就像在你的页面上粘贴一张额外的小图片一样，粗略地说。

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

如果你真的担心对页面加载时间的影响，那么看看Firebug的“净速度”部分，它将量化这个并绘制一个漂亮的图形。我鼓励你为自己做这件事，即使其他人给你你要求的数字和基准，它 会对你自己的网站完全不同。

Answer 12

好吧，我已经在网上进行了广泛的搜索，研究和评论。但我没有找到任何支持或反对这一前提的统计数据。

但是，http://www.ga-experts.com的这段摘录声称GA会减慢您网站的速度。

  

呃，好吧，也许稍微，但是   我们谈论的是毫秒。 GA   通过页面标记，以及任何时间   你在网页上添加了更多内容   会增加加载时间。然而   如果你遵循最佳实践（添加   然后是</body>标记之前的标记   您的网页将首先加载。还有，熊   记住任何基于网页的标签   分析包（即   多数）将以同样的方式工作

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

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

Answer 13

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

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

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

Answer 14

问题是Google Analytics会导致您的网站速度变慢，答案是肯定的。现在，在撰写本文时，Google-Analytics.com无法正常工作，因此在其网页中具有该页面的网站将不会加载页面，因此，它可能会变慢并导致您的网站甚至无法加载。 google-analytics.com落后这么长时间并不常见，现在已超过10分钟，但它只是表明它是可能的。

Answer 15

它有两个方面。

1. Google Analytics脚本的'（和gif）下载
2. 下载的脚本执行

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

这就是扭曲。

1. analytics.js执行250毫秒
2. 重新营销（如果启用）300毫秒
3. 人口统计（如果启用）200ms

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

Answer 16

我注意到cPanel中频繁发生I / o和CPU过载，结果是：

  

网站无法访问错误

并且在我禁用WP Analytics插件后停止了。所以我认为这确实有一定影响。