Front-end Performance Optimization Year 2019 – Part 4

Milica Mihajlija provides an overview of how WebAssembly works and why it’s useful. (Preview larger image)

28. Is AOT compilation used?

Use AOT (Ahead-of-time) compiler to put some client renderings on the server to quickly output usable results. Finally, consider using optimize.js to speed up initial load time, wrapping functions that need to be called immediately (although this may not be necessary now).

From Default Fast: Modern Loading Best Practices, by the unique Addy Osmani. Slide on page 76.

29. Only provide legacy code to older browsers

Since ES2015 is so well supported in modern browsers, we can use babel-preset-env to just escape those ES2015 + features that are not yet supported by our target browser. Then set up two builds, one in ES6 and one in ES5. As mentioned above, JavaScript modules are now supported by all major browsers, so use script type = “module” to get browsers that support ES modules to load ES6-enabled files, Older browsers can load ES5-enabled files using Script nomodule. We can automate the whole process using the Webpack ESNext Boilerplate.

Note that we can now write module-based JavaScript that runs natively in a browser, without a compiler or packaging tool. Header provides a way to load module scripts early (and with high priority). Basically, it does a good job of maximizing bandwidth usage by telling the browser what it needs to get so that it doesn’t get stuck during these long round trips. In addition, Jake Archibald has posted a detailed article about the ES module to keep in mind that is worth reading.

For LoDash, use babel-plugin-loDash, which loads only the modules you use in your source code. Your other dependencies may also depend on other versions of LoDash, so converting generic LoDash requires specific functionality to avoid code duplication. This may save you quite a bit of JavaScript overhead.

Shubham Kanodia has written a detailed low-maintenance guide to smart packaging: how to just push legacy code to older browsers in a production environment, with snippets of code that you can use directly.

Jake Archibald has posted a detailed article about the ES module to keep in mind, such as the fact that inline scripts are delayed until blocking external and inline scripts are executed. (Preview larger image)

30. Are JavaScript differentiated services used?

We wanted to send the necessary JavaScript over the network, but that meant more concentration and fine-grained attention to the delivery of these static resources. Philip Walton introduced the idea of differentiated services a while back. The idea is to compile and serve two separate JavaScript packages: “regular” builds with babel-transforms and Polyfills that are only available to older browsers that actually need them, and another package without transforms and polyfills that has the same functionality.

As a result, it helps reduce blocking on the main thread by reducing the number of scripts the browser needs to process. Jeremy Wagner published a comprehensive article in 2019 on differential services and how to set it up in your build pipeline, from setting up Babel to what tweaks you need to make in Webpack, and the benefits of doing it all.

31. Identify and rewrite legacy code through incremental decoupling

Old projects are riddled with old and outdated code. Review your dependencies and assess how long it will take to refactor or rewrite the legacy code that recently caused the problem. Of course, it’s always a big task, but once you understand the impact of legacy code, you can start with incremental decoupling.

First, set metrics that track whether the rate of legacy code calls stays the same or goes down, not up. Publicly prevent teams from using the library, and make sure your CI warns developers if it is used in pull requests. Polyfill helps convert legacy code into a rewritten code base using standard browser functionality.

Identify and remove unused CSS/JS

CSS and JavaScript code coverage in Chrome will give you an idea of what code has been executed/applied and what has not been executed. You can start recording coverage, perform actions on the page, and then browse code coverage results. Once you detect unused code, find those modules and use import() for lazy loading (see whole thread). Then overwrite the configuration file repeatedly and verify that it now sends less code on initial load.

You can use Puppeteer to programmatically collect code coverage, and Canary lets you export code coverage results. As Andy Davies mentioned, you may want to collect code coverage for both modern and older browsers. Puppeteer also has many other use cases, such as automatic parallax or monitoring of unused CSS per build.

In addition, Purgecss, UnCSS and Helium can help you remove unused styles from your CSS. If you are not sure whether use the suspicious code somewhere, you can follow Harry Roberts advice: 1 x 1 px for the class to create a transparent GIF and puts it into dead/directory, for example: / assets/img/dead/comments. GIF. Then, set that particular image to the background of the appropriate selector in your CSS, and wait a few months to see if that file shows up in your log. If the entry does not appear in the log, no one uses the legacy component: you can continue to delete it all.

For the adventurous, you can even monitor DevTools by using DevTools, which automatically collects unused CSS through a set of pages.

33. Reduce the size of JavaScript packages

As Addy Osmani points out, when you only need a small part, you’re likely to send complete JavaScript libraries, along with outdated polyfills for browsers that don’t need them, or just duplicate code. To avoid extra overhead, consider using Webpack-Libs-Optimization to remove unused methods and polyfills during the build process.

Add packaged auditing to your regular workflow. There are some lightweight alternatives to the heavy library you added a few years ago, for example: moment.js can be replaced with date-fns or Luxon. Research by Benedikt Rotsch suggests that the switch from moment.js to date-fns could reduce first draw times on 3G and low-end phones by around 300ms.

This is where tools like Bundlephobia can help you find the cost of adding an NPM package to a package. You can even combine these costs with the Lighthouse Custom Audit. This also applies to frameworks. Styles can be reduced from 194KB to 10KB by removing or reducing the Vue MDC adapter (Vue’s Material component).

Do you like adventure? You can look at Prepack. It compiles JavaScript to equivalent JavaScript code, but unlike Babel or Uglify, it allows you to write normal JavaScript code and output faster equivalent JavaScript code.

Instead of shipping the entire framework package, you can even trim the framework and compile it into a raw JavaScript package that requires no extra code. Svelte does this, as does the Rawact Babel plug-in, which converts the React. Js component to native DOM operations at build time. Why is that? Well, as the maintainer explains: “React-DOM contains code for every possible component/HTMLElement that can be rendered, including code for incremental rendering, scheduling, event handling, and so on. But some applications don’t need all of these features (at initial page load). For such applications, it might make sense to build an interactive user interface using native DOM manipulation.”

In Benedikt Rotsch’s article, he states that the switch from moment.js to date-fns will reduce the first drawing time on 3G and low-end phones by around 300ms. (Preview larger image)

34. Is predictive prefetch of JavaScript code blocks used?

We can use heuristics to determine when to preload blocks of JavaScript code. Guess. Js is a set of tools and libraries that use Data from Google Analytics to determine which pages a user is most likely to visit from a given page. Based on user navigation patterns gathered from Google Analytics or other sources, Guess. Js builds a machine learning model to predict and prefetch the JavaScript required for each subsequent page.

Therefore, each interaction element receives a probability score of participation, and based on that score, the client script decides to pre-acquire the resource in advance. You can integrate this technology into your Next. Js application, Angular, and React, and a Webpack plug-in automates the setup process.

Obviously, you might expect the browser to pre-fetch unwanted pages using unwanted data, so it’s best to be absolutely conservative in the number of pre-fetch requests. A good use case is pre-fetching validation scripts needed in checkout, or speculative pre-fetching when a critical CTA (call-to-action) enters the viewport.

Need something less complicated? Quicklink is a small library that automatically prefetches links in the viewport when idle to speed up the loading of next page navigation. However, it also takes into account Data traffic, so it doesn’t pre-fetch Data on a 2G network or when the Data-Saver is turned on.

35. Benefit from optimizing for your target JavaScript engine

Research which JavaScript engines dominate your user base, and then explore ways to optimize for those engines. For example, script flows are used to handle large scripts when optimizing for Blink kernel browser, V8 used in The Node.js runtime, and Electron. It allows async or defer scripts to be parsed on a separate background thread at the start of the download, thus reducing page load times by up to 10% in some cases. In fact, use

Warning: Opera Mini does not support script delay, so if you are developing for India or Africa, defer will be ignored, which will prevent rendering until the script runs out (thanks Jeremy!). .

Progressive startup means using server-side rendering to get a fast first effective draw, but also includes some minimal JavaScript to keep first interaction times close to first effective draw times.

36. Client-side rendering or server-side rendering?

In both cases, our goal should be to set up progressive startup: use server-side rendering to get a fast first effective draw, but also include some minimal JavaScript necessary to keep the first interaction time close to the first effective draw time. If JavaScript comes too late after the first effective drawing, the browser may lock up the main thread while parsing, compiling, and executing the JavaScript discovered later, thus locking up the site or application’s interactions.

To avoid this, always break function execution into separate asynchronous tasks and use requestIdleCallback whenever possible. Consider using WebPack’s dynamic import() support to delay loading portions of the UI, reducing the cost of loading, parsing, and compiling until the user actually needs them (thanks to Addy!). .

In essence, first interaction time (TTI) tells us the time between navigation and interaction. The metrics are defined by looking at the first five second window after the initial content rendering, where no JavaScript task will exceed 50 milliseconds. If a task occurs for more than 50 milliseconds, restart the search for the five-second window. Therefore, the browser will first assume that it has reached the interactive state, then switch to the frozen state, and finally switch back to the interactive state.

Once we reach the interactive state, we can start the non-essential parts of the application on demand or as time permits. Unfortunately, as Paul Lewis has noted, frameworks often don’t provide developers with a concept of priority, so most libraries and frameworks struggle with incremental startup. If you have the time and resources, use this strategy to ultimately improve performance.

So, client side or server side? If there is no obvious benefit to the user, client-side rendering may not really be necessary — in fact, server-side rendering of HTML may be faster. Maybe you can even use static site generator to pre-render some content and push it directly to the CDN with some JavaScript at the top.

Limit the use of client frameworks to pages that absolutely need them. Server rendering and client rendering can be a disaster if done badly. Consider pre-rendering and dynamic CSS inlining at build time to produce production-ready static files. Addy Osmani gave an excellent talk on JavaScript costs that might be worth paying attention to.

37. Restrict the influence of third-party scripts

With all the performance tuning, we often have no control over third-party scripts from business requirements. Third-party script metrics are not influenced by the end user experience, so often a script ends up calling an annoying, verbose third-party script, undermining the dedicated performance effort. To control and mitigate the performance cost of these scripts, it is not enough to load them asynchronously (possibly via latency) and accelerate them through resource prompts such as DNS-Prefetch or preconnect.

As Yoav Weiss explains in his must-read view on third-party scripts, in many cases these scripts download dynamic resources. Resources change between page loads, so there is no need to know which hosts to download resources from and what those resources are.

What are your options? Consider using the service worker to compete for resource downloads by timeout, and if the resource does not respond within a specified timeout, an empty response is returned to tell the browser to continue parsing the page. You can also log or block third-party requests that are unsuccessful or do not meet certain criteria. If you can, load third-party scripts from your own server rather than the vendor’s.

Casper.com published a detailed case study of how they reduced their response time by 1.7 seconds with self-hosted Optimizely. It might be worth it. (Image source) (Preview larger image)

Another option is to establish a content security policy (CSP) to limit the impact of third-party scripts, such as not allowing audio or video downloads. The best option is to embed the script through

For example, you might have to use

Consider using Intersection Observer; This will keep the AD still in the IFrame, but you can schedule events or get the required information (for example, AD visibility) from the DOM. New policies, such as functional policies, resource size limits, and CPU/ bandwidth priorities, can be looked at to limit harmful Web features and scripts that can slow down browsers, such as synchronous scripts, synchronous XHR requests, document.write, and outdated implementations.

To stress test a third party, check the bottom-up summary in the performance profile page in DevTools to test what happens if the request is blocked or timed out — for the latter, You can use the WebPageTest Blackhole server, blackhole.webpagetest.org, it can be a specific domain points to your hosts file. It is best to self-host and use a single host name, but you can also generate a request map that exposes a fourth party call and detects when the script changes. You can audit third parties using the Harry Roberts approach and generate spreadsheets like this one. Harry also explained the audit workflow in his discussion on third-party performance and auditing.

Image credit: Harry Roberts

38. Set the HTTP cache header

Double check that expires, max-age, cache-Control, and other HTTP cache headers are set correctly. In general, resources are cacheable either for a short time (if they can change) or indefinitely (if they are static) — you just need to change their version in the URL as needed. Disable the last-Modified header, because any static resource with it will result in a conditional request with an if-Modified-since header, even If the resource is in the cache. The same goes for Etag.

Use cache-Control: immutable, designed for fingerprint static resources, to avoid revalidation (as of December 2018, Firefox, Edge, and Safari all support this feature; Firefox only supports https:// transactions). In fact, “of all pages in the HTTP archive, 2% of requests and 30% of sites appear to contain at least one immutable response. Also, most sites that use it have static resources with a long, fresh life cycle.”

Remember stale-while-revalidate? As you may know, we use the cache-control response header to specify the Cache time, for example: cache-control: max-age=604800. After 604,800 seconds, the cache will refetch the requested content, causing the page to load slowly. You can avoid this slow down problem by using stale-while-revalidate. It essentially defines an additional window of time during which the cache can use the old static resource as long as it is asynchronously revalidating itself in the background. Therefore, it “hides” latency from clients (both on the network and on the server).

In October 2018, Chrome released an attempt to handle stale-while-revalidate in the HTTP cache-control header, so it should improve subsequent page loading delays since the old static files are no longer in the critical path. Result: RTT of repeated page visits is zero.

You can use Heroku’s INTRODUCTION to HTTP Caching headers, Jake Archibald’s “Caching Best Practices” and Ilya Grigorik’s INTRODUCTION to HTTP Caching as guides. Also, be aware of header changes, especially those related to CDNS, and pay attention to the Key header, which helps avoid extra round-trip validation when a new request is slightly (but not significantly) different from a previous one (thanks Guy!). .

Also, double check if you’re sending unnecessary headers (such as X-powered-by, pragma, X-UA-compatible, Expires, etc.), And contains useful Security and performance headers (such as Content-security-policy, X-Xss-protection, x-Content-Type-options, etc.). Finally, keep in mind the performance cost of CORS requests in a single-page application.

• Front-end Performance Optimization Year 2019 – Part 1
• Front-end Performance Optimization Year 2019 – Part 2
• Front-end Performance Optimization Year 2019 – Part 3
• [translation]2019 Front-end Performance Optimization Annual Review – Part 4
• Front-end Performance Optimization Year 2019 – Part 5
• Front-end Performance Optimization Year 2019 – 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.