wifi放大器速度
AMP has caused quite the stir from a philosophical perspective, but the technology hasn’t received as close of a look. A few weeks ago, Ferdy Christant wrote about the unfair advantage being given to AMP content through preloading. This got me wondering: how well does AMP really perform. I’ve seen folks, like Ferdy, analyze one or two pages, but I hadn’t seen anything looking at the broader picture…yet.
从哲学的角度来看，AMP引起了极大的轰动，但这项技术尚未引起人们的广泛关注。 几周前，费迪·克里斯坦(Ferdy Christant)写道， 通过预加载为AMP内容提供了不公平的优势 。 这让我想知道：AMP 实际表现如何。 我见过像Ferdy这样的人分析一到两页，但是从整体上看，我什么也没看见。
Evaluating the effectiveness of AMP from a performance standpoint is actually a little less straightforward than it sounds. You have to consider at least four different contexts:
从性能的角度评估AMP的有效性实际上比听起来容易得多。 您必须考虑至少四个不同的上下文：
How well does the AMP library perform when used as a standalone framework?
How well does AMP perform when the library is served using the AMP cache?
How well does AMP perform compared to the canonical article?
AMP在Google搜索中的效果如何？ (How well does AMP perform in the context of Google search?)
As Ferdy pointed out, when you click through to an AMP article from Google Search, it loads instantly—AMP’s little lightning bolt icon seems more than appropriate. But what you don’t see is that Google gets that instantaneous loading by actively preloading AMP documents in the background.
正如Ferdy所指出的那样，当您单击Google搜索中的AMP文章时，它会立即加载-AMP的小闪电图标似乎更合适。 但是您看不到的是Google通过在后台主动预加载AMP文档来获得即时加载。
In the case of the search carousel, it’s literally an iframe that gets populated with the entirety of the AMP document. If you do end up clicking on that AMP page, it’s already been downloaded in the background and as a result, it displays right away.
就搜索轮播而言，它实际上是一个iframe，其中填充了整个AMP文档。 如果您确实单击了该AMP页面，则该页面已经在后台下载，因此它会立即显示。
In the context of Google search, then, AMP performs remarkably well. Then again, so would any page that was preloaded in the background before you navigated to it. The only performance benefit AMP has in this context is the headstart that Google gives it.
因此，在Google搜索的背景下，AMP的表现非常出色。 再一次，导航到该页面之前在后台预加载的任何页面也将如此。 在这种情况下，AMP唯一的性能优势就是Google给予它的领先优势 。
In other words, evaluating AMP’s performance based on how those pages load in search results tells us nothing about the effectiveness of AMP itself, but rather the effectiveness of preloading content.
换句话说，根据这些页面在搜索结果中的加载方式来评估AMP的性能，并不能说明AMP本身的有效性，而只能告诉我们预加载内容的有效性。
AMP库用作独立框架时的性能如何？ (How well does the AMP library perform when used as a standalone framework?)
In Ferdy’s post, he analyzed a page from Scientas. He discovered that without the preloading, it’s far from instant. On a simulated 3G connection, the Scientas AMP article presents you with a blank white screen for 3.3 seconds.
在Ferdy的帖子中，他分析了Scientas的页面。 他发现，没有预加载，它不是即时的。 在模拟的3G连接上，Scientas AMP文章为您提供了3.3秒的空白白屏。
Now, you might be thinking, that’s just one single page. There’s a lot of variability and it’s possible Scientas is a one-off example. Those are fair concerns so let’s dig a little deeper.
现在，您可能会想，那只是一页。 可变性很多，Scientas可能是一个例子。 这些是令人担忧的问题，因此让我们深入探讨。
The first thing I did was browse the news. I don’t recommend this to anyone, but there was no way around it.
我做的第一件事是浏览新闻。 我不建议任何人这样做，但是没有办法解决。
Anytime I found an AMP article, I dropped the URL in a spreadsheet. It didn’t matter what the topic was or who the publisher was: if it was AMP, it got included. The only filtering I did was to ensure that I tested no more than two URL’s from any one domain.
每当我找到AMP文章时，都会将该URL放在电子表格中。 主题是什么或发布者是谁都没有关系：如果是AMP，则将其包括在内。 我所做的唯一过滤是确保从任何一个域测试的URL最多不超过两个。
In the end, after that filtering, I came up with a list of 50 different AMP articles. I ran these through WebPageTest over a simulated 3G connection using a Nexus 5. Each page was built with AMP, but each page was also loaded from the origin server for this test.
最后，经过过滤，我得出了50篇不同的AMP文章的列表。 我使用Nexus 5在模拟的3G连接上通过WebPageTest来运行这些页面。每个页面都是使用AMP构建的，但是每个页面也都从原始服务器加载以进行此测试。
AMP is comprised of three basic parts:
AMP包含三个基本部分：
- AMP HTML AMP HTML
- AMP JS AMP JS
- AMP Cache AMP缓存
When we talk about the AMP library, we’re talking about AMP JS and AMP HTML combined. AMP HTML is both a subset of HTML (there are restrictions on what you can and can’t use) and an augmentation of it (AMP HTML includes a number of custom AMP components and properties). AMP JS is the library that is used to give you those custom elements as well as handles a variety of optimizations for AMP-based documents. Since the foundation is HTML, CSS, and JS, you can absolutely build a document using the AMP library without using the Google AMP Cache.
当我们谈论AMP库时，我们谈论的是AMP JS和AMP HTML的结合。 AMP HTML既是HTML的子集(对可以使用和不能使用的内容有所限制)，又是HTML的扩充(AMP HTML包括许多自定义AMP组件和属性)。 AMP JS是用于为您提供这些自定义元素以及处理基于AMP的文档的各种优化的库。 由于基础是HTML，CSS和JS，因此您绝对可以使用AMP库来构建文档，而无需使用Google AMP缓存。
The AMP library is supposed to help ensure a certain level of consistency with regards to performance. It does this job well, for the most part.
AMP库应该有助于确保性能方面的一定程度的一致性。 在大多数情况下，它都能很好地完成这项工作。
The bulk of the pages test landed within a reasonable range of each other. There was, however, some deviance on both ends of the spectrum: the minimum values were pretty low and the maximum values frightening high.
测试的大部分页面落在彼此的合理范围内。 但是，频谱的两端都有一些偏差：最小值非常低，最大值令人恐惧。
| Metric | Min | Max | Median | 90th Percentile |
|---|---|---|---|---|
| Start Render | 1,765ms | 8,130ms | 4,617ms | 5,788ms |
| Visually Complete | 4,604ms | 35,096ms | 7,475ms | 21,432ms |
| Speed Index | 3729 | 16230 | 6171 | 10144 |
| Weight | 273kb | 10,385kb | 905kb | 1,553kb |
| Requests | 14 | 308 | 61 | 151 |
| 公制 | 敏 | 最高 | 中位数 | 90％ |
|---|---|---|---|---|
| 开始渲染 | 1,765毫秒 | 8,130毫秒 | 4,617毫秒 | 5,788毫秒 |
| 外观完整 | 4,604毫秒 | 35,096毫秒 | 7,475毫秒 | 21,432毫秒 |
| 速度指数 | 3729 | 16230 | 6171 | 10144 |
| 重量 | 273kb | 10,385kb | 905kb | 1,553kb |
| 要求 | 14 | 308 | 61 | 151 |
Most of the time, AMP’s performance is relatively predictable. However, the numbers also showed that because a page is a valid AMP document, that is not a 100% guarantee that the site will be fast or lightweight. As with pages built with any technology, it’s entirely possible to build an AMP document that is slow and heavy.
在大多数情况下，AMP的性能是相对可预测的。 但是，数字还表明，由于页面是有效的AMP文档，因此不能100％保证该网站快速或轻量。 与使用任何技术构建的页面一样，完全可以构建缓慢而繁琐的AMP文档。
Any claim that AMP ensures a certain level of performance depends both on how forgiving you are of the extremes, and on what your definition of “performant” is. If you were to try and build your entire site using AMP, you should be aware that while it’s not likely to end up too bloated, it’s also not going to end up blowing anyone’s mind for its speed straight of the box. It’s still going to require some work.
关于AMP确保一定水平的性能的任何主张都取决于您对极端情况的宽容程度以及您对“绩效”的定义。 如果您要尝试使用AMP构建整个站点，则应注意，尽管它最终可能不会显得过于肿，但也不会因为其速度的迅捷而最终引起任何人的注意。 它仍然需要一些工作。
At least that’s the case when we’re talking about the library itself. Perhaps the AMP cache will provide a bit of a boost.
至少在谈论库本身时就是这种情况。 也许AMP缓存会有所助益。
使用AMP缓存为库提供服务时，AMP的性能如何？ (How well does AMP perform when the library is served using the AMP cache?)
The AMP library itself helps, but not to the degree we would think. Let’s see if the Google cache puts it over the top.
AMP库本身可以提供帮助，但程度不尽人意。 让我们看看Google缓存是否将其放在顶部。
The Google AMP Cache is a CDN for delivering AMP documents. It caches AMP documents and—like most CDN’s—applies a series of optimizations to the content. The cache also provides a validation system to ensure that the document is a valid AMP document. When you see AMP served, for example, through Google’s search carousel, it’s being served on the Google AMP Cache.
Google AMP缓存是用于传递AMP文档的CDN。 它缓存AMP文档，并且像大多数CDN一样，对内容进行一系列优化。 缓存还提供了一个验证系统，以确保该文档是有效的AMP文档。 例如，当您看到AMP通过Google的搜索轮播投放时，就会在Google AMP缓存中投放。
I ran the same 50 pages through WebPagetest again. This time, I loaded each page from the Google AMP CDN. Pat Meenan was kind enough to share a script for WebPagetest that would pre-warm the connections to the Google CDN so that the experience would more closely resemble what you would expect in the real world.
我再次通过WebPagetest运行了相同的50页。 这次，我从Google AMP CDN加载了每个页面。 Pat Meenan非常乐于分享WebPagetest的脚本，该脚本将预热与Google CDN的连接，以便使体验与您在现实世界中的期望更加相似。
logdata 0
navigate https://cdn.ampproject.org/c/www.webpagetest.org/amp.html
logdata 1
navigate %URL%When served from the AMP Cache, AMP pages get a noticeable boost in performance across all metrics.
当从AMP缓存提供服务时，AMP页面在所有指标上的性能都有明显提高。
| Metric | Min | Max | Median | 90th Percentile |
|---|---|---|---|---|
| Start Render | 1,427ms | 4,828ms | 1,933ms | 2,291ms |
| Visually Complete | 2,036ms | 36,001ms | 4,924ms | 19,626ms |
| Speed Index | 1966 | 18677 | 3277 | 9004 |
| Weight | 177kb | 10,749kb | 775kb | 2,079kb |
| Requests | 13 | 305 | 53 | 218 |
| 公制 | 敏 | 最高 | 中位数 | 90％ |
|---|---|---|---|---|
| 开始渲染 | 1,427毫秒 | 4,828毫秒 | 1,933ms | 2,291ms |
| 外观完整 | 2,036毫秒 | 36,001毫秒 | 4,924毫秒 | 19,626毫秒 |
| 速度指数 | 1966年 | 18677 | 3277 | 9004 |
| 重量 | 177kb | 10,749kb | 775kb | 2,079kb |
| 要求 | 13 | 305 | 53 | 218 |
Overall the benefits of the cache are pretty substantial. On the high-end of things, the performance is still pretty miserable (the slightly higher max’s here mostly have to do with differences in the ads pulled in from one test to another). But that middle range where most of the AMP documents live becomes faster across the board.
总体而言，缓存的好处非常可观。 从高端的角度来看，效果仍然很糟糕(此处的最高最高值很大程度上与从一项测试拉到另一项测试中的广告差异有关)。 但是，大多数AMP文档所处的中间范围将变得更快。
The improvement is not surprising given the various performance optimizations the CDN automates, including:
考虑到CDN自动化的各种性能优化，这一改进不足为奇，其中包括：
- Caching images and fonts 缓存图像和字体
- Restricting maximum image sizes 限制最大图像尺寸
- Compressing images on the fly, as well as creating additional sizes and adding srcset to serve those sizes 动态压缩图像，以及创建其他大小并添加srcset以提供这些大小
- Uses HTTP/2 and HTTPS 使用HTTP / 2和HTTPS
- Strips out HTML comments 去除HTML注释
Automates inclusion of resource hints such as
dns-prefetchandpreconnect自动包含诸如
dns-prefetch和preconnect类的资源提示
Once again, it’s worth noting that none of these optimizations requires that you use AMP. Every last one of these can be done by most major CDN providers. You could even automate all of these optimizations yourself by using a build process.
再次值得注意的是，这些优化都不要求您使用AMP。 大多数主要的CDN提供商都可以完成其中的最后一项。 您甚至可以自己使用构建过程来自动化所有这些优化。
I don’t say that to take away from Google’s cache in any way, just to note that you can, and should, be using these same practices regardless of if you use AMP or not. Nothing here is unique to AMP or even the AMP cache.
我并不是说要以任何方式利用Google的缓存，只是要注意，无论是否使用AMP，您都可以而且应该使用这些相同的做法。 AMP甚至AMP缓存都不是唯一的。
与规范文章相比，AMP的表现如何？ (How well does AMP perform compared to the canonical article?)
So far we’ve seen that the AMP library by itself ensures a moderate level of performance and that the cache takes it to another level with its optimizations.
到目前为止，我们已经看到AMP库本身可以确保中等水平的性能，并且缓存通过其优化将其提升到另一个水平。
One of the arguments put forward for AMP is that it makes it easier to have a performant site without the need to be “an expert”. While I’d quibble a bit with whether labeling many of the results I found “performant”, it does make sense to compare these AMP documents with their canonical equivalents.
AMP提出的论点之一是，无需成为“专家”就可以更轻松地拥有表演场所。 尽管我对是否标记许多我发现为“性能良好”的结果有些疑问，但是将这些AMP文档与其规范的等效文档进行比较确实有意义。
For the next round of testing, I found the canonical version of each page and tested that as well, under the same conditions. It turns out that while the AMP documents I tested were a mixed bag, they do out-perform their non-AMP equivalents more often than not (hey publishers, call me).
对于下一轮测试，我找到了每个页面的规范版本，并在相同条件下进行了测试。 事实证明，尽管我测试的AMP文档是一堆混杂的东西，但它们的表现确实好于非AMP同类产品(嘿，出版商， 叫我 )。
| Metric | Min | Max | Median | 90th Percentile |
|---|---|---|---|---|
| Start Render | 1,763ms | 7,469ms | 4,227ms | 6,298ms |
| Visually Complete | 4,231ms | 108,006ms | 20,418ms | 54,546ms |
| Speed Index | 3332 | 45362 | 8152 | 21495 |
| Weight | 251kb | 11,013kb | 2,762kb | 5,229kb |
| Requests | 24 | 1743 | 318 | 647 |
| 公制 | 敏 | 最高 | 中位数 | 90％ |
|---|---|---|---|---|
| 开始渲染 | 1,763ms | 7,469毫秒 | 4,227毫秒 | 6,298毫秒 |
| 外观完整 | 4,231毫秒 | 108,006毫秒 | 20,418毫秒 | 54,546毫秒 |
| 速度指数 | 3332 | 45362 | 8152 | 21495 |
| 重量 | 251kb | 11,013kb | 2,762kb | 5,229kb |
| 要求 | 24 | 1743 | 318 | 647 |
Let’s forget the Google cache for a moment and put the AMP library back on even footing with the canonical article page.
让我们暂时忘记Google缓存，并通过规范的文章页面使AMP库恢复稳定。
Metrics like start render and Speed Index didn’t see much of a benefit from the AMP library. In fact, Start Render times are consistently slower in AMP documents.
诸如开始渲染和速度索引之类的指标并未从AMP库中获得太多好处。 实际上，AMP文件中的“开始渲染”时间始终较慢 。
That’s not too much of a surprise. As mentioned above, AMP documents use the AMP JS library to handle a lot of the optimizations and resource loading. Anytime you rely on that much JavaScript for the display of your page, render metrics are going to take a hit. It isn’t until the AMP cache comes into play that AMP pulls back ahead for Start Render and Speed Index.
这不足为奇。 如上所述，AMP文档使用AMP JS库来处理许多优化和资源加载。 每当您依赖大量JavaScript来显示页面时，渲染指标都会受到影响。 直到AMP缓存起作用时，AMP才将Start Render和Speed Index撤回。
For the other metrics though, AMP is the clear winner over the canonical version.
但是，对于其他指标，AMP明显胜过规范版本。
改善性能…。但是对于谁呢？ (Improving performance….but for who?)
The verdict on AMP’s effectiveness is a little mixed. On the one hand, on an even playing field, AMP documents don’t necessarily mean a page is performant. There’s no guarantee that an AMP document will not be slow and chew right through your data.
关于AMP的效力的结论有些参差不齐。 一方面，在公平的竞争环境中，AMP文档不一定表示页面性能良好。 不能保证AMP文档不会变慢并且不会影响您的数据。
On the other hand, it does appear that AMP documents tend to be faster than their counterparts. AMP’s promise of improved distribution cuts a lot of red tape. Suddenly publishers who have a hard time saying no to third-party scripts for their canonical pages are more willing (or at least, made to) reduce them dramatically for their AMP counterparts.
另一方面，AMP文件似乎比它们的同行更快。 AMP承诺改善分销渠道的承诺削减了很多繁文tape节。 突然之间，很难在标准网页上拒绝第三方脚本的发布商更愿意(或至少是要)为AMP同行大幅减少这些脚本。
AMP’s biggest advantage isn’t the library—you can beat that on your own. It isn’t the AMP cache—you can get many of those optimizations through a good build script, and all of them through a decent CDN provider. That’s not to say there aren’t some really smart things happening in the AMP JS library or the cache—there are. It’s just not what makes the biggest difference from a performance perspective.
AMP的最大优势不是库-您可以自己击败它。 它不是AMP缓存-您可以通过一个好的构建脚本来获得许多优化，而所有这些优化都可以通过一个不错的CDN提供程序进行。 这并不是说AMP JS库或缓存中没有发生任何真正聪明的事情，而是有。 从性能的角度来看，这并不是最大的区别。
AMP’s biggest advantage is the restrictions it draws on how much stuff you can cram into a single page.
AMP的最大优势在于它限制了您可以在单个页面中填充多少内容 。
For example. here are the waterfalls showing all the requests for the same article page written to AMP requirements (the right) versus the canonical version (the left). Apologies to your scroll bar.
例如。 以下是瀑布图，显示了针对同一文章页面的所有请求，这些请求都已写入AMP要求(右)与规范版本(左)。 对您的滚动条表示歉意。
Comparing the waterfalls for the canonical version of an article (left) and AMP version (right). AMP’s restrictions make for a lot fewer requests.
比较文章的规范版本(左)和AMP版本(右)的瀑布。 AMP的限制使请求减少了很多。
The 90th percentile weight for the canonical version is 5,229kb. The 90th percentile weight for AMP documents served from the same origin is 1,553kb— a savings of around 70% in page weight. The 90th percentile request count for the canonical version is 647, for AMP documents it’s 151. That’s a reduction of nearly 77%.
规范版本的第90个百分位数权重是5,229kb。 来自相同来源的AMP文件的第90个百分位重量为1,553kb，这使页面重量节省了约70％。 规范版本的第90个百分位请求计数是647，而AMP文档的请求百分位数是151。减少了近77％。
AMP’s restrictions mean less stuff. It’s a concession publishers are willing to make in exchange for the enhanced distribution Google provides, but that they hesitate to make for their canonical versions.
AMP的限制意味着更少的东西。 发布商愿意做出让步，以换取Google提供的增强版本，但他们不愿为自己的规范版本做出选择。
If we’re grading AMP on the goal of making the web faster, the evidence isn’t particularly compelling. Every single one of these publishers has an AMP version of these articles in addition to a non-AMP version.
如果我们以提高网络速度为目标对AMP进行分级，则证据并不是特别引人注目。 除了非AMP版本外 ，这些发布者中的每一个都有这些文章的AMP版本。
Every. Single. One.
每一个 单。 之一。
And for more often than not, these non-AMP versions are heavy and slow. If you’re reading news on these sites and you didn’t click through specifically to the AMP library, then AMP hasn’t done a single thing to improve your experience. AMP hasn’t solved the core problem; it has merely hidden it a little bit.
而且，这些非AMP版本通常又笨又慢。 如果您在这些站点上阅读新闻，并且没有直接单击AMP库，则AMP并没有做任何事情来改善您的体验。 AMP尚未解决核心问题。 它只是将其隐藏了一点。
Time will tell if this will change. Perhaps, like the original move from m-dot sites to responsive sites, publishers are still kicking the tires on a slow rollout. But right now, the incentives being placed on AMP content seem to be accomplishing exactly what you would think: they’re incentivizing AMP, not performance.
时间会证明这是否会改变。 也许，就像最初从m-dot网站迁移到响应式网站一样，发布商仍在为缓慢的推出而烦恼。 但是现在，放在AMP内容上的激励措施似乎正在完全实现您的想法：它们是在激励AMP，而不是性能。
翻译自: https://timkadlec.com/remembers/2018-03-19-how-fast-is-amp-really/
wifi放大器速度
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
