chrome打开页面_了解Chrome Lite页面

chrome打开页面

Google formally announced Lite Pages the other day and the response has been….let’s say mixed. Understandably so.

Google在前几天正式宣布了Lite Pages，而回应却是……。可以理解的是。

The announcement post was a fairly typical product announcement post which is to say it was light (no pun intended) on the technical details and leaves a lot of open questions. Sometimes that’s fine. But in this case, the announcement has to deal with Google making changes to HTTPS content which, as you would expect, makes folks a little more nervous. Some more detail would have been nice.

公告栏是一个相当典型的产品公告栏，也就是说，它对技术细节比较轻(无双关语)，并且留下了许多悬而未决的问题。有时候很好。但是在这种情况下，该公告必须与Google处理HTTPS内容的更改有关，正如您所期望的那样，这会使人们更加紧张。一些更多的细节会很好。

我们所知道的 (What We Know)

Despite the vague announcement, between conversations with Chrome folks over the years, digging around and some general knowledge of how proxy services work, we can put together a decent chunk of the puzzle.

尽管发布了模糊的声明，但多年来与Chrome员工之间的对话，深入探讨以及关于代理服务如何工作的一些常识，我们仍可以解决这一难题。

精简版页面不是新的。好吧，不完全是。 (Lite pages aren’t new. Well, not exactly.)

Chrome has offered a proxy service through its browser for several years now. In that time it’s undergone a few different rebrands.

Chrome浏览器已通过其浏览器提供代理服务已有几年了。在那个时候，它经历了几个不同的品牌重塑。

The first name I’m familiar with was Flywheel. That’s what it was called back in 2015 when the team working on the service wrote up a detailed paper about the optimizations Flywheel applied, and why.

我熟悉的名字是飞轮。这就是2015年的名字，当时负责该服务的团队撰写了详细的论文，介绍了Flywheel应用的优化及其原因。

Flywheel wasn’t used as a public name for long, if at all. (I honestly don’t remember if they ever talked much about it in public as Flywheel.) It’s not exactly intuitive. Data Saver was the more common name and the one that has continued to be used to date.

飞轮很久没有被用作公共名称了。 (老实说，我不记得他们是否曾经像Flywheel那样在公众场合谈论过太多。)这不是很直观。 Data Saver是更常见的名称，并且一直沿用至今。

You can think of Lite pages as an extension of Data Saver for when loading conditions are especially bad. Data Saver still does its optimizations, just like always. But when conditions are especially bad (2G-like connections or longer than 5 seconds until First Contentful Paint), Lite pages will kick in and potentially provide additional interventions (more on those later).

当加载条件特别糟糕时，您可以将Lite页面视为Data Saver的扩展。 Data Saver仍然像往常一样进行优化。但是，当情况特别糟糕时(类似于2G的连接，或者直到First Contentful Paint超过5秒钟)，Lite页面将启动，并可能提供其他干预措施(稍后会进行更多介绍)。

Perhaps the most significant difference between the Lite pages announcement and Data Saver as we knew it is that Lite pages work over HTTPS traffic. Data Saver was always HTTP only. Good for security, not great for anyone who needed data savings on an increasingly HTTPS-driven web.

正如我们所知，Lite页面公告和Data Saver之间的最大区别可能是Lite页面通过HTTPS流量工作。 Data Saver始终仅是HTTP。对安全性有好处，但对于那些需要在越来越多的HTTPS驱动的Web上节省数据的人来说并不是一个好选择。

数据保护程序！==保存数据 (Data Saver !== Save-Data)

One big source of confusion comes from the very similarly named Data Saver mode and the Save-Data header.

造成混淆的一大原因来自名称非常相似的“数据保护程序”模式和“保存数据”标头。

Save-Data is a header that can be passed along by any browser or service when a user has explicitly requested an experience that uses less data. Save-Data can, and should, be used by developers to help reduce page weight regardless of what the browser may or may not be doing.

当用户明确要求使用较少数据的体验时， Save-Data是可以由任何浏览器或服务传递的标头。开发人员可以并且应该使用Save-Data来帮助减轻页面重量，无论浏览器可能在做什么或不做什么。

In theory, by itself, the Save-Data header doesn’t necessarily indicate that a proxy service is being used. A browser could ask a user if they want less data, indicate that decision to developers with the Save-Data header and leave all the work up to the developer.

从理论上说， Save-Data标头本身并不一定表示正在使用代理服务。浏览器可以询问用户是否需要更少的数据，并通过Save-Data标头向开发人员指示该决定，并将所有工作留给开发人员。

In practice, that is not the case. Right now, to my knowledge, the Save-Data header is passed by Chrome when the Data Saver mode is enabled, Yandex and Opera Turbo. In other words, at the moment, Save-Data is only ever being seen by developers when a browser is doing some sort of proxy service to optimize the page.

实际上，情况并非如此。据我所知，当启用“数据保护程序”模式(Yandex和Opera Turbo)时，Chrome会传递Save-Data标头。换句话说，目前，只有在浏览器正在执行某种代理服务来优化页面时，开发人员才能看到Save-Data 。

Data Saver is Chrome’s proxy service. Users can opt into the Data Saver service by turning the feature on in the settings on Chrome for Android, or by installing an extension on Chrome for Desktop.

Data Saver是Chrome的代理服务。用户可以通过在Android版Chrome上的设置中启用该功能或在Chrome for Desktop上安装扩展程序来选择使用Data Saver服务。

When Data Saver mode is enabled, Chrome will attempt to make optimizations to the page to reduce data usage and improve overall performance. Traditionally, these optimizations have only applied to HTTP traffic—something that has changed now with Lite pages.

启用“数据保护程序”模式后，Chrome会尝试对页面进行优化，以减少数据使用量并提高整体性能。传统上，这些优化仅适用于HTTP流量-精简版页面现已有所改变。

If the Data Saver mode is enabled, Chrome passes along the Save-Data header with each request, as a responsible proxy service should. That’s the only relationship between the two.

如果启用了数据保护程序模式，Chrome会按照负责的代理服务的要求Save-Data每个请求都传递到Save-Data标头。那是两者之间的唯一关系。

精简版页面！== AMP (Lite Pages !== AMP)

Lite pages are also in no way related to AMP. AMP is a framework you have to build your site in to reap any benefit from. Lite pages are optimizations and interventions that get applied to your current site. Google’s servers are still involved, by as a proxy service forwarding the initial request along. Your URL’s aren’t tampered with in any way.

精简版页面也与AMP毫无关系。 AMP是一个框架，您必须在其中构建站点才能从中受益。精简版页面是应用于当前网站的优化和干预措施。 Google的服务器仍然作为代理服务来转发初始请求，因此仍然参与其中。您的网址不会受到任何篡改。

精简版页面仅在特定情况下适用 (Lite Pages are only applied in specific situations)

The release post was vague on details but fairly clear on when the optimizations would be applied. In addition to the requirement that Data Saver mode is enabled, Lite pages will be applied:

该发布的帖子在细节上含糊不清，但在何时应用优化方面相当明确。除了要求启用“数据保护程序”模式之外，还将应用精简版页面：

…when the network’s effective connection type is “2G” or “slow-2G,” or when Chrome estimates the page load will take more than 5 seconds to reach first contentful paint given current network conditions and device capabilities.

…当网络的有效连接类型为“ 2G”或“慢速2G”时，或当Chrome估计在当前网络条件和设备功能下，页面加载将需要5秒钟以上的时间才能达到令人满意的效果。

In other words, the optimizations are likely going to be applied to only a subset of a given site’s traffic and only on slow pages. If you’ve done a good job of optimizing your site for less than ideal network scenarios and kept it lightweight, you’re unlikely to see it impact your site at all.

换句话说，优化可能只应用于给定站点流量的一部分，并且仅应用于慢速页面。如果您已经针对不理想的网络方案做了出色的网站优化工作，并且保持网站的轻量级，那么您几乎看不到它会影响您的网站。

这些优化尚不清楚，并且可能很流畅。 (The optimizations are a little unclear, and likely fluid.)

The original Flywheel paper detailed some basic optimizations that the proxy service would apply when appropriate, including:

Flywheel的原始论文详细介绍了代理服务在适当时将应用的一些基本优化，包括：

Transcoding images
转码图片
Ensuring text-based resources are compressed
确保压缩基于文本的资源
Minifying JS and CSS
缩小JS和CSS
Providing lightweight error pages when the user is unlikely to see them (ex: favicon that 404’s)
当用户不太可能看到错误页面时，提供轻量级错误页面(例如：404的图标图标)
Preconnect and prefetching
预连接和预取

I haven’t seen any documentation to counter this, nor to add to it. I think it’s safe to say most of these are still in play.

我还没有看到任何文档来对此进行反驳，也没有对其进行补充。我认为可以肯定地说，大多数仍在发挥作用。

The original paper also showed that optimizing images provided, by far, the most significant data reduction. Nothing has really changed there. You can make the case JavaScript is a bigger deal for overall performance, but not data reduction. Optimizing or removing images is the safest way of ensuring a much lighter experience and that’s the primary optimization Data Saver relies on.

原始论文还显示，到目前为止，优化图像可以最大程度地减少数据量。那里什么都没有真正改变。可以断定JavaScript对于整体性能来说是一个更大的问题，但对于数据减少而言却不是。优化或删除图像是确保获得更轻盈体验的最安全方法，这是Data Saver所依赖的主要优化。

Lite pages take it a step further: they provide more performance gains, but at the same time are also a bit more intrusive in regards to the design of the site. Whereas Data Saver would apply optimizations (making improvements to resources and connections to speed them up), Lite pages apply interventions (eliminating some slow or heavy qualities of the page altogether). For example, Data Saver may transcode your images, but Lite pages will replace them with placeholders.

精简版页面更进一步：它们提供了更多的性能提升，但同时在站点设计方面也更具侵入性。 Data Saver会应用优化(对资源和连接进行改进以加快速度)，而Lite页面应用干预(完全消除页面的某些慢速或繁重质量)。例如，Data Saver可能会对您的图像进行转码，但精简版页面会将其替换为占位符。

Chrome has been playing with various interventions over the past year or two that were all triggered by the user opting into Data Saver mode, and typically the detection of a 2G-like connection. Most of those interventions were very experimental.

在过去的一两年中，Chrome一直在进行各种干预，这些干预都是由用户选择了Data Saver模式触发的，通常是检测到类似2G的连接。这些干预大多数都是实验性的。

Andy Davies posted to the Web Performance Slack group a link to a Chrome Status report describing which interventions are currently a part of Lite pages. At the moment, it looks like there are four that could possibly be applied:

安迪·戴维斯(Andy Davies)向Web Performance Slack组发布了指向Chrome状态报告的链接，该报告描述了哪些干预措施当前是Lite页面的一部分。目前，似乎有四个可能适用：

I spent the past two days using Chrome on my phone with Data Saver enabled and an effective connection type of 2G (using the #force-effective-connection-type flag).

我过去两天都在手机上启用了Data Saver并使用2G有效连接类型(使用＃force-effective-connection-type标志)使用Chrome。

The image replacement intervention has been applied everywhere. No images are loaded unless you long-press on one and specifically choose to download it, or you opt to show the original version of the page. Alt text is available on long hold as well, though it would be really handy to have that displayed by default over the placeholders to provide some context (I’ve submitted a bug for this).

图像替换干预已遍及所有地方。除非您长按其中一个并明确选择下载图像，否则您将不会加载任何图像，或者您选择显示页面的原始版本。 Alt文本也可以长期保留，尽管默认情况下将其显示在占位符上以提供一些上下文非常方便(我已经为此提交了一个错误 )。

I’ve seen offline copies of pages a handful of times as well, usually when I have closed the browser and come back to it a bit later.

通常，当我关闭浏览器并稍后再返回浏览器时，我也看到过几次页面的脱机副本。

If any non-critical resources have stopped loading or if scripts have been disabled yet, I haven’t noticed. So either they’re really well done, or they are not an intervention that is commonly applied in my region (Houssein stated on Twitter that the interventions do vary a lot based on overall conditions).

如果有任何非关键资源已停止加载，或者脚本已被禁用，则我不会注意到。因此，它们要么做得很好，要么不是我所在地区常用的干预措施( 侯赛因在Twitter上表示，干预措施的确因整体情况而有很大差异)。

您将能够知道何时将精简版页面应用于您的网站 (You’ll be able to tell when Lite Pages are applied to your site)

When Lite Pages are shown for your site, Chrome will allow you to record these interventions with the Reporting API. If you set a Report-To header telling the browser where to send the reports, you can set up an endpoint somewhere to collect them all for further analysis. Each report will detail exactly which intervention was applied.

当显示网站的精简版页面时，Chrome将允许您使用Reporting API记录这些干预。如果您设置了一个Report-To标头来告诉浏览器将报告发送到何处，则可以在某个地方设置一个端点以收集所有报告以进行进一步分析。每份报告将准确地详细说明采用哪种干预措施。

用户和开发人员都可以选择退出 (Users and developers can both opt out)

If users don’t enable Data Saver mode, they’ll never see a Lite page. If users do have Data Saver mode and opt out of the Lite pages interventions for the same site or URL frequently enough, then Chrome will stop applying interventions to that page for that user.

如果用户未启用数据保护程序模式，则他们将永远不会看到精简版页面。如果用户确实具有数据保护程序模式并且足够频繁地退出针对同一网站或URL的Lite页面干预，则Chrome将停止对该用户的干预应用于该页面。

Developers can also opt out of Lite pages for their sites by applying a Cache-Control: no-transform header to their responses. If Chrome sees this header, they won’t apply optimizations or interventions regardless of whether or not the user has opted into Data Saver mode.

通过将Cache-Control: no-transform标头应用于响应，开发人员还可以选择退出其站点的Lite页面。如果Chrome浏览器看到此标头，则无论用户是否选择了Data Saver模式，他们都不会应用优化或干预。

Please, please, please only use Cache-Control: no-transform if you are already checking for the Save-Data header and optimizing the experience accordingly (or if your initial experience is already blazingly fast and lightweight). Users explicitly telling us they want a faster experience is the kind of direct feedback we don’t usually get, and respecting their request is important.

请，请，请仅使用Cache-Control: no-transform如果您已经在检查Save-Data标头并相应地优化了体验(或者您的初始体验已经非常快捷，轻便)。用户明确告诉我们他们想要更快的体验是我们通常无法获得的直接反馈，尊重他们的要求很重要。

我们不知道的 (What We Don’t Know)

By now it’s clear there’s a lot going on, but we have a few unanswered questions that make me (and from what I can tell, many others) a little uneasy.

到目前为止，很明显有很多事情要做，但是我们有一些未解决的问题使我(以及据我所知，还有许多其他问题)有些不安。

何时应用优化和干预措施？ (When do optimizations and interventions get applied?)

We have some inkling of the optimizations and interventions, as I mentioned above, but I would love to see an authoritative source of documentation from Chrome that lists exactly what can be applied and, critically, when.

如上所述，我们对优化和干预措施有所了解，但我希望看到Chrome的权威文档来源，其中确切列出了可以应用的内容以及至关重要的时间。

I understand the heuristics take into consideration network and region, and I would suspect potentially device as well as other factors. So it’s not exactly straightforward when they’re applied. Still, I think particularly when you’re talking about making changes to the intended experience, the more transparency the better.

我了解启发式方法会考虑到网络和区域，因此我怀疑潜在的设备以及其他因素。因此，在应用它们时并不完全简单。尽管如此，我还是特别认为当您谈论更改预期的体验时，透明度越高越好。

For more experimental interventions, flag them as such in the documentation. They could even be a little less clear about the heuristics for those, because I imagine that’s a big part of the experiment—figuring out exactly when those interventions make sense, and when they fail.

有关更多实验性干预措施，请在文档中进行相应标记。他们甚至可能不太了解这些启发式方法，因为我认为这是实验的重要组成部分-准确找出这些干预措施何时有意义以及何时失败。

Chrome如何通过HTTPS应用优化？ (How does Chrome apply the optimizations over HTTPS?)

This is the big one. The one that’s going to bother people until it’s made very clear how this works.

这是大个子。在弄清楚这是如何工作之前，这将困扰着人们。

The post mentions that only the URL is passed to Google servers, and no sensitive data. I think everyone would feel a bit more at ease if we could see some clear documentation about how that process works.

该帖子提到仅URL被传递到Google服务器，而没有敏感数据。我认为，如果我们可以看到一些清晰的文档说明该过程的工作原理，那么每个人都会感到更加自在。

In my conversations with folks working on Chrome and Data Saver over the years, they were always very opposed to the Man-in-the-Middle behavior other proxy browsers took to optimize HTTPS traffic. I’m very interested in hearing how they managed to avoid that.

多年来，在我与从事Chrome和Data Saver开发的人们的对话中，他们始终非常反对其他代理浏览器用来优化HTTPS流量的中间人行为。我对听到他们如何避免这种情况非常感兴趣。

Addy elaborated a little on Twitter but I’m still a bit fuzzy on the mechanics.

Addy 在Twitter上做了一些详细说明，但是我仍然对机制有些模糊。

Šime Vidas clarified this a bit for me on Twitter, and I chatted a bit with Addy Osmani to make sure I was understanding correctly.

ŠimeVidas在Twitter上为我澄清了一些，我和Addy Osmani聊了些，以确保我正确理解。

Basically, it sounds like Chrome triggers an internal redirect to Google servers for the URL requested. Google’s servers make the request and apply any optimizations. Then those servers pass the optimized content back to Chrome to provide to the user.

基本上，听起来Chrome会针对请求的URL触发内部重定向到Google服务器。 Google的服务器发出请求并应用所有优化。然后，这些服务器将优化后的内容传递回Chrome，以提供给用户。

It’s pretty close to a MITM on the surface, but with a really important exception: by using a redirect it ensures that any cookies or sensitive information scoped to the origin does not get sent to Google. So there’s no passthrough or manipulation to the HTTPS connection potentially exposing private information. In other words, if you do have a page with session-based information, Lite pages won’t be able to do anything with it.

这是非常接近表面的MITM，但有一个非常重要的例外：通过使用重定向它保证范围限定为原点的任何cookie或敏感信息不会发送给谷歌。因此，不会对HTTPS连接进行任何传递或操纵，从而可能暴露出私人信息。换句话说，如果你有基于会话的信息的页面，页面精简版将无法用它做任何事情。

So yes, you still get something different that what you requested, and Google’s servers are still intervening, but private information is kept at least a little safer than with other proxy services.

因此，是的，您仍然得到了与您要求的有所不同的信息，并且Google的服务器仍在进行干预，但是私有信息至少比其他代理服务更安全。

一个喜欢网络的开发人员该做什么？ (What’s a web loving developer to do?)

On the one hand, I’m not foolish enough to trust any company to have my best interest at heart all the time. On the other hand, I do know many of the people working at Google, and on Chrome, and those folks I do trust. It’s enough to make me a little less wary of this announcement than perhaps some others are.

一方面，我不够愚蠢，无法信任任何一家公司，始终将自己的最大利益放在心上。另一方面，我确实认识许多在Google和Chrome上工作的人，以及我确实信任的人。这足以使我对这一宣布的警惕性要比其他一些警告少一些。

And providing a data reduction service through one of the biggest browsers out there does solve a very real need. I know I use proxy browsers, or things like Firefox Focus, on a daily basis. Not just when I travel, but also at home to help me stay under my monthly roaming data limit. For many folks all over the world, their need for such a service extends far beyond my own.

通过现有最大的浏览器之一提供数据缩减服务确实可以解决非常实际的需求。我知道我每天都使用代理浏览器或诸如Firefox Focus之类的工具。不仅在旅行时，而且还在家里帮助我保持在每月漫游数据限制之内。对于世界各地的许多人来说，他们对这种服务的需求远远超出了我的需求。

Still, a healthy skepticism is warranted for any proxy service, let alone one provided by a company that also happens to provide a lot of advertising online. Some clarification and additional details from the Lite pages team would go a long way towards alleviating those concerns.

尽管如此，对任何代理服务都应保持健康的怀疑态度，更不用说由公司提供的代理服务了，而该公司也恰巧在网上提供了大量广告。精简版页面小组的一些澄清和其他细节将有助于减轻这些担忧。

In the meantime, if you’re completely uncomfortable with the idea altogether, the best thing you can do is optimize the heck out of your site and then use Cache-control: no-transform to opt out of Data Saver and other proxy services.

同时，如果您对这个想法完全不满意，那么您可以做的最好的事情就是优化站点之外的内容，然后使用Cache-control: no-transform退出Data Saver和其他代理服务。

Just make sure you really are pushing performance to the extreme before you do. Make the default experience as fast as possible and whenever you see the Save-Data header being passed, apply further optimizations to reduce the amount of data being used (replace webfonts, eliminate or reduce images, etc).

只需确保您确实在将性能推向极限即可。使默认体验尽可能快，并且每当看到传递了Save-Data标头时，都应进行进一步的优化以减少使用的数据量(替换Web字体，消除或减少图像等)。

Respect your users desire for a faster, lightweight experience and you’ll be able to take control of your experience yourself, without any need for third-party interventions.

尊重用户对更快，轻量级体验的渴望，您将能够自己控制自己的体验，而无需第三方干预。

翻译自: https://timkadlec.com/remembers/2019-03-14-making-sense-of-chrome-lite-pages/