谷歌amp 下拉
While writing the article for David Walsh’s blog I had posted a version of the article on Medium to have @cramforce, the lead on Google AMP, answer the questions brought up. Here is a link to the article where he posted those answers: bit.ly/1VCLBr0
在为David Walsh的博客撰写文章时，我在Medium上发布了该文章的一个版本，让Google AMP的负责人@cramforce回答提出的问题。 这是他发布这些答案的文章的链接： bit.ly/1VCLBr0
As developers we know that site speed is extremely important. In recent years, the developer community has created and supported new browser specifications and techniques to enhance site speed. So when I heard that Google was launching the Accelerated Mobile Pages (AMP) project I got really excited and wanted to immediately begin using the standards Google set to make sure that the sites at Aristotle Interactive were performing the best they could.
作为开发人员，我们知道站点速度非常重要。 近年来，开发人员社区创建并支持了新的浏览器规范和技术，以提高站点速度。 因此，当我听说Google正在启动“加速的移动页面(AMP)”项目时，我感到非常兴奋，并希望立即开始使用Google设置的标准，以确保Aristotle Interactive的网站表现最佳。
The developers, designers, and project managers at Aristotle have worked very hard over the last year to create a site speed specification document and performance budget to ensure that every website we build is fast without sacrificing design or functionality. Naturally, we wanted to use AMP to make our clients' sites even faster, but before we started changing code we wanted to do some testing to explore the benefits of using AMP, aside from the SEO boost. The tests raised a question among our team and we wanted to post this question out to the community to start a discussion: Is AMP really needed to increase site speed?
亚里斯多德的开发人员，设计师和项目经理在过去的一年中一直非常努力地创建站点速度规范文档和性能预算，以确保我们建立的每个网站都快速而又不牺牲设计或功能。 自然，我们希望使用AMP来提高客户网站的速度，但是在开始更改代码之前，我们希望进行一些测试以探索使用AMP的好处，除了SEO提升。 测试在我们的团队中提出了一个问题，我们希望将此问题发布给社区以开始讨论：AMP是否真的需要提高站点速度？
First, let's look at the results of the tests. We used a tool called WebPageTest to check the site speed of every page below. We tested the pages using an iPhone 6 running iOS 9, simulating a 3G connection (1.6 Mbps/768 Kbps 300ms RTT). We tested each page 5 times and have shown the median result in this article. Our performance team at Aristotle uses 3 metrics that have proven to measure site speed and user experience: Time to First Byte, Speed Index (Perceived Performance), and Page Size. We tested pages that were displayed on the AMP demo link that Google provided (http://g.co/amp), AMPs "in the wild" that we found through Google searches, and then a few sites Aristotle has recently created.
首先，让我们看一下测试结果。 我们使用了一个名为WebPageTest的工具来检查下面每个页面的网站速度。 我们使用运行iOS 9的iPhone 6测试了页面，模拟了3G连接(1.6 Mbps / 768 Kbps 300ms RTT)。 我们对每页进行了5次测试，并在本文中显示了中位数结果。 我们在亚里斯多德的绩效团队使用了3个指标，这些指标已被证明可以衡量站点速度和用户体验：第一个字节的时间，速度指数(感知的性能)和页面大小。 我们测试了Google提供的AMP演示链接( http://g.co/amp )上显示的页面，以及通过Google搜索发现的“野外” AMP，然后对Aristotle最近创建了一些站点。
Google AMP演示结果 (Google AMP Demo Results)
| Site | Time to First Byte | Speed Index | Page Size | WPT Test |
|---|---|---|---|---|
| NY Times | B | 6.44 secs | 649 kb | link |
| USA Today | B | 7.42 secs | 1,962 kb | link |
| New York Post | A | 6.72 secs | 443 kb | link |
| Mashable | A | 6.43 secs | 593 kb | link |
| The Verge | A | 5.69 secs | 465 kb | link |
| 现场 | 到第一个字节的时间 | 速度指数 | 页面大小 | WPT测试 |
|---|---|---|---|---|
| 纽约时报 | 乙 | 6.44秒 | 649 KB | 链接 |
| 今日美国 | 乙 | 7.42秒 | 1,962 kb | 链接 |
| 纽约邮报 | 一个 | 6.72秒 | 443 KB | 链接 |
| 可混搭 | 一个 | 6.43秒 | 593 kb | 链接 |
| 边缘 | 一个 | 5.69秒 | 465 kb | 链接 |
“野外” AMP结果 ("In the Wild" AMP Results)
| Site | Time to First Byte | Speed Index | Page Size | WPT Test |
|---|---|---|---|---|
| Buzzfeed | D | 5.53 secs | 3,882 kb | link |
| Wordpress Blog | A | 5.78 secs | 324 kb | link |
| SE Round Table | A | 5.60 secs | 1,007 kb | link |
| BBC | A | 5.58 secs | 389 kb | link |
| 现场 | 到第一个字节的时间 | 速度指数 | 页面大小 | WPT测试 |
|---|---|---|---|---|
| 嗡嗡声 | d | 5.53秒 | 3,882 kb | 链接 |
| WordPress博客 | 一个 | 5.78秒 | 324 KB | 链接 |
| SE圆桌会议 | 一个 | 5.60秒 | 1,007 kb | 链接 |
| 英国广播公司 | 一个 | 5.58秒 | 389 KB | 链接 |
亚里士多德互动结果 (Aristotle Interactive Results)
| Site | Time to First Byte | Speed Index | Page Size | WPT Test |
|---|---|---|---|---|
| Fort Smith * | A | 5.77 secs | 893 kb | link |
| Little Rock * | A | 8.30 secs | 754 kb | link |
| ASPSF | A | 7.24 secs | 411 kb | link |
| Beacon Legal Group * | A | 6.78 secs | 761 kb | link |
| 现场 | 到第一个字节的时间 | 速度指数 | 页面大小 | WPT测试 |
|---|---|---|---|---|
| 史密斯堡* | 一个 | 5.77秒 | 893 kb | 链接 |
| 小石头 * | 一个 | 8.30秒 | 754 KB | 链接 |
| ASPSF | 一个 | 7.24秒 | 411 kb | 链接 |
| 信标法律小组* | 一个 | 6.78秒 | 761 KB | 链接 |
* means the redesigned site is nearly launched and a link is not available.
*表示重新设计的网站即将启动，并且链接不可用。
There is a difference between the content on the sites Aristotle has created and the Google AMPs. Our sites are tourism sites while the AMPs are news articles. We expected the tourism sites to be much larger in size and slower in speed considering the amount of images and Javascript used to create interactive experiences but found that wasn't always the case.
亚里斯多德创建的网站上的内容与Google AMP上的内容有所不同。 我们的站点是旅游站点，而AMP是新闻报道。 考虑到用于创建交互式体验的图像和Javascript的数量，我们预计旅游景点的规模会大得多，速度会慢一些，但事实并非总是如此。
问题 (Questions)
- The biggest question: why are pages such as Buzzfeed and USA Today boosted and preloaded on a user's device, but not pages like Fort Smith and ASPSF (unless they were to use AMP)? AMPs appear to load quickly because there are some assets that are preloaded from the page. Doesn't it make most sense to give an SEO boost pages that inherently meet a standard? We should reward the pages (and publishers) that build site speed into their site as a feature. 最大的问题：为什么像Buzzfeed和“今日美国”这样的页面在用户的设备上得到了增强和预加载，却没有如史密斯堡和ASPSF这样的页面(除非它们要使用AMP)？ AMP似乎加载很快，因为该页面中已预先加载了一些资产。 提供本质上符合标准的SEO提升页面不是最有意义吗？ 我们应该奖励那些将网站速度提升到他们网站的功能的页面(和发布者)。
- Since there are assets that get preloaded from the Google search results page, is there a cap on how many kilobytes get downloaded from there? Sites like Buzzfeed that appear to abuse visitors' data usage could be a problem if you are preloading assets. 由于有些资产是从Google搜索结果页上预先加载的，因此从那里下载多少千字节是否有上限？ 如果您要预加载资产，则Buzzfeed之类的网站似乎会滥用访问者的数据，这可能是一个问题。
It appears that some sources are saying that publishers should "have to maintain at least two versions of any article page: The original version of your article page that users will typically see, and the AMP version of that page." Since most SEO sources recommend a responsive site over a separate mobile site and most sites have spent a lot to make that happen, doesn't it seem like taking 2 steps back to have a separate AMP site? This could get complicated when you consider Facebook Instant Articles and other services that want to accomplish the same goal.
似乎有些消息人士说，发布者应该“至少维护任何文章页面的两个版本：用户通常会看到的文章页面的原始版本，以及该页面的AMP版本”。 由于大多数SEO来源建议在单独的移动网站上使用响应型网站，并且大多数网站都花了很多钱才能做到这一点，所以似乎不应该再花2步才能拥有一个单独的AMP网站？ 当您考虑要实现相同目标的Facebook Instant Articles和其他服务时，这可能会变得复杂。
- There are a few nice features that AMP offers, such as how images and assets are loaded and displayed, but wouldn't it be better to standardize a way of doing these things rather than doing it a different way for each service? AMP提供了一些不错的功能，例如如何加载和显示图像和资产，但是标准化一种做这些事情的方式而不是为每种服务采用不同的方式会更好吗？
Services like Google AMP and Facebook Instant Articles appear to be setting themselves up to award publishers that use "proprietary" markup (meaning not standardized markup), rather than awarding publishers who build their sites with performance as the foundation. Is that really the web we want to promote? What are your thoughts on Google AMP and other services like it?
诸如Google AMP和Facebook Instant Articles之类的服务似乎正在设置自己，以奖励使用“专有”标记(即非标准标记)的发布者，而不是奖励以性能为基础构建网站的发布者。 那真的是我们要推广的网络吗？ 您对Google AMP和其他类似服务有何看法？
Share your thoughts and get others involved by sharing this post.
分享您的想法，并通过分享此信息让其他人参与。
翻译自: https://davidwalsh.name/questions-google-amp
谷歌amp 下拉