谷歌分析是否有性能开销？

Question

谷歌分析对性能的影响有多大？

我需要以下内容:

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

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

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

我很想看到这如何减少客户机Web服务器与GA服务器之间的通信。

是否有人进行了这些测试？如果是，您可以提供结果吗？如果没有，是否有更好的测试GA使用性能影响（或缺乏影响）的方法？

- Mohit Nanda

---

我看到很多关于页面加载时间的帖子，但异步请求的消耗呢？浏览器对挂起请求的数量有限制，而且更新 Google 肯定会消耗其中一些。如果您的网站大量使用同时进行的异步请求，那么使用 Google Analytics 是否会导致阻塞实际应用程序的请求？ - user748852

@user748852 这仍然是真的。 - Aluan Haddad

Answer 1

2018年更新：关于Analytics要放置在哪里以及如何放置已经不断变化了很多次。当前的gtag.js代码执行以下几个步骤：

1. 异步（非阻塞）加载gtag脚本。这意味着它不会以除了带宽和处理之外的任何其他方式减慢您的页面速度。
2. 在页面上创建一个名为window.datalayer的数组。
3. 定义一个简单的gtag()函数，将其推入该数组中。
4. 调用该事件并随之产生一个页面加载事件。

一旦主要的gtag脚本加载完毕，它就会与Google同步此数组并监视其更改。这是一个很好的系统，与先前的系统（例如只需在</body>之前添加代码）不同的是，它意味着您可以在DOM渲染之前调用事件，并且脚本顺序并不重要，只要您首先定义gtag()即可。

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

但与（例如）现代前端框架相比，这一切都微不足道。

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

- Oli

---

谷歌可能拥有更好的服务器，但如果可能的话，他们不会提供压缩文件gzipped；22k并不是一个非常大的文件，但足够大以从gzipping中受益，特别是它是纯文本（在我的服务器上可以将其减小到10k）。 - Ross

我不知道两年前他们是否使用gzip，但现在他们正在使用，并且根据本文撰写时的情况，它将文件大小从30.92k减小到12.63k。 - Yahel

错误的是： GA 文件被标记为 no-cache。没有人将其缓存。 - tacone

我很高兴找到一个如此简单的答案，但这是来自2009年。我并不是说“旧就意味着不好”，我只是想知道：最近几年有没有什么变化？ - Lazar Ljubenović

已更新至最新脚本。@tacone，你的评论是在我最初回答几年后发表的。事实是，谷歌在过去十年中一再改变了所有这些东西的工作方式。当前缓存为900秒。 - Oli

Answer 2

Steve Souders（客户端性能专家）有一些非常棒的幻灯片，关于：

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

- orip

Answer 3

我没有进行任何高级自动化测试或程序化数字计算，但使用老牌的Firefox浏览器和Firebug插件以及一对JS变量来告诉所有GA代码执行前后的时间差异，这是我发现的情况。

下载了两个东西：

1. ga.js是包含代码的JavaScript文件。这是9KB，所以初始下载是微不足道的，并且文件名不是动态的，因此它在第一次请求后被缓存。 2. 一个35字节的gif文件，具有动态url（通过查询字符串参数），因此每次都会请求。35字节也是微不足道的下载量（firebug说我用了70ms来下载它）。

至于执行时间，我的第一个请求（清除浏览器缓存）平均约为每次330ms，随后的请求在35到130ms之间。

- Rich

---

当你说它花费了70毫秒，你是指它增加了70毫秒的时间，从观看者点击链接到页面对他们可见之间所花费的时间吗？如果是这样的话，根据我所读的，70毫秒非常重要。我读到，任何低于100毫秒的东西都被认为是瞬间的。因此，如果已经使用了70毫秒，那么在出现明显延迟之前，你只剩下30毫秒来完成所有其他事情。我不确定我所说的是否有意义，因为我对这个主题并不是很了解，但至少表面上似乎是合乎逻辑的。 - user3425506

Answer 4

您可以毫不担心地将ga.js托管在您的服务器上，但是想法是您的用户可能已经从一些其他网站缓存了ga.js。因此，在许多情况下（即已经被缓存），下载ga.js几乎不会增加额外开销，因为它非常流行。

此外，由于网络拓扑结构不同，DNS查找在不同地方的成本也不同。缓存行为将根据用户是否使用包含ga.js的其他站点而发生变化。

一旦JavaScript已加载，ga.js确实与Google服务器通信，但这是一个异步过程。

- Daniel Rosenstark

Answer 5

从我的经验来看，添加Google Analytics并没有改变加载时间。

根据FireBug的显示，它在不到一秒钟的时间内加载完成（平均648毫秒），根据我的其他测试，大约60％-80％的时间是从服务器传输数据，这当然会因用户而异。

我不认为将分析代码缓存到本地会对加载时间产生太大的影响，原因如上。

我在40多个网站上使用Google Analytics，它从未成为任何甚至是小型减速的原因，最耗时的是获取图片，由于它们的典型大小，这是可以理解的。

- Unkwntech

Answer 6

这真的取决于当天情况。我只是在博客中添加这个内容。我在加利福尼亚，非常靠近他们的主数据中心，在快速低延迟的商业DSL上，使用超频的i5和充足的RAM运行最新的Linux内核和稳定的Firefox。

下面是一个样本页面加载: 仅Google Analytics就需要5秒的网络下载时间...才能获取15Kb!

您可以看到Blogger.com在300毫秒内提供了34Kb。这比前者快32倍！

此外，请注意红线（表示onLoad事件，意味着页面上不再执行脚本，因此浏览器最终可以停止加载指示器/旋转等）...请看它距离右边有多远。那大概是3秒钟的垃圾JavaScript处理。很少见得到该行远离资源下载栏的末端。我已经完成了调试，1/3是分析故障，2/3是博客故障。...人们会认为谷歌的东西很快。

编辑：

一些更多的数据。这里是一个包括所有缓存的请求。上述请求是第一次访问。

我从上面删除了Google Plus的垃圾，原因有两个，一是我想看看它们是否对缓慢的onLoad事件起了一定作用（事实并非如此），二是因为它几乎是无用的。

所以，根据这个结果，我们可以看到网络时间是您最不用担心的。即使在快速计算机和现代软件上，Google Analytics + Blogger所花费的处理时间仍然会将页面加载超过7秒。如果没有Blogger，请查看此网站，我看到资源加载后有0.5秒的延迟，并且红线开始工作。

- gcb

Answer 7

在服务器端没有或仅有极少的网站开销。

Google Analytics的HTML代码只有三行Javascript，您可以将其放置在网页底部。它实际上什么都不是，并且不会消耗比版权声明更多的服务器资源。

在客户端，页面可能需要一点时间（最多几秒钟）才能完成显示。然而，在我的经验中，页面上唯一未加载的部分是Google相关内容，因此用户可以完美地查看您的页面。您只需要在页面顶部看到throbber转动的时间稍长。

（注意：要使这种情况成立，您需要将Google Analytics代码块放置在所有服务的页面底部。如果将代码块放置在HTML顶部，我不知道会发生什么。）

- seanyboy

Answer 8

谷歌的传统指南中关于如何包含ga.js的说明使用了document.write()。因此，即使浏览器以某种方式异步加载外部JavaScript库直到某些代码实际执行，document.write()仍然会阻止页面加载。后来的异步指南没有直接使用document.write()，但是insertBefore也可能会阻止页面加载？

然而，Google将缓存的max-age设置为86400秒（即1天，并且设置为公共，因此也适用于代理）。因此，由于许多站点加载完全相同的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响应缓慢时，这些用户会立刻注意到。(网络上发布了许多解决方案来异步加载ga.js脚本，对于这些类型的网站特别有用，但可能不再比Google的更新指令更好。)

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

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

另请参见Google的功能概述，解释了“Google Analytics如何收集数据？”，包括“跟踪代码的工作原理”。（这也正式说明Google收集第一方cookie的内容。也就是你正在访问的网站的cookie。）

---

更新：在2009年12月，Google发布了一个异步版本。上述内容应该告诉每个人升级以确保安全，但是升级并不能解决所有问题。

- Arjan

Answer 9

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

- tvanfosson

Answer 10

使用FireBug和YSlow来进行检查。然而，你会发现GA的大小约为9KB（实际上对于它所做的事情来说相当大），有时加载速度也很慢（原因我不知道，可能是服务器有时会“卡住”）。我们在Ajax示例中由于性能问题将其移除了，但对我们来说，超快速和响应是第一、二、三优先级。

- Thomas Hansen

---

Thomas，你有没有数据可以说明删除GA代码后的改进情况。比如响应时间方面，以百分比或数值本身来衡量？ - M.N

我喜欢每个人都很聪明（包括我），但情况的实证是不同的（它们总是这样吗？）。感谢您的答案，非常有趣。 - Dan Rosenstark