Chrome浏览器的NOSCRIPT干预

The other week, there were a few articles that came out about Chrome’s NOSCRIPT intervention: an intervention that would disable JavaScript altogether on slow networks. Chrome intervening on behalf of the user when it feels the network is iffy isn’t exactly new. Chrome has several interventions including one that can replace images with placeholders and one that bypasses web fonts on slow connections. The NOSCRIPT intervention itself isn’t even new. From the looks of it, it’s been around since January (just disabled by default until now).

前一周，有几篇关于Chrome浏览器的NOSCRIPT干预的文章出炉了：这种干预会在慢速网络上完全禁用JavaScript。 当感觉网络不稳定时，Chrome代表用户进行干预并不是完全新的。 Chrome采取了多种干预措施，其中一种可以使用占位符替换图像，另一种可以在连接缓慢时绕过网络字体。 NOSCRIPT干预本身并不是什么新鲜事。 从外观上看，它从一月份开始就存在(直到现在默认情况下都处于禁用状态)。

But disabling JavaScript is a much more controversial move, it appears. Web fonts fallback very easily to system fonts so disabling web fonts is not a huge deal to most. JavaScript, however, isn’t always treated as progressive enhancement (as much as I feel it should be) and so when it goes missing, the consequences can be a bit more significant.

但是，看来禁用JavaScript是一个更具争议性的举措。 Web字体很容易回退到系统字体，因此禁用Web字体对大多数人来说并不是什么大问题。 但是，JavaScript并不总是被视为渐进式增强(正如我认为应该的那样多)，因此当它丢失时，后果可能会更加严重。

As you would expect, then, there’s been a lot of ensuing conversation. However, all the articles I had read were speculating on what the intervention would look like, not what it does. It took a little digging through Blink issues, but I eventually figured out how to reliably fire up the NOSCRIPT preview so that I could test it out.

如您所料，随后进行了很多对话。 但是，我读过的所有文章都在猜测干预的效果，而不是效果。 它花了一些时间研究Blink问题，但最终我想出了如何可靠地启动NOSCRIPT预览版，以便对其进行测试。

它到底是做什么的？ (What exactly does it do?)

When the preview is enabled, the browser will download any necessary resources to display the page except for any JavaScript. External JavaScript files will not be requested, and inline JavaScript will not be executed. (Though it does appear that if a service worker has been installed for the domain, it will still execute).

启用预览后，浏览器将下载所有必要的资源以显示该页面(JavaScript除外) 。 不会请求外部JavaScript文件，也不会执行内联JavaScript。 (尽管看起来确实已经为该域安装了Service Worker，但它仍将执行)。

The browser will do all the rest of the work necessary to display the page and present it to the user, with an information bar informing the user that the page has been modified to save data and giving them the option to view the “original”. When the click on the information bar, the original page will be downloaded and displayed—JavaScript included.

浏览器将完成显示页面并将其呈现给用户的所有其余工作，并带有一个信息栏，通知用户该页面已被修改以保存数据，并为他们提供了查看“原始”内容的选项。 单击信息栏时，将下载并显示原始页面-包括JavaScript。

When I first read about the intervention, I had thought the preview was some sort of static snapshot, but it’s fully interactive. Provided your site works without JavaScript, I can click from page to page, reading articles or shopping for the product I want to buy.

当我第一次阅读有关干预的内容时，我曾以为预览是某种静态快照，但它是完全交互式的。 如果您的网站可以在不使用JavaScript的情况下正常运行，那么我可以逐页单击，阅读文章或购买要购买的产品。

进行试驾 (Taking it for a test drive)

To test the intervention, you’ll need to toggle a few flags to make sure you can see the NOSCRIPT preview. Once it’s enabled by default on Android, which presumably will happen in Chrome 69, this won’t be necessary.

要测试干预措施，您需要切换一些标志以确保您可以看到NOSCRIPT预览。 一旦默认情况下在Android上启用了该功能(该功能可能会在Chrome 69中启用)，则无需这样做。

To toggle the flags, open Chrome on your Android device and navigate to chrome://flags. #allow-previews and #enable-noscript-previews must each be enabled. #enable-optimization-hints should be disabled (we’ll come back to that later). You’ll also need to set the #force-effective-connection-type flag to ‘2G’ or slower.

要切换标志，请在您的Android设备上打开Chrome，然后导航至chrome://flags 。 #allow-previews和#enable-noscript-previews必须分别启用。 #enable-optimization-hints应该被禁用(我们稍后会再讲)。 您还需要将#force-effective-connection-type标志设置为“ 2G”或更慢。

什么时候开始？ (When does it kick in?)

The intervention kicks in when two criteria are met (it’s a bit more complicated than that, but we’ll get to that in a minute):

当满足两个条件时，干预就开始了(比这要复杂一些，但我们将在一分钟内解决)：

1. The effective network connection type is 2G or slower
   有效的网络连接类型为2G或更慢
2. The Data Saver proxy is enabled
   启用了Data Saver代理

If you want to see the intervention in action, you’ll need to make sure Data Saver is running (Chrome > Settings > Data Saver).

如果要查看实际的干预措施，则需要确保Data Saver正在运行(Chrome>设置> Data Saver)。

In real use, Chrome will use the Network Information API to determine if the effective connection type (ECT) is 2G or slower and, if it is, use the NOSCRIPT intervention. For testing purposes, you can force Chrome to always view the ECT as a 2G network using the #force-effective-connection-type flag I mentioned earlier.

在实际使用中，Chrome将使用Network Information API来确定有效连接类型(ECT)是2G或更慢，如果是2G或更慢，则使用NOSCRIPT干预。 为了进行测试，您可以使用我之前提到的#force-effective-connection-type标志，强制Chrome始终将ECT视为2G网络。

On the surface, the decision to apply the intervention seems straightforward. If the network is slow and the user has made the decision to get let Chrome help them out in those situations, you’ll get the NOSCRIPT intervention. The reality is it’s a little more complex than that.

从表面上看，采取干预措施的决定似乎很简单。 如果网络很慢，并且用户决定让Chrome在这种情况下帮助他们，则您将获得NOSCRIPT干预。 现实情况是，这要复杂得多。

For one, there is a whitelist and blacklist that can opt domains in or out of this optimization. It appears that there are lists on the browser side as well as on the user side. I’m not clear on all the ways those lists can be populated, but it does look like if the user opts out of the same host often enough, the host will be added to the preview blacklist. There is also a short period (about 5 seconds from the looks of it) where Chrome will decide not to use the intervention from any site if a user has recently opted out.

首先，有一个白名单和黑名单可以选择加入或退出此优化的域。 看来在浏览器端以及用户端都有列表。 对于这些列表的填充方式尚不清楚，但是如果用户选择退出同一主机的次数足够多，则该主机将被添加到预览黑名单中 。 还有很短的时间(从外观来看，大约5秒钟)，如果用户最近选择退出，Chrome会决定不使用任何网站的干预措施。

Another wrinkle is that the NOSCRIPT intervention is far from the only option Data Saver has to reduce page bloat. There are other optimizations, and even other previews (like the LOFI preview which will load image placeholders instead of actual images). Again, I’m not 100% certain about the logic they’re using to determine when a given preview is the correct option, but it does appear there’s some thought applied here: they’re not just applying the NOSCRIPT intervention to every page that comes along.

另一个麻烦是，NOSCRIPT干预远非Data Saver减少页面膨胀的唯一选择。 还有其他优化，甚至还有其他预览(例如LOFI预览，它将加载图像占位符而不是实际图像)。 再说一次，我不确定他们用于确定给定预览何时正确选项的逻辑，但并没有百分百确定，但确实出现了一些想法：他们不只是将NOSCRIPT干预应用于每个页面随之而来。

That’s where the #enable-optimization-hints flag I mentioned earlier comes in. Enabled by default, this flag enables Chrome to use “hints” to determine when and where certain optimizations should apply. Right now, to apply the NOSCRIPT intervention with optimization hints enabled, the request must be whitelisted. I suspect they may get more aggressive with the optimization after they’ve had it running like this for awhile. In the meantime, to consistently see it in effect, we need to disable those hints.

这就是我前面提到的#enable-optimization-hints标志出现的地方。默认情况下启用，此标志使Chrome可以使用“提示”来确定应在何时何地应用某些优化。 现在，要在启用优化提示的情况下应用NOSCRIPT干预， 必须将请求列入白名单 。 我怀疑经过一段时间这样的优化后，他们可能会在优化方面变得更加积极。 同时，为了始终如一地看到它的效果，我们需要禁用这些提示。

So yes, it does kick in on 2G networks with Data Saver enabled, but as you can see, there are more variables at play.

是的，它确实可以在启用了Data Saver的2G网络上使用，但是如您所见，还有更多的变量在起作用。

它也适用于HTTPS (It works on HTTPS too)

Before testing, I made the (mistaken) assumption that since the NOSCRIPT preview intervention was tied to Data Saver, it wouldn’t apply to HTTPS sites. Data Saver, like most proxy browsers and services, tends to leave HTTPS alone. But it looks like I was wrong: the NOSCRIPT intervention appears to work on both HTTP and HTTPS sites.

在测试之前，我做出了一个(错误的)假设，因为NOSCRIPT预览干预与Data Saver绑定在一起，所以它不适用于HTTPS站点。 像大多数代理浏览器和服务一样，Data Saver倾向于不使用HTTPS。 但是似乎我错了：NOSCRIPT干预似乎在HTTP和HTTPS站点上都起作用。

I guess it makes sense. The reason Data Saver (and other proxy services and browsers) leave HTTPS alone is that applying any transformations to the content would require that they essentially act as a man-in-the-middle.

我想这很有道理。 Data Saver(以及其他代理服务和浏览器)不使用HTTPS的原因是，对内容应用任何转换都将要求它们本质上充当中间人。

In this case, however, they aren’t transforming the content in any way. The NOSCRIPT previews simply don’t execute JavaScript, nor make any requests to external JavaScript.

但是，在这种情况下，他们不会以任何方式转换内容。 NOSCRIPT预览根本不执行JavaScript，也不对外部JavaScript发出任何请求。

开发人员如何知道已应用干预措施？ (How do developers know the intervention has been applied?)

When the intervention kicks in, all requests will have an intervention header applied to them, like so:

干预开始时，所有请求都将被应用intervention标头，如下所示：

<https://www.chromestatus.com/features/4775088607985664>; level="warning"

The presence of the header is enough to indicate that the browser applied some sort of intervention, and the URL in the header will point to more information about the specific intervention applied.

头的存在就足以表明该浏览器应用某种形式的干预，并在报头中的URL将指向有关应用的具体干预措施的更多信息 。

There’s one notable exception: the main document does not appear to get the intervention header currently. Honestly, this may just be a bug as it’s not clear to me why the header wouldn’t be applied to the main document.

有一个值得注意的例外：主文档当前似乎未获得intervention标头。 老实说，这可能只是一个错误，因为我不清楚为什么标头不会应用于主文档。

All requests (including the main document) will also have the save-data header set to on, but you shouldn’t rely on that as an indication of an intervention. The save-data header will be applied whenever the proxy is enabled (or, really, any proxy service or browser that supports the header), regardless of whether the browser applied any interventions.

所有请求(包括主文档)也将save-data标头设置为on ，但是您不应依赖于此作为干预的指示。 只要启用了代理(或者实际上是支持该头的任何代理服务或浏览器)，便会应用save-data头，而不管浏览器是否应用了任何干预措施。

If you’re actively testing, you can also fire up chrome://interventions-internals/ in Chrome on your device and follow the logs to confirm when the NOSCRIPT intervention has been applied.

如果您正在积极测试，则还可以在设备上的Chrome中启动chrome://interventions-internals/ ，并按照日志确认何时应用了NOSCRIPT干预措施。

这对用户意味着什么？ (What does this mean for users?)

For users, the intervention can be very effective for certain sites. I loaded up 10 different sites with the NOSCRIPT intervention enabled and disabled to see the difference.

对于用户而言，干预对于某些站点可能非常有效。 在启用和禁用NOSCRIPT干预的情况下，我加载了10个不同的站点，以查看区别。

The two results that jump out right away as oddities are The Atlantic and The Verge which managed to get a whopping 293% and 2048% heavier without JavaScript. In case you’re curious (I was), it’s because they are doing a lot of lazy-loading of images with JavaScript. In situations where JavaScript is not available, they wrap a fallback image in a <noscript> element. Unfortunately for visitors to both sites, several fallback images are massive—ranging from 1.6MB to 9.9MB.

突然出现的两个结果是The Atlantic和The Verge，它们在没有JavaScript的情况下重了293％和2048％。 如果您好奇(我曾经)，那是因为他们正在使用JavaScript进行大量的图像延迟加载。 在无法使用JavaScript的情况下，它们会将后备图像包装在<noscript>元素中。 不幸的是，对于这两个站点的访问者来说，几个后备图像很大，从1.6MB到9.9MB不等。

When the optimization works, which is more often than not, it works very well. The minimal improvement was a 24% reduction in data usage, and the remaining sites shed between 74-98% of their bytes.

当优化工作(通常不是)进行时，效果很好。 最小的改进是数据使用量减少了24％，其余站点的字节数减少了74-98％。

It’s possible you would get similar results from the LOFI preview (which displays placeholders instead of the site’s actual images by default) for many of these sites. It’s worth noting though that the NOSCRIPT intervention has the added benefit of reducing the amount of work the actual device has to do. Images may account for the majority of network weight, but on the CPU, JavaScript is the worst offender by far.

对于许多这样的网站，您可能会从LOFI预览(默认显示占位符而不是网站的实际图像)中得到类似的结果。 值得注意的是，NOSCRIPT干预还具有减少实际设备要做的工作量的额外好处。 图像可能占网络总重量的大部分，但是在CPU上， JavaScript是迄今为止最严重的违规行为 。

这对网站所有者意味着什么？ (What does this mean for site owners?)

Whenever something like this comes up, naturally people want to know how to make it so that their site isn’t negatively impacted. The appropriate response is to make sure you serve a usable experience even if JavaScript isn’t enabled. That doesn’t mean you can’t use React, Vue or the like—but it does mean you should use server-side rendering if you do. The less your site relies on client-side JavaScript, the better it will appear when the intervention is applied. Treat JavaScript as an enhancement and you’re good to go.

每当出现这种情况时，人们自然就会想知道如何制作它，以免对他们的网站造成负面影响。 适当的响应是即使没有启用JavaScript，也要确保您提供了可用的体验。 这并不意味着您不能使用React，Vue之类的东西，而是意味着您应该使用服务器端渲染。 您的站点对客户端JavaScript的依赖程度越低，则在进行干预时它就会显示的越好。 将JavaScript视为增强功能，就可以了。

The BBC site is a good example. Below you can see the mobile site (left) and the NOSCRIPT preview (right). There is very little difference. The branding is retained, and the content is readable.

英国广播公司的网站就是一个很好的例子。 在下面您可以看到移动网站(左)和NOSCRIPT预览(右)。 几乎没有区别。 品牌保留，内容可读。

Contrast that with the Engadget site, which displays nothing whatsoever in the NOSCRIPT preview:

与Engadget站点(在NOSCRIPT预览中什么也不显示)进行对比：

Or AliExpress which does have some navigation displayed (kind of), but no branding:

或确实显示了某种导航但没有品牌的AliExpress：

You can, technically, opt-out of the intervention altogether by setting Cache-control: no-transform on your main request. The no-transform value tells proxy services not to modify any requests or resources and the intervention respects that: applying it ensures no one will ever see a NOSCRIPT preview for your site.

从技术上讲，您可以通过在主请求上设置Cache-control: no-transform来完全退出干预。 no-transform值告诉代理服务不要修​​改任何请求或资源，并且干预措施涉及：应用该值可确保不会有人看到您站点的NOSCRIPT预览。

But use this with extreme caution. I’ve always been incredibly uneasy about using the no-transform value to opt out of proxies. Users are choosing those proxy services or browsers intentionally. They’re opting into these sort of optimizations and interventions and it feels a bit uncomfortable to me when developers overrule those decisions.

但是请格外小心。 使用no-transform值选择退出代理，我一直非常不安。 用户正在故意选择那些代理服务或浏览器。 他们选择了这种优化和干预措施，当开发人员否决这些决定时，令我感到不舒服。

If you are going to opt-out using the no-transform value, then at least make sure you’re making ample use of the save-data header to reduce weight wherever you can: eliminating web fonts, serving low-quality images, etc.

如果你要退出使用no-transform值，那么至少确保你正在做充分的利用的save-data报头，以减轻重量的地方，您可以：消除网页字体，服务低质量的图像等。

这是一件好事 (This is a good thing)

Long story short, the NOSCRIPT intervention looks like a really great feature for users. More often than not it provides significant reduction in data usage, not to mention the reduction in CPU time—no small thing for the many, many people running affordable, low-powered devices.

长话短说，对于用户来说，NOSCRIPT干预看起来是一个很棒的功能。 通常，它可以显着减少数据使用量，更不用说减少CPU时间了-对于运行负担得起的低功耗设备的许多人来说，这并不是一件小事。

The Chrome folks, as you would expect, aren’t being haphazard with the intervention either. In fact, by (at least initially) relying on a whitelist, they’re being pretty conservative with it. It’s just one of many tricks in their bag to provide a more performant experience and they appear to be treading carefully when it comes to applying it.

正如您所期望的那样，Chrome专家也不会对干预感到随意。 实际上，(至少在一开始)依靠白名单，他们对​​此相当保守。 这只是他们提供更多性能体验的众多技巧之一，在应用时，他们似乎在谨慎行事。

What I love most about the intervention is the attention it has gotten from developers. JavaScript isn’t a given. Things go wrong.

我最喜欢干预的地方是开发人员的关注。 JavaScript不是给定的 。 事情出了问题 。

I have mixed feelings about Google’s influence on the web (a subject for another post, perhaps) but bringing a little more attention to the reality that we can’t always rely on JavaScript (and providing a much more usable experience for many in the process) is something I can get behind.

我对Google对网络的影响有不同的看法(也许是另一篇文章的主题)，但更多地关注了我们不能总是依赖JavaScript的现实(并在此过程中为许多人提供了更多可用的体验) )是我可以落后的东西。

翻译自: https://timkadlec.com/remembers/2018-09-06-chromes-noscript-intervention/