带预览功能的pdf浏览器_带有功能策略的浏览器内性能分析

带预览功能的pdf浏览器

One of the absolute best things you can do to help keep performance in check is to provide a series of visible, well-placed checks and balances in your development workflow to always keep performance front-of-mind. One thing I’m very excited about in this context is feature policies.

您可以采取的绝对最好的措施之一就是保持性能检查，这是在开发工作流中提供一系列可见的，位置合理的检查和平衡操作，以始终使性能成为首要考虑因素。 在这种情况下，我非常兴奋的一件事就是功能策略。

Feature-Policy is a relatively new feature that lets you opt-in or out of certain browser features on your site.

Feature-Policy是一项相对较新的功能，可让您选择加入或退出网站上的某些浏览器功能。

For example, you could tell the browser not to allow the use of the Geolocation API by providing the following header:

例如，您可以通过提供以下标头来告诉浏览器不允许使用Geolocation API：

Feature-Policy: geolocation 'none'

There are a lot of benefits from a security and performance standpoint to Feature-Policy, but what I’m excited about at the moment are the ways you can use Feature-Policy to help make easy-to-overlook performance issues more visible. It essentially provides in-browser performance linting.

从安全和性能的角度来看，“ Feature-Policy有很多好处，但是目前让我兴奋的是，您可以使用“ Feature-Policy来帮助使容易忽视的性能问题更明显。 它实质上提供了浏览器内性能的提升。

图像过大 (Oversized-images)

By default, if you provide the browser an image in a format it supports, it will display it. It even helpful scales those images so they look great, even if you’ve provided a massive file. Because of this, it’s not immediately obvious when you’ve provided an image that is larger than the site needs.

默认情况下，如果您以支持的格式向浏览器提供图像，它将显示该图像。 即使您提供了大量文件，它也有助于缩放这些图像，使它们看起来很棒。 因此，当您提供的图像大于站点所需的图像时，它并不是立即显而易见的。

The oversized-images policy tells the browser not to allow any images that are more than some predefined factor of their container size. The recommended default threshold is 2x, but you are able to override that if you would like.

oversized-images政策会告诉浏览器，不允许任何图片超出其容器大小的某些预定义因素。 建议的默认阈值为2倍，但是您可以根据需要覆盖该阈值。

So, given the following header, the browser will not allow any origins (that’s the ‘none’ part) to display an image that is more than 2x its container size (either width or height).

因此，给定以下标头，浏览器将不允许任何来源(即“无”部分)显示大于其容器大小(宽度或高度)两倍的图像。

Feature-Policy: oversized-images 'none';

If you wanted to be more lenient, you could tell the browser not to display any images more than 3x their container size:

如果您想宽大处理，可以告诉浏览器不要显示超过其容器大小三倍的图像：

Feature-Policy: oversized-images *(3) 'none';

In either case, if an image exceeds the threshold, a placeholder is displayed instead, and an error is logged to the console.

在任何一种情况下，如果图像超过阈值，则会显示一个占位符，并将错误记录到控制台。

With the oversized-images policy in place, large images are still downloaded, but placeholders are shown instead, and an error is logged to the console.

使用适当的oversized-images策略，仍会下载大图像，但显示占位符，并且将错误记录到控制台。

未优化的图像 (Unoptimized Images)

Another common image related performance problem is unoptimized images. It’s all too common to find images that may be appropriately sized, but haven’t been adequately compressed. A lot of unnecessary metadata gets added to images when they’re taken and created, and that often gets passed along. One particularly annoying example are images that have thumbnails of themselves embedded in their metadata. I’ve seen plenty of instances where the embedded thumbnail (that the designers and developers didn’t even know was there) weighed more than the image itself!

另一个常见的与图像相关的性能问题是未优化的图像。 找到尺寸适当但未充分压缩的图像太普遍了。 拍摄和创建图像时，会在图像中添加许多不必要的元数据，而这些元数据通常会被传递出去。 一个特别令人讨厌的示例是图像，其自身的缩略图嵌入其元数据中。 我见过很多实例，其中嵌入式缩略图(设计人员和开发人员甚至不知道该缩略图)比图像本身重得多！

On top of that, there’s also just general compression that many formats provide to get the ideal balance of quality and file size.

最重要的是，许多格式还提供了通用压缩功能，以实现质量和文件大小的理想平衡。

Using both the unoptimized-lossy-images and unoptimized-lossless-images policies, we can tell the browser to compare the file size to the dimensions of the image.

使用unoptimized-lossy-images和unoptimized-lossless-images策略，我们可以告诉浏览器将文件大小与图像尺寸进行比较。

Feature-Policy: unoptimized-lossy-images 'none';
Feature-Policy: unoptimized-lossless-images
'none';

If the byte-per-pixel ratio is too high, the browser will display a placeholder image and log an error to the console.

如果每像素字节比率太高，浏览器将显示一个占位符图像并将错误记录到控制台。

The unoptimized-* policies result in a placeholder image being displayed, just as with the oversized-images policy.

unoptimized-*策略会导致显示占位符图像，就像oversized-images策略一样。

The recommended byte-per-pixel ratio for lossy images is 0.5 and the recommended ratio for lossless images is 1. There’s a little wiggle room here. Right now, there’s an overhead allowance of 1kb for lossy images and 10kb for lossless images.

对于有损图像，建议的每像素字节比率为0.5，对于无损图像，建议的比率为1。这里有一些摆动的空间。 目前，有损图像的开销为1kb，无损图像的开销为10kb。

For example, let’s say we have a 200px by 200px JPEG. JPEG is a lossy format, so the recommended byte-per-pixel ratio is .5, and the overhead allowance is only 1kb. To figure out what image size would be acceptable, we would multiply the dimensions by the accepted ratio and then add in the overhead allowance.

例如，假设我们有200px x 200px的JPEG。 JPEG是一种有损格式，因此建议的每像素字节比为.5，开销允许仅为1kb。 为了确定可接受的图像大小，我们将尺寸乘以可接受的比率，然后加上间接费用。

(200 x 200 x .5) + 1024 = 21,024 bytes or 20.5kb

(200 x 200 x .5)+ 1024 = 21,024字节或20.5kb

If the image were a lossy format, then our allowance would be 10kb, and the accepted byte-per-pixel ratio would be 1. Other than that, the calculation would look the same.

如果图像是有损格式，则我们的余量为10kb，可接受的每像素字节比为1。除此之外，计算结果相同。

(200 x 200 x 1) + 10,240 = 50,240 bytes or 49.1kb

(200 x 200 x 1)+ 10,240 = 50,240字节或49.1kb

That allowance is likely to change in the future. In fact, while Blink defaults to a 10kb allowance for lossless images, they’re already experimenting with an unoptimized-lossless-images-strict policy that changes that allowance to only 1kb.

该津贴将来可能会改变。 实际上，尽管Blink默认将无损图像的容限设置为10kb，但他们已经在尝试采用unoptimized-lossless-images-strict策略，将容限更改为仅1kb。

无尺寸媒体 (Unsized Media)

What’s old is new and all that.

旧的是新的，这一切。

For a long time, putting height and width attributes on your image was more or less a best practice. Without those in place, the browser has no idea how much space the image should take up until the image has actually been downloaded. This leads to layout shifting. The page will be displayed, and then the content will shift once the image has arrived, and the browser does another layout pass to make room for it.

长期以来，在图像上放置height和width属性或多或少是一种最佳做法。 如果没有适当的位置，浏览器将不知道在实际下载图像之前图像应占用多少空间。 这导致布局偏移。 将显示该页面，一旦图像到达，内容就会转移，浏览器将进行另一次布局传递以为其腾出空间。

When we started wanting images to scale fluidly with the help of CSS, we more or less recreated the issue regardless of if those attributes existed or not. As a result, a lot of folks stopped using them altogether.

当我们开始希望图像在CSS的帮助下流畅地缩放时，无论这些属性是否存在，我们或多或少都会重新创建该问题。 结果，很多人完全停止使用它们。

But, thanks to recent work spearheaded by Jen Simmons, Firefox and Chrome can compute the aspect ratio of an image from its height and width attributes. When paired with any applied CSS, this means they can preserve space for those images during the initial layout phase.

但是，由于由Jen Simmons领导的最新工作 ，Firefox和Chrome可以从图像的height和width属性计算出图像的长宽比。 与任何已应用CSS配对时，这意味着它们可以在初始布局阶段为这些图像保留空间。

The unsized-media policy tells the browser that all media elements should have size attributes, and if they don’t, the browser should choose a default. It’s a little more complicated than that, but the gist is that if you don’t have size attributes, the browser will use 300px by 150px.

unsized-media策略告诉浏览器所有媒体元素都应具有size属性，如果没有，则浏览器应选择默认属性。 比这要复杂一些 ，但是要点是，如果没有size属性，浏览器将使用300px x 150px。

Feature-Policy: unsized-media 'none';

With this policy in place, media will still be displayed, but if the size isn’t defined in the HTML, you’ll very quickly see as all the images will be sized at the default dimensions. And, as always, an error will be reported in the console.

使用此策略后，仍会显示媒体，但是如果未在HTML中定义尺寸，您将很快看到所有图像将按默认尺寸进行尺寸设置。 而且，和往常一样，控制台中将报告错误。

With the unsized-media policy, the original image or video is still displayed, but the browser defaults to a 300px x 150px size for each image without the height and width attributes.

使用unsized-media策略时，仍会显示原始图像或视频，但浏览器默认为每个图像的300px x 150px大小(不包括height和width属性)。

It's probably worth noting because it tripped me up at first, but if you're using the unsized-media policy in conjunction with the oversized-images policy, don't be surprised if you suddenly see a bunch more violations from oversized images. Because the unsized-media policy now changes your unsized images to 300px by 150px, the browser will use that size as its starting point when determining if an image is oversized.

可能值得一提，因为它一开始让我大跌眼镜，但是如果您同时使用unsized-media策略和oversized-images策略，那么如果您突然看到更多来自超大图像的违规行为，请不要感到惊讶。 由于unsized-media策略现在将您的未缩放图像更改为300px x 150px，因此浏览器在确定图像是否过大时将以该尺寸为起点。

应对不可见的政策违规行为 (Surfacing Less-Visible Policy Violations)

What I love about the image related policies is that they take something that isn’t usually noticeable and makes it jump out at us as we’re building. We know if we’ve neglected to optimize an image or provide sizing attributes because the display of the page is impacted. In fact, reporting is their primary benefit. While unsized-media would potentially reduce layout shifting, the other policies still result in the images being downloaded, so the sole benefit is this increased visibility.

我喜欢与图片相关的政策，因为它们采取了通常不引人注意的方法，并在我们构建过程中让我们惊讶。 我们知道是否由于页面显示受到影响而忽略了优化图像或提供尺寸设置属性。 实际上，报告是他们的主要好处。 尽管unsized-media可能会减少布局偏移，但其他策略仍会导致图像下载，因此唯一的好处就是增加了可见性。

There are a few other potentially helpful policies from a performance linting perspective. Policies like sync-script (which blocks synchronous script execution), sync-xhr (which blocks synchronous AJAX requests) and document-write (which blocks any document.write calls) all come to mind.

从性能下降的角度来看，还有其他一些可能有用的策略。 所有想到的策略，例如sync-script (阻止同步脚本执行)， sync-xhr (阻止同步AJAX请求)和document-write (阻止任何document.write调用)。

These other policies great from a performance and control standpoint, but out of the box they’re a little less exciting from a linting perspective. Unless you have a synchronous script that is necessary for your page to display (which, ok, is not that hard to find) most of the visibility benefits these policies provide are in the form of console errors and, frankly, I suspect most developers don’t pay super close attention to those (though we all probably should).

从性能和控制的角度来看，这些其他策略非常有用，但是从线性角度来看，它们开箱即用的效果并不那么令人兴奋。 除非您有页面显示所必需的同步脚本(好吧，这并不难找到)，否则这些策略提供的大多数可见性好处都是以控制台错误的形式出现的，坦率地说，我怀疑大多数开发人员都不会这样做不会特别注意这些内容(尽管我们所有人都应该如此)。

That being said, we can make them more visible by using the ReportingObserver API to watch for violations and display them prominently on the page:

话虽如此，我们可以使用ReportingObserver API监视违规行为并将其显着地显示在页面上，从而使它们更加可见：

let reportingAlerts = document.createElement('ul');
  reportingAlerts.setAttribute('id','reportingAlerts');
  document.body.appendChild(reportingAlerts);

const alertBox = document.getElementById('reportingAlerts');

new ReportingObserver((reports, observer) => {
  let fragment = document.createDocumentFragment();
  
  Object.keys(reports).forEach(function(item) {
    let li = document.createElement('li');
    li.textContent = reports[item].body.message + ': ' + reports[item].body.featureId;
    fragment.appendChild(li);
  });
  
  alertBox.appendChild(fragment)
}, {types: ['feature-policy-violation'], buffered: true}).observe();

I setup a quick and dirty CodePen to show how it might look.

我设置了一个快速而肮脏的CodePen来展示它的外观。

An example of how you could display feature policy violations on in your local development or staging environments.

有关如何在本地开发或登台环境中显示违反功能策略的示例。

赶上 (The Catch)

The big catch: browser support. Only Blink-based browsers (Opera, Edge, Chrome, Samsung) seem to support the header right now. (Firefox and Safari support the allow attribute intended for iFrames.) Even there, you have to enable “Experimental Web Platform features” (found in about:flags) for many of these to work.

最大的收获是：浏览器支持。 目前只有基于Blink的浏览器(Opera，Edge，Chrome，Samsung)似乎支持该标头。 (Firefox和Safari支持用于iFrame的allow属性。)即使在这里，您也必须启用“实验性Web平台功能”(在about：flags中找到)才能使其中许多功能起作用。

我如何使用它们 (How I’m Using Them)

That’s not a huge issue for me personally. Since I like to use these policies as in-browser linting, I don’t need to try to ship any of these headers to production or have them work for everyone—they need to be there for me and anyone actively building the site. I use Chrome as my primary development browser anyway, so it’s just a matter of turning the flag on once and forgetting about it.

就我个人而言，这不是一个大问题。 由于我喜欢将这些策略用作浏览器内的linting，因此我不需要尝试将任何这些标头发布到生产环境中或让它们适用于所有人—他们需要在我身边以及任何积极构建该站点的人。 无论如何，我都将Chrome用作主要的开发浏览器，因此只需将标志打开一次就可以了。

The simplest way I’ve found for doing this is through the ModHeader extension. The extension lets you define custom headers to be passed along as you’re browsing the web.

我找到的最简单的方法是通过ModHeader扩展。 通过扩展，您可以定义自定义标头，以在浏览网络时传递。

The ModHeader extension lets me set up a Feature-Policy header that I can easily toggle on and off as I browse around the web.

ModHeader扩展使我可以设置一个Feature-Policy标头，当我在网络上浏览时，可以轻松地打开和关闭它。

I have three different Feature-Policy headers that I primarily toggle between:

我主要使用三种不同的Feature-Policy标头：

• oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';

  oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';

• unsized-media 'none'; oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';

  unsized-media 'none'; oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';

• script-sync 'none'; unsized-media 'none'; oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';

  script-sync 'none'; unsized-media 'none'; oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';

I keep the first one on a lot—it’s fascinating to browse the web with these policies applied. It’s scary how massive some images are. There’s a lot of room for improvement.

我经常讲第一个-运用这些策略浏览网页很有趣。 令人震惊的是有些图像有多大。 有很大的改进空间。

There is a LOT of unsized-media out there (I’m guilty too!) so that one gets annoying if it’s on for general browsing, which is why I have it in a separate policy I can toggle on. The same thing goes for sync-script—it breaks a lot of sites.

那里有很多unsized-media (我也很内!！)，这样一来，如果将其打开进行常规浏览就很烦人，这就是为什么我将其放在单独的策略中以便可以启动。 sync-script -它破坏了很多站点。

A few teams I’ve worked with have started using a similar flow to have those policies running so that when they’re working on the local development and staging environments, they can quickly see if something is amiss. Of course, in those situations, I recommend turning on any and all performance related policies so that they’re able to catch issues right away.

与我一起工作的几个团队已经开始使用类似的流程来运行这些策略，以便在本地开发和暂存环境上工作时，他们可以快速查看是否有问题。 当然，在这种情况下，我建议启用所有与性能相关的策略，以便它们能够立即发现问题。

I’m hopeful that we’ll see a few other browsers add support eventually—while Chrome is my primary development browser, I do bounce between browsers, and it would be helpful for this to be available across them all. This is one of those rare times, however, where experimental support is enough to make a feature like this instantly useful.

我希望我们最终会看到其他一些浏览器增加支持，尽管Chrome是我的主要开发浏览器，但我确实会在各种浏览器之间跳动，这对于在所有浏览器中都可用会有所帮助。 但是，这是那些罕见的时期之一，在该时期，实验支持足以使此类功能立即可用。

A lot of performance issues stem from them simply not being very noticeable to those of us doing the building. Changing that wherever we can is one of the best ways to make sure that all that low-hanging fruit doesn’t go overlooked.

许多性能问题源于它们，而对于我们进行构建的人员而言，它们根本就不是很明显。 尽我们所能改变它是确保所有那些低调的成果不会被忽视的最好方法之一。

翻译自: https://timkadlec.com/remembers/2020-02-20-in-browser-performance-linting-with-feature-policies/

带预览功能的pdf浏览器