Google Analytics（分析）在多大程度上影响性能？
我正在寻找以下内容：
在您的网站上测试Google Analytics（分析）的一种（可能）方法：
我很想知道这如何减少客户端Web服务器和GA服务器之间的通信。
有人进行过这些测试吗？如果可以，您能否提供结果？如果不是，是否有人有更好的方法来测试使用GA所带来的性能下降（或没有下降）？
Answers:
2018年更新：安装Google Analytics（分析）的位置和方式一再改变。当前的gtag.js代码可以执行以下操作：
window.datalayergtag()函数，将您将其投入的任何内容推入该数组。加载主gtag脚本后，它将将该数组与Google同步并监视其更改。这是一个很好的系统，与以前的系统不同（例如，在之前填充代码</body>），这意味着您可以在DOM呈现之前调用事件，而脚本顺序并不重要，只要gtag()先定义即可。
这并不是说这里没有性能开销。我们在加载脚本时仍在使用带宽（该脚本在本地缓存15分钟），而且它们扔给您的脚本不是很多，因此有一些CPU时间来处理它。
但是，与（例如）现代前端框架相比，这几乎可以忽略不计。
如果您要使用绝对，最精简的网站，请完全避免。如果你想保护用户的隐私，不使用任何第三方脚本......但是，如果我们谈论的平均现代的网站上，有很多低悬的果实比gtag.js如果你遇到性能问题。
我还没有做过任何花哨的自动化测试或程序化的数字运算，但是我使用了带有Firebug插件的旧版Firefox和一对JS变量来告知执行GA代码前后的时差，这就是我所发现的。
下载了两件事：
ga.js是包含代码的JavaScript文件。这是9kb，因此初始下载可忽略不计，并且文件名不是动态的，因此在第一个请求后将被缓存。
一个35字节的gif文件，带有动态网址（通过查询字符串args），因此每次都需要这样做。35字节的下载量也可以忽略不计（firebug说我花了70ms来下载它）。
就执行时间而言，我的第一个带有干净浏览器缓存的请求平均每次大约330毫秒，随后的请求在35到130毫秒之间。
Google关于如何使用的传统说明。因此，即使浏览器会以某种方式异步加载外部JavaScript库，直到实际执行某些代码，它仍然会阻止页面加载。后面的异步指令不直接使用，但也许ga.jsdocument.write()document.write()document.write()insertBefore也阻止页面加载？
但是，Google将缓存的时间设置max-age为86,400秒（即1天，甚至设置为public，因此也适用于代理）。因此，由于许多站点加载了完全相同的Google脚本，因此通常会从缓存中获取JavaScript。不过，即使ga.js是缓存，只需点击刷新按钮往往会使浏览器问谷歌有关的任何变化。然后，就像当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日，星期日，格林尼治标准时间 快取控制：max-age = 604800，公开 服务器：高尔夫
请注意，许多用户单击重新加载即可在浏览器窗口中打开已经打开的新闻站点，论坛和博客，从而使许多浏览器处于阻塞状态，直到收到Google的响应为止。您多久刷新一次SO主页？当Google Analytics（分析）响应缓慢时，此类用户会立即注意到。（网上发布了许多解决方案来异步加载ga.js脚本，这对于这类网站特别有用，但可能不再比Google的更新说明要好。）
加载并执行JavaScript后，Web错误（跟踪图像）的实际加载应该是异步的。因此，除非页面使用以下命令，否则跟踪图像的加载不应阻止其他任何内容body.onload()。在这种情况下，如果Web错误无法立即加载，则单击重新加载实际上会使情况变得更糟，因为If-Modified-Since如上所述，单击重新加载还会使浏览器再次请求脚本。在重新加载之前，浏览器仅在等待Web错误，而在单击重新加载之后，浏览器也需要ga.js脚本的响应。
因此，使用Google Analytics（分析）的网站不应使用body.onload()。相反，应该使用类似jQuery的$（document）.ready（）或MooTools的domready event之类的东西。
另请参阅Google的功能概述，说明Google Analytics（分析）如何收集数据？，包括跟踪代码的工作原理。（这也正式表明Google会收集第一方Cookie的内容。即：您所访问的网站中的Cookie。）
更新：2009年12月，Google发布了异步版本。以上内容应该告诉每个人一定要升级，尽管升级并不能解决所有问题。
这真的取决于一天。我只是将其添加到博客中。我在加利福尼亚，离他们的主要数据中心非常近，使用快速低延迟的商业DSL，使用超频的i5，带有大量运行最新linux内核和稳定的Firefox的RAM。
这是页面加载示例：
仅google-analytics一项就增加了5秒的网络下载时间...以获得15Kb！
你可以看到blogger.com在300管辖34KB毫秒。快32倍！
另外，查看红线（代表onLoad事件，这意味着页面上没有更多的脚本正在执行，因此浏览器最终可以停止加载指示器/旋转/等）的方式……看向右多远是。那大概是3秒在那里发生的垃圾JavaScript处理。该行与资源下载栏的末尾相距很远很罕见。我已经调试完毕，这是1/3分析错误，2/3博客错误。...一个人会认为Google的东西很快。
编辑：
一些更多的数据。这是一个已缓存所有内容的请求。以上是第一次访问。
我已从上面删除了googleplus废话，原因有两个，我试图查看它们是否在慢速onLoad事件中发挥了作用（不是），并且它基本上没有用。
因此，借助此功能，您可以省去最少的网络时间。即使是在装有现代软件的快速计算机上，收费的Google Analytics（分析）+ Blogger占用的处理时间仍会使您的网页加载时间超过7秒。如果没有博客作者，只需检查此站点即可，加载资源后，红线开始出现0.5s的延迟。
使用FireBug和YSlow检查自己。但是，您会发现，GA的大小约为9KB（实际上，它的工作量相当大），而且有时加载速度也不会很快（出于某种原因，我不知道，我认为这可能是因为服务器有时“窒息”）
由于Ajax Samples上的性能问题，我们将其删除了，但是对于我们而言，再次以超快速度和响应速度为首要任务1、2和3
没什么大不了的。
对Google的调用（包括DNS查找，如果尚未缓存则加载Java脚本以及实际的跟踪程序本身会调用）应由客户端的浏览器在单独的线程中完成，以实际加载您的页面。当然，DNS查找将由底层系统完成，并且据我所知，不会算作浏览器中的查找（浏览器对每个站点使用的请求线程数有限制）。
除此之外，浏览器还将与所有其他嵌入式资源一起并行加载Google脚本，因此，在最坏的情况下，下载所有内容的时间可能会略有增加（在最坏的情况下）毫秒，这不是很明显。如果Google脚本是最后一次由浏览器加载的，或者页面上没有太多外部资源，或者页面的外部资源是由浏览器缓存的，或者Google的脚本是由浏览器缓存的（总的来说，这绝对是微不足道的，就像在页面上粘贴一张很小的图片一样（大致来说）。
大约只有一次，它可能会产生实际的不同，即您是否会在onLoad事件上触发某些行为（该事件等待外部资源加载），并且Google服务器处于关闭/慢速状态。后者不太可能经常发生，但是如果是这种情况，那么在下载脚本之前，onLoad甚至不会触发。无论如何，您都可以通过使用各种“当DOM加载时”事件来解决此问题，这些事件通常响应速度更快，因为您也不必等待自己的脚本/图像也以这种方式加载。
如果您真的担心页面加载时间的影响，请查看Firebug的“网络速度”部分，它将对此进行量化并绘制漂亮的图形。我仍然鼓励您自己完成此操作，即使其他人提供了您所要求的数据和基准，对于您自己的网站也将完全不同。
好吧，我已经在网上进行了广泛的搜索，研究和扩展。但是我没有发现任何支持或反对这一前提的统计数据。
但是，摘录自 http://www.ga-experts.com，声称Google Analytics（分析）会使您的网站变慢是一个神话。
错误，很好，也许略有增加，但是我们所谈论的是毫秒。Google Analytics（分析）通过页面标记进行工作，每当您向网页中添加更多内容时，它都会增加加载时间。但是，如果您遵循最佳做法（在标记之前添加
</body>标记），则页面将首先加载。另外，请记住，任何基于页面标签的Web分析软件包（大多数）都将以相同的方式工作
从上面的答案以及所有其他来源来看，我觉得页面底部包含了该脚本所导致的任何速度下降，但用户并未意识到。但是，如果谈到完整的页面加载，我们可能会说这会减慢页面加载时间。
如果您有更多信息，请发布更多信息；如果有，请发布更多数据。