限制JavaScript？
Yesterday there was a bit of a heated discussion around a WebKit issue that suggested putting a limit on the amount of JavaScript a website can load. In the issue, Craig Hockenberry makes the case that enforcing a limit on the amount of JavaScript would provide a sort of “meet me in the middle” solution for users currently using content blockers.
昨天，围绕WebKit问题进行了激烈的讨论，建议限制网站可以加载JavaScript数量。 在本期杂志中，克雷格·霍肯贝里(Craig Hockenberry)提出了这样一个案例，即限制JavaScript的数量将为当前正在使用内容阻止程序的用户提供一种“让我与中间人见面”的解决方案。
Content blockers have been a great addition to WebKit-based browsers like Safari. They prevent abuse by ad networks and many people are realizing the benefits of that with increased performance and better battery life.
内容阻止程序是Safari等基于WebKit的浏览器的重要补充。 它们可以防止广告网络滥用，许多人已经意识到通过提高性能和延长电池寿命可以从中受益。
But there’s a downside to this content blocking: it’s hurting many smaller sites that rely on advertising to keep the lights on…..
但是，这种内容封锁有一个弊端：它正在损害许多依靠广告保持亮灯的小型网站的伤害。
The situation I’m envisioning is that a site can show me any advertising they want as long as they keep the overall size under a fixed amount, say one megabyte per page. If they work hard to make their site efficient, I’m happy to provide my eyeballs.
我所设想的情况是，一个网站可以向我显示他们想要的任何广告，只要它们将整体大小保持在固定的数量之内，例如每页1兆字节。 如果他们努力工作以提高网站效率，我很高兴为您提供帮助。
If Webkit pursues the idea further, they wouldn’t be alone.
如果Webkit进一步追求这个想法，他们将不会孤单。
Alex Russell has been working on a Never-Slow Mode for Chrome since October or so. The Never-Slow Mode is much more refined, as you would expect given how long it has been brewing. It doesn’t merely look at JavaScript size, but also CSS, images, fonts and connections. It also disables some features that are harmful to performance, such as document.write and synchronous XHR.
自10月左右以来， 亚历克斯·罗素(Alex Russell )一直致力于Chrome的从不慢模式 。 如酿造多久了，您会期望从不慢速模式更加精致。 它不仅查看JavaScript的大小，还查看CSS，图像，字体和连接。 它还禁用了一些对性能有害的功能，例如document.write和同步XHR。
Never-Slow Mode isn’t that far removed from two ideas that we had back in 2016 when Yoav Weiss and I met with the AMP team to discuss some standards-based alternatives to AMP. One of the ideas that came out of that discussion was Feature Policy which lets you disable and modify specific features in the browser. Another idea that came out of that discussion was the idea of “Content Sizes” which would enable first-party developers to put specify limits on the size of different resource types. This was, primarily, a way for them to keep third-party resources in check. Never-Slow Mode would combine these two concepts to create a set of default policies that would ensure a much more performant experience.
从不慢速模式与2016年我们与Yoav Weiss和我会见AMP团队讨论AMP的一些基于标准的替代方案的两个想法相距不远。 讨论中提出的想法之一是功能策略 ，它使您可以禁用和修改浏览器中的特定功能。 讨论中产生的另一个想法是“内容大小”，这将使第一方开发人员可以对不同资源类型的大小设置特定的限制。 这主要是使他们能够控制第三方资源的一种方法。 从不慢模式将结合这两个概念来创建一组默认策略，以确保获得更高的性能体验。
Not only would WebKit not be alone in pursuing some sort of resource limits, but they wouldn’t exactly be breaking new ground either.
WebKit不仅会独自追求某种资源限制，而且它们也不会真正地开辟新天地。
Browsers feature similar limits and interventions already today. iOS imposes a memory limit (a high one, but it’s still a limit) that folks most usually run into when using large, high-resolution images. And Chrome’s NOSCRIPT intervention skips right past the idea of limiting JavaScript and disables it altogether.
浏览器已经具有类似的限制和干预措施。 iOS施加了一个内存限制 (一个很高的限制 ，但仍然是一个限制)，这是人们在使用大型高分辨率图像时最常遇到的。 Chrome的NOSCRIPT干预措施跳过了限制JavaScript的想法，并完全禁用了它。
In other words, the idea itself isn’t as radical as maybe it appears at first blush.
换句话说，这个想法本身并不像乍看上去那样激进。
Still, there are a few concerns that were raised that I think are very valid and worth putting some thought into.
尽管如此，我仍然提出了一些担忧，这些担忧非常有效，值得深思。
为什么每个人都总是对我挑剔 (Why’s Everybody Always Pickin’ on Me)
One common worry I saw voiced was “if JavaScript, why not other resources too?”. It’s true; JavaScript does get picked on a lot though it’s not without reason. Byte for byte, JavaScript is the most significant detriment to performance on the web, so it does make sense to put some focus on reducing the amount we use.
我听到的一个普遍担忧是“如果使用JavaScript，为什么还不使用其他资源？”。 这是真的; 尽管确实并非没有道理，但JavaScript的确受到了很多欢迎。 字节对字节，JavaScript是对网络性能的最重大损害，因此，将重点放在减少我们的使用量上确实是有意义的。
However, the point is valid. JavaScript may be the biggest culprit more often than not, but it’s not the only one. That’s why I like the more granular approach Alex has taken with Chrome’s work. Here are the current types of caps that Never-Slow Mode would enforce, as well as the limits for each:
但是，这一点是有效的。 JavaScript可能经常是最大的罪魁祸首，但它并不是唯一的罪魁祸首。 这就是为什么我喜欢Alex在Chrome的工作中采用的更精细的方法。 以下是永不慢速模式将强制执行的当前上限类型，以及每个上限的限制：
- Per-image max size: 1MB 每张图片的最大大小：1MB
- Total image budget: 2MB 图片总预算：2MB
- Per-stylesheet max size: 100kB 每个样式表的最大大小：100kB
- Total stylesheet budget: 200kB 样式表总预算：200kB
- Per-script max size: 50kB 每个脚本的最大大小：50kB
- Total script budget: 500kB 脚本总预算：500kB
- Per-font max size: 100kB 每字体最大大小：100kB
- Total font budget: 100kB 总字体预算：100kB
- Total connection limit: 10 总连接限制：10
- Long-task limit: 200ms 长任务限制：200ms
There’s a lot more going on than simply limiting JavaScript. There are limits for individual resources, as well as their collective costs. The limit on connections, which I glossed over the first time I read the description, would be a very effective way to cut back on third-party content (the goal of Craig’s suggestion to WebKit). Finally, having a limit on the long-tasks ensures that the main thread is not overwhelmed and the browser can respond to user input.
除了限制JavaScript之外，还有很多事情要做。 个人资源及其集体成本受到限制。 我第一次阅读该说明时就掩盖了对连接的限制，这将是减少第三方内容(Craig向WebKit提出建议的目标)的一种非常有效的方法。 最后，对长任务进行限制可以确保主线程不会被淹没，并且浏览器可以响应用户输入。
It does seem to me that if browsers do end up putting a limit on the amount of JavaScript, they should consider following that lead and impose limits on other resources as well where appropriate.
在我看来，如果浏览器最终确实限制了JavaScript的数量，他们应该考虑遵循这一原则，并在适当时对其他资源施加限制。
太大太大了？ (How big is too big?)
Another concern is the idea that these size limits are arbitrary. How do we decide how much JavaScript is too much? For reference, the WebKit bug thread hasn’t gone as far as suggesting an actual size yet, though Craig did toss out a 1 MB limit as an example. Chrome’s Never-Slow Mode is operating with a 500kB cap. That 500kB cap, it’s worth noting, is transfer size, not the decoded size the browser has to parse and execute. Regarding the actual code the device has to run, that’s still somewhere around 3-4MB which is…well, it’s a lot of JavaScript.
另一个问题是这些大小限制是任意的。 我们如何确定JavaScript过多呢？ 供参考，WebKit错误线程还没有建议实际大小，尽管Craig举了一个1 MB的限制为例。 Chrome的“永不慢速”模式在500kB的上限下运行。 值得注意的是500kB的上限是传输大小，而不是浏览器必须解析和执行的解码大小。 关于设备必须运行的实际代码，它仍然在3-4MB左右，这是……很多JavaScript。
That being said, the caps currently used in Never-Slow Mode are just guesses and estimates. In other words, the final limits may look very different from what we see here.
话虽如此，目前在从不慢模式下使用的上限只是猜测和估计。 换句话说，最终限制可能与我们在此处看到的完全不同。
Exactly what amount to settle on is a tricky problem. The primary goal here isn’t necessarily reducing data used (though that is a nice side-effect), but rather reducing the strain on the browsers main thread. Sizes are being used as a fuzzy proxy here which makes sense—putting a cap on CPU usage and memory is a lot harder to pull off. Is focusing on size ideal? Probably not. But not that far off base either.
究竟要解决多少是一个棘手的问题。 这里的主要目标不一定是减少使用的数据(尽管这是一个很好的副作用)，而是减轻了浏览器主线程的负担。 在这里，大小被用作模糊代理，这很有意义-限制CPU使用率和内存上限要困难得多。 专注于尺寸是否理想？ 可能不是。 但是也不算太远。
The trick is going to be to find a default limit that provides a benefit to the user without breaking the web in the process. That 500kB JavaScript limit, for example, is right around the 60th percentile of sites according to HTTP Archive, which may end up being too aggressive a target. (Interestingly, when discussing this with Alex, he pointed out that the 50kB limit on individual JavaScript files broke sites far more often than the 500kB restriction. Which, I suppose, makes sense when you consider the size of many frameworks and bundles today.)
诀窍是要找到一个默认限制，该限制为用户带来好处，而又不会破坏流程。 例如，根据HTTP Archive ，该500kB JavaScript限制正好位于网站第60个百分位数附近，这最终可能会成为一个过于激进的目标。 (有趣的是，在与Alex讨论时，他指出，单个JavaScript文件的50kB限制比500kB限制破坏站点的频率要高得多。考虑到当今许多框架和捆绑软件的大小，我认为这很有意义。)
One thing that seems to be forgotten when we see browsers suggestion things like resource limits, or selective disabling of JavaScript, is that they aren’t going to roll something out to the broader web that is going to break a ton of sites. If they did, developers would riot and users would quickly move to another browser. There’s a delicate balance to be had here. You need the limit low enough to actually accomplish something, but high enough that you don’t break everything in the process.
当我们看到浏览器提出诸如资源限制或选择性禁用JavaScript之类的建议时，似乎已经忘记的一件事是，它们不会将某些东西推广到更广泛的网站上，而这将破坏大量站点。 如果这样做的话，开发人员将暴动，用户将Swift转移到另一个浏览器。 这里有一个微妙的平衡。 您需要足够低的极限来实际完成某项工作，但又需要足够高的极限，以确保您不会破坏过程中的所有内容。
Even more than that, you need to be careful about when and where you apply those limits. Currently the idea with Never-Slow Mode would be to selectively roll those restrictions out only for limited situations, according to Alex:
不仅如此，您还需要注意何时何地应用这些限制。 Alex表示 ，目前从不采用慢速模式的想法是选择性地仅在有限的情况下推出这些限制：
Current debate is on how to roll this out. I am proposing a MOAR-TLS-like approach wherein we try to limit damage by starting in high-value places (Search crawl, PWAs install criteria, Data-Saver mode) and limit to maintained sites (don’t break legacy)
当前的辩论是关于如何推广这一点。 我正在提议一种类似MOAR-TLS的方法，在这种方法中，我们尝试通过从高价值的地方开始(搜索爬网，PWA安装条件，数据节省模式)来限制破坏，并限制维护的站点(不要破坏传统)
In other words, they would take a very gradual approach like the did with HTTPS Everywhere, focusing on specific situations to apply the restrictions and careful consideration into how to progressively enable a UI that keeps users informed.
换句话说，他们将采用与HTTPS Everywhere一样的非常渐进的方法，重点放在特定情况下以应用限制，并仔细考虑如何逐步启用可让用户保持知情的UI。
Data-Saver mode (the user opt-in mode that indicates they want to use less data), to me, is so obvious a choice that it should just happen.
对我来说，数据保护程序模式(指示用户希望使用较少数据的用户加入模式)非常明显，它应该发生。
Progressive web app (PWA) installs are an interesting one as well. I can definitely see the case for making sure that a PWA doesn’t violate these restrictions before allowing it to be added to the homescreen and get all the juicy benefits PWA’s provide.
渐进式Web应用程序(PWA)的安装也很有趣。 我绝对可以看到在确保将PWA添加到主屏幕并获得PWA提供的所有多汁好处之前，确保PWA不违反这些限制的情况。
It’s also worth noting, while we’re on PWA’s, that Never-Slow Mode would not apply those restrictions to the service worker cache or web workers. In other words, Never-Slow Mode is focused on the main thread. Keep that clear and performant and you’ll be just fine.
值得注意的是，当我们使用PWA时，永不慢模式不会将这些限制应用于服务工作者缓存或Web工作者。 换句话说，从不慢模式集中在主线程上。 保持清晰和高效，您就可以了。
浏览器将如何启用和实施此功能？ (How would browsers enable and enforce this?)
Still, the risk of broken functionality will always be there which brings us to consideration number three: how do browsers enable these limits and how do they encourage developers to pay attention?
但是，始终存在功能中断的风险，这使我们不得不考虑第三点：浏览器如何实现这些限制，以及它们如何鼓励开发人员注意？
The surface level answer seems relatively straightforward: you give control to the users. If the user can opt into these limits, then we developers have zero right to complain about it. The user has signaled what they want, and if we are going to stubbornly ignore them, they may very well decide to go somewhere else. That’s a risk we take if we ignore these signals.
表面级别的答案似乎相对简单：将控制权交给用户。 如果用户可以选择这些限制，那么我们的开发人员将无权投诉。 用户已经发出了他们想要的信号，并且如果我们要顽固地忽略它们，他们很可能决定去其他地方。 如果我们忽略这些信号，那将是一种冒险。
The issue of control is a bit more nuanced when you start to think about the actual implementation though.
但是，当您开始考虑实际的实现时，控制问题会更加细微。
How do we expose these controls to the user without annoying them?
我们如何在不烦扰用户的情况下向用户公开这些控件？
How do we make sure that the value and risk is communicated clearly without overwhelming people with technical lingo?
我们如何确保清晰地传达价值和风险，而又不会让技术术语的人感到不知所措？
How do we ensure developers make responding to the users request for a faster site a priority?
我们如何确保开发人员将响应用户对更快网站的请求作为优先事项？
Kyle Simpson’s suggestion of a slider that lets the user choose some level of “fidelity” they prefer is an interesting one, but it would require some care to make sure the wording strikes the right balance of being technically vague, and yet clear to users as to what the impact would be. Would users really have an idea of what level of “fidelity” or “fastness” they would be willing to accept versus not?
凯尔·辛普森(Kyle Simpson)建议使用一种滑块，让用户选择他们喜欢的某种程度的“保真度”，这很有趣，但是需要谨慎行事，以确保措辞达到技术上模糊不清的正确平衡，并且对于用户而言仍然清晰易懂会有什么影响。 用户是否真的会知道他们愿意接受还是不愿意接受什么级别的“保真度”或“牢度”？
Kyle also suggested that these sliders would then ultimately send back a header which each request to the site so that the site itself could determine what it should and should not send down to the user. That idea is a better articulation of a concern that seemed to be underlying much of the negative feedback to the idea: developers are leery of browsers imposing some limit all on their own without letting sites have some say in it themselves.
凯尔(Kyle)还建议这些滑块最终将向每个站点发送一个标头，每个请求都将标头发送给站点，以便站点本身可以确定应该向用户发送或不向用户发送什么。 这个想法更好地表达了人们的担忧，这似乎是对该想法的负面反馈的基础：开发人员对浏览器持谨慎态度，他们自己施加了一些限制，而没有让网站自己发表意见。
And I get it, I do. I love the idea of a web that is responsible and considerate of users first and foremost. A web that would look at these user signals and make decisions that benefit the user based on those preferences. I think that’s the ideal scenario, for sure.
我知道了，我知道。 我喜欢这样一个网站的想法：首先要对用户负责并考虑周到。 一个网络，将查看这些用户信号并根据这些首选项做出使用户受益的决策。 我认为那是理想的情况。
But I also think we have to be pragmatic here.
但是我也认为我们在这里必须务实。
We already have a signal like this in some browsers: the Save-Data header. It’s more coarse than something like Kyle’s suggestion would be—it’s a very straightforward “I want to save data”—but it’s a direct signal from the user. And it’s being ignored. I couldn’t find a single example from the top 200 Alexa sites of anyone optimizing when the Save-Data header was present, despite the fact that it’s being sent more frequently than you might think.
在某些浏览器中，我们已经有这样的信号： Save-Data header 。 它比像凯尔(Kyle)的建议那样粗略-这是一个非常简单的“我想保存数据”-但这是用户的直接信号。 而且它被忽略了。 我无法从Alexa的前200个站点中找到任何一个示例，说明存在Save-Data标头时进行优化的任何人 ，尽管事实是发送它的频率比您想象的要高 。
If these requests for less data and less resources being utilized have any chance at all of being seriously considered by developers, there needs to be some sort of incentive in place.
如果这些要求更少数据和更少资源的要求完全有可能被开发人员认真考虑，则需要采取某种激励措施。
That being said, I like the idea of the developer having some idea of what is happening to their site. So here’s what I’m thinking might work:
话虽这么说，我喜欢开发人员对他们的网站所发生的事情有所了解的想法。 所以这是我在想的可能的工作：
The browser sets a series of restrictions that it can enforce.
浏览器设置了可以强制执行的一系列限制。
These limits need to be suitably high enough to reduce breakage while still protecting users (Sounds so simple, doesn’t it? Meanwhile the folks having to implement this are banging their heads against their desks right now. Sorry about that.) These limits also need to be very carefully applied depending on the situation. The direction Never-Slow Mode is headed, both in terms of granularity and progressive rollout, make a lot of sense to me.
这些限制必须足够高，以减少破裂，同时仍要保护用户(听起来很简单，不是吗？与此同时，必须执行此操作的人们正在将头撞在桌子上。很抱歉。)这些限制需要根据情况非常仔细地应用。 从粒度和逐步推出的角度来看，永不缓慢模式的发展方向对我来说非常有意义。
These restrictions could, optionally, be reduced further with user input.
这些限制可以有选择地通过用户输入进一步降低。
Whether it’s in the form of a coarse “put me in a never slow mode” or a more granular control, I’m not sure. If this step happens, it needs to be clearly communicated to the user what they’re getting and giving up. Right now, I’m not sure most everyday people would have a clear understanding of the trade-offs.
我不确定是粗略的“让我进入永不慢速的模式”还是更细化的控件。 如果发生此步骤，则需要将其清楚地传达给用户，他们正在获得和放弃什么。 现在，我不确定大多数人是否会对折衷方案有清楚的了解。
The browser should communicate to the site when those limits apply.
这些限制适用时，浏览器应与网站进行通信。
If the user
如果用户
does opt into a limit, or the browser is applying limits in a certain situation, communicate that through some sort of request header so developers have the ability to make optimizations on their end.
确实选择了限制，或者浏览器在某种情况下正在应用限制，请通过某种请求标头传达此信息，以便开发人员可以在其末端进行优化。
The browser should communicate to the site if those limits get enforced.
如果强制执行这些限制，浏览器应与该站点进行通信。
If and when the browser does have to enforce the limits that the site violates, provide a way to beacon that to the site for later analysis, perhaps similar to
如果浏览器确实必须执行该网站违反的限制，则当该浏览器必须执行该网站所违反的限制时，请提供一种将其信标发送给该网站以供以后分析的方法，也许类似于
reporting on Content-Security policies.
报告内容安全政策 。
I don’t see this approach as particularly troublesome as long as those defaults are handled with care. Is it applying a band-aid to a gunshot wound? Kind of, yes. There are bigger issues—lack of awareness and training, lack of top-down support, business models and more—that contribute to the current state of performance online. But those issues take time to solve. It doesn’t mean we pretend they don’t exist, but it also doesn’t mean we can’t look for ways to make the current situation a little better in the meantime.
只要谨慎处理这些默认值，我就不会觉得这种方法特别麻烦。 是否在创可贴上使用创可贴？ 有点，是的。 存在更大的问题-缺乏意识和培训，缺乏自上而下的支持，业务模型等等，这些都是导致在线绩效当前状态的原因。 但是这些问题需要时间解决。 这并不意味着我们假装它们不存在，但也并不意味着我们不能在此期间寻找使当前情况好一些的方法。
If a limit does get enforced (it’s important to remember this is still a big if right now), as long as it’s handled with care I can see it being an excellent thing for the web that prioritizes users, while still giving developers the ability to take control of the situation themselves.
如果确实实施了一个限制(重要的是要记住，如果现在就这样做仍然很大)，只要谨慎处理，我就会发现这对于优先考虑用户的网络来说是一件好事，同时仍使开发人员能够自己控制局势。
翻译自: https://timkadlec.com/remembers/2019-01-31-putting-some-limits-on-javascript/