• 原文 标 题 : front-end Performance Checklist 2019-3
  • Vitaly Friedman
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Starrier
  • Proofreader: kikooo,Jingyuan0000

2019 Front-end Performance Optimization Year Summary – Part 3

Let 2019 come faster! You are reading the annual summary of front-end performance optimizations for 2019, which started in 2016.

2019 Front-end Performance Optimization Annual Summary — Part 1 2019 Front-end Performance Optimization Annual Summary — Part 2 2019 Front-end Performance Optimization Annual Summary — Part 3 2019 Front-end Performance Optimization Annual Summary — Part 4 2019 2019 Front-end Performance Optimization Year Summary – Part 6

directory

  • Resource optimization
    • 17. Use Brotli or Zopfli to compress plain text content
    • 18. Use responsive images and WebP
    • 19. Has the image been properly optimized?
    • 20. Has the video been properly optimized?
    • 21. Has the web font been optimized?

Resource optimization

17. Use Brotli or Zopfli to compress plain text

In 2015, Google launched Brotli, a new open source lossless data format that is now supported by all modern browsers. In fact, Brotli is much more effective than Gzip and Deflate. Because it is configuration dependent, this compression can be (very) slow, but slower compression means higher compression rates. But it decompresses quickly. So consider the cost savings Brotli can bring to your site.

The browser will only accept this format if the user accesses the site through HTTPS. And at what cost? Brotli is not pre-installed on some servers, so if Nginx is not self-compiled, configuration can be relatively difficult. However, it is not an impenetrable problem, as Apache has been gradually supporting it since version 2.4.26, for example. Thanks to the fact that Brotli is supported by many vendors, many CDNS (Akamai, AWS, KeyCDN, Fastly, Cloudlare, CDN77) have also started to support it. You can even (using it in conjunction with service Worker) support it on a CDN that does not support it. Enable Brotli.

At the highest level of compression, Brotli can be so slow that the time it takes the server to wait for dynamically compressed resources before starting to send responses can offset the potential gain in file size (after compression). But for static compression, a higher level of compression should be preferred.

Alternatively, you can consider using the Zopfli compression algorithm that encodes data in Deflate, Gzip, and Zlib formats. Any normal Gzip compressed resource can achieve file sizes that are 3% to 8% less than Zlib’s maximum compression rate through Zopfli’s improved Deflate encoding. The problem is that it takes about 80 times longer to compress files. That’s why it’s a good idea to use Zopfli on resources that don’t change much and are designed to be compressed once but downloaded multiple times.

If you can reduce the cost of dynamically compressing static resources, it’s worth the effort. Both Brotli and Zopfli can be used with any plain text payload — HTML, CSS, SVG, JavaScript, etc.

What is the solution? Use Brotli + Gzip to precompress static resources and Brotli to dynamically compress (dynamic) HTML at levels 1-4. Ensure that the server handles Brotli or Gzip protocol content correctly. If you cannot install/maintain Brotli on the server, use Zopfli.

18. Use response images and WebP

Use as many responsive images as possible with srcSET, sizes, and elements. Of course, You can also use the WebP format (supported in Chrome, Opera, Firefox 65, Edge 18) by using WebP images on native with a fallback to JPEG mechanism or by using protocol content (see also) Andreas Bovens snippet), or use the protocol content (the Accept header). Ire Aderinokun also has a very detailed tutorial on converting images to WebP images.

Native Sketch is WebP-enabled and you can export WebP images from Photoshop using Phtotshop’s WebP plugin. There are other options available, of course. If you’re using WordPress or Joomla, you can also use extensions to help you easily implement WebP support yourself, such as Optimus and Cache Enabler for WordPress, Joomla, of course, also has extensions that provide support (through the use of Cody Arsenault).

It should be noted that although WebP image file sizes are equivalent to Guetzli and Zopfli, it does not support progressive rendering like JPEG, which is why users were previously able to see actual images faster with JPEG, even though WebP images were transferred faster over the network. With JPEG, we can provide half or even a quarter of the data to the user and then load the rest of the data, rather than the incomplete image that WebP can lead to. You should make trade-offs based on your needs: with WebP, you can reduce load, and with JPEG, you can improve performance perception.

In Smashing Magazine, we use the -opt suffix to name images — for example, brotli-compression-opt.png; This way, when we find that the image contains the suffix, team members will know that the image has been optimized. — Unbelievable! Jeremy Wagner has written a great book about WebP.

The responsive picture endpoint generator automatically generates images and tags.

19. Is the image optimized properly?

When you are developing landing pages, the loading of certain images must be fast, make sure JPEG is progressively loaded and compressed by [mozJPEG] or Guetzli (by working with the scan level to improve the start rendering time), Google’s new open source encoder focuses on performance awareness and takes advantage of what it learned from Zopfli and WebP. The only downside: slow processing time (1 minute CPU per megapixel). For PNG we can use Pingo and for SVG we can use SVGO or SVGOMG. If you need to quickly preview, copy, or download all the SVG resources on your website, you can try using SVG-Grabber.

Although every image optimization article will say this, I would like to remind you to keep your vector resources clean and compact. Remember to clean up unused resources, remove unnecessary metadata and the number of waypoints in your artwork (code like SVG, for example) (thanks Jeremy!).

There are more advanced options, such as:

  • Use Squoosh for optimal compression levels (lossy or lossless). Adjust and manipulate images.

  • Use a responsive image breakpoint generator or a service like Cloudinary or Imgix to automate image optimization. In addition, srcSET and SIZES are used for best results in many cases.

  • To check the efficiency of the response tag, you can use imaging-heap (a command-line tool) to detect the effects of different window sizes and device pixel ratios.

  • Use Lazysizes to lazy-load images and IFrames, which is a library that triggers any visibility changes by detecting user interactions (or IntersectionObserver as we’ll discuss later).

  • Note the default loaded images, which may never be used — for example, in Carousels, Accordions, and Image galleries.

  • Consider different image displays specified by the request type to switch images through Sizes property, for example, manipulating Sizes to swap data sources in the magnifier component.

  • To prevent accidental downloads of foreground and background images, check for inconsistencies in image downloads.

  • To radically optimize storage, you can use Dropbox’s new format (Lepton) to perform lossless compression of JPeGs averaging 22%.

  • Note the aspect-Ratio and intrinsicSize properties of the CSS properties, which allow setting the width, height and dimensions of the image, so the browser can reserve a predefined layout slot during page loading to avoid styling errors.

  • If you’re feeling adventurous, for faster transmission of images over the network, you can terminate and reschedule HTTP/2 streams using a CDN-based real-time filter, Edge Workers. Edge Workers use JavaScript stream modules that you can control (they run on the CDN and modify the response stream) so that you can control the transmission of images. This process takes a little longer than a service worker because you have no control over the transfer, but it does work for Edge workers. Therefore, you can use them on static JPeGs that are saved step by step for a specific login page.

Sample output from imaging-heap (a command line tool for detecting loading efficiency across window size and device pixel ratio), (image source) (detailed preview)

The future of responsive graphics may change dramatically with the adoption of client-side prompts. The client prompt content is HTTP request header fields, such as DPR, viewport-width, Width, save-data, Accept (specify image format preferences), etc. They should tell the server about the user’s browser, screen, connection, and so on. Thus, the server can decide how to populate the layout with images of the appropriate size, and only provide images needed for the appropriate format. With client prompts, we migrate resources from HTML tags to request response protocols between the client and server.

As Ilya Grigorik points out, client-side prompts make image processing more complete – they are not a substitute for responsive images. provides control over the necessary art direction in the HTML tag. Client prompts annotate the requested image to automate resource selection. The Service Worker provides complete request and response management for clients. For example, the Service Worker can append a new client prompt header value to the request, rewrite the URL and point the image request to the CDN, adjust the response based on the link, user preferences, etc. It applies not only to image resources, but also to all other requests.

For clients that support client-side prompts, you can detect a savings of 42% in bytes and over 70% in 1MB+ bytes on the image. In Smashing magazine, we can also detect a 19-32% improvement in performance. Unfortunately, client-side prompts still need to be supported by the browser. Firefox and Edge are considering support for it. But if you provide both the normal response image tag and the client prompt’s
tag, the browser will evaluate the response image tag and request the corresponding image using the client prompt HTTP header.

Is not enough? Then you can use a variety of background image techniques to improve the perception of the image. Keep in mind that handling contrasts and blurring unnecessary details (or removing colors) can also reduce file sizes. If you want to enlarge a small photo without losing quality, consider using letsenhance.io.

So far, these optimizations have covered only the basics. Addy Osmani has published a very detailed guide to basic image optimization that goes into the details of image compression and color management. For example, you can blur unnecessary parts of an image (by applying a Gaussian blur filter) to reduce the file size, and you can even reduce the file size further by removing colors or converting the image to black and white. For background images, only 0 to 10% quality exported from Photoshop is perfectly acceptable. Don’t use JPEG-XR on the Web — “The process of decoding jPEG-XRS software on the CPU negates the potentially positive effect of saving bytes, or worse, especially in SPAs cases”.

20. Is the video optimized properly?

So far, we’ve covered images, but we’ve avoided discussing the merits of GIFs. Frankly, instead of loading heavily animated GIFs that affect rendering performance and bandwidth, choose dynamic WebP (GIF as fallback) or replace them with HTML5 Videos loop. Yes, browsers with

Early tests showed that an inline video with the IMG tag displayed 20 times faster and decoded 7 times faster than an equivalent GIF, despite file size issues. Although support for was announced in the Safari technical preview, this feature is far from universal, so it will not be adopted in the near future.

Addy Osmani recommends looping inlined videos instead of animated GIFs. File sizes vary significantly (80% savings). (preview)

The front end is an area of constant progress, and video formats have been evolving over the years. For a long time, we had hoped that WebM would become the ruler of formats, and that WebP (basically a still image in a WebM video container) would replace outdated image formats. Despite the support WebP and WebM have gained over the years, the breakthrough we had hoped to see did not happen.

In 2018, Alliance of Open Media released a video format called AV1. AV1 has similar compression to the H.265 (an improved version of H.264) encoder, but unlike the latter, AV1 is free. H.265’s license price forces browser vendors to adopt AV1 with the same performance: AV1 (as h.265) has twice the compression performance of WebP.

AV1 is likely to become the ultimate standard for web video. (Image: Wikimedia.org) (Preview in detail)

In fact, Apple currently uses HEIF and HEVC (H.265), and in the latest IOS, all photos and videos are saved in these formats instead of pure JPEG. Although HEIF and HEVC (H.265) are not publicly available on the web, AV1 is slowly being supported by browsers. So add AV1 to your

By far the most widely used is H.264, which is serviced by MP4 files, so make sure your MP4 files are multipass-encoding and blurred with Frei0r iirblur (if applicable) before providing files. Moov Atom metadata is also moved to the file header, and your server accepts byte services. Boris Schapira provides exact instructions for FFmpeg to maximize video optimization. Of course, it helps to offer WebM as an alternative.

Video playback performance itself has a lot to learn, and if you want to dig into the details of it, check out Doug Sillar’s video series on the current state of video and video delivery best practices. This section provides details about video transmission indicators, video preloading, compression, and streaming media.

Zach Leatherman’s comprehensive guide to Font loading Strategies offers a dozen options for Web font transfer.

21. Have Web fonts been optimized?

The first question worth asking is whether you can choose UI system fonts first. If this is not the case, the Web fonts you provide are likely to include glyphs or additional features or font size that are not used in the system font. You can ask font providers to group fonts, or if you’re using open source fonts, you can subset them yourself using Glyphhanger or Fontsquirrel. You can even use Peter Muller’s SubFont, a command line tool that automates your entire process by statically analyzing your pages, generating a subset of the best Web fonts, and then injecting them into your pages.

WOFF2 is the most supportive, and you can use WOFF as an alternative to browsers that don’t support WOFF2 — after all, system fonts are more friendly to legacy browser versions. There are many, many, many options for loading Web fonts. You can choose a strategy from Zach Leatherman’s “Comprehensive Guide to Font Loading Strategies” (snippet code can also be found in Web Font loading).

For now, a better option would be to use Critical FOFT combined with preload and “The Compromise” methods. They both use two-stage rendering to progressively provide Web fonts — first the small superset needed to render pages quickly and accurately using Web fonts, then asynchronously load the rest, The difference is that “The Compromise” technology loads polyfills asynchronously only if The font loading event is not supported, so by default polyfills are not loaded. Need a quick start? Zach Leatherman has a quick start 23 minute tutorial and case study to help you use fonts.

In general, using preload resource hints to preload fonts is a good idea, but include links to CSS and JavaScript in your markup. Otherwise, font loading takes time on the first rendering. Still, it’s a good idea to be selective about important documents. For example, rendering critical files will help you avoid visualizations and disruptive text refreshes. In summary, Zach recommends preloading one or two fonts per family. It makes sense to lazily load some fonts if they are not critical.

No one likes to wait for content to appear. Using the font-display CSS descriptor, we can control the font loading behavior and make the content read immediately (font-display: optional) or almost immediately (font-display: swap). However, if you want to avoid text being reordered, we still need to use the font loading API, especially group Repaints, or when you use a third party host. Unless you can use Cloudflare Workers’ Google font. Discuss Google Fonts: Consider using Google-Webfonts-Helper, which is an easy way to self-host Google Fonts. If you can, hosting your fonts yourself will give you maximum control over your fonts.

In general, if you choose FONT-display: optional, you need to forgo preload because it triggers requests for Web fonts early (and can cause network congestion if you have other critical path resources that need to be accessed). Preconnect can get cross-domain font requests faster, but use Preload with caution because preloaded fonts from different domains can cause network contention. All of these techniques are included in Zach’s Web font loading.

In addition, if the user has Reduce Motion enabled in the accessibility preferences or chooses Data protection mode (see save-Data Header for details), it is best to opt out of using Web fonts (at least in phase 2 rendering). Or when the user happens to have a slow connection (via the Web messaging API).

To test the loading performance of a Web font, consider using metrics for all text visualizations (everything is displayed as a Web font immediately as the font loads), as well as counting the Web font rearrangement after the first rendering. Obviously, the lower these two metrics, the better performance. It is important to consider the performance requirements of variable fonts. They provide designers with a greater choice of fonts at the cost of a single serial request as opposed to many separate file requests. This single request can slowly block the entire typographical appearance on a page. On the bright side, however, in the case of variable fonts, we get a new file stream by default, so there is no need for JavaScript to group the redrawn content.

Is there a perfect Web font loading strategy? Subset fonts are ready for two-stage rendering, declared using font-display descriptors, redrawn content is grouped using font loading apis, and fonts are stored in persistent service worker caches. If necessary, you can go back to Bram Stein’s Font Face Observer. If you are interested in detecting the performance of font loading, Andreas Marschke examines the performance of using the font API and the UserTiming API.

Finally, don’t forget to add Unicode-range, breaking up a large font into smaller language specific fonts, using Monica Dinculescu’s font-style-matcher to minimize jarring changes in layout, This is because there is an inconsistency between the size of the fallback and Web fonts.

2019 Front-end Performance Optimization Annual Summary — Part 1 2019 Front-end Performance Optimization Annual Summary — Part 2 2019 Front-end Performance Optimization Annual Summary — Part 3 2019 Front-end Performance Optimization Annual Summary — Part 4 2019 2019 Front-end Performance Optimization Year Summary – Part 6

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.


The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.