🔙 – How to speed up requests?

In the last stop, we briefly covered server-side processing and response, and we’ve come a long way so far, and we’ve got a lot of “performance optimization weapons.” like

  • Optimize with all levels of caching
  • Perform DNS query or establish a connection in advance to expedite requests
  • Avoid unnecessary time consumption on the server side
  • …

However, don’t be complacent, there is still a lot of work to optimize. Now it’s time for the client to receive the response.

The main work

There’s a lot for the browser to deal with at this stage, so to better understand performance tuning, we’ll break it down into several parts:

  • Page DOM parsing;
  • Page static resources loading, including page reference JavaScript/CSS/ images/fonts, etc.
  • Static resource parsing and processing, such as JavaScript execution, CSSOM construction and style composition, etc.

The general process is to parse the DOM structure of the page, load it when it encounters external resources, and use it when it is loaded. But because this section is quite extensive, we’ll focus on page parsing in this section (the rest will be covered in the Write section).

1. Note the location of the resource in the page document

Our goal is to parse and process content as soon as we receive it, send requests as soon as pages have dependent resources, and process responses as soon as we receive them. However, this beautiful goal can be spoiled by our carelessness.

Both JavaScript scripts and CSS stylesheets have control over DOM element attributes, especially style attributes. It’s like a multithreading problem. In server-side multithreaded programming, locks are often used to ensure mutual exclusion between threads. Back to the front end, there are now two parties competing for the same resource, and obviously there will be a mutual exclusion problem. This leads to some mutually exclusive relationships between DOM parsing, JavaScript loading and execution, and CSS loading and usage.

Just look at the relationship between DOM and CSS, as shown below:

HTML is parsed into a DOM Tree, CSS is parsed into A CSSOM, and the two are combined into a Render Tree, executed in parallel, perfectly. However, when JavaScript entered the scene, the situation changed:

According to the standard specification, the DOM is accessible in JavaScript. Therefore, DOM parsing is blocked when JavaScript is encountered. At the same time, to avoid races between CSS and JavaScript, the CSSOM build blocks JavaScript script execution. So that sums it up

JavaScript blocks DOM builds, and CSSOM builds in turn block JavaScript execution.

So that’s why, as a best practice for optimization, we generally recommend putting CSS stylesheets in (the head of the page) and JavaScript scripts at the end of (the end of the page).

Some explanation of this section can be found in this article [1].

2. Use defer and async

As mentioned above, when DOM parsing encounters a JavaScript script, parsing stops, the script is downloaded and executed, and parsing resumes, essentially blocking THE DOM build.

Other than putting the script at the end of the body, is there any way to optimize it? There is one.

You can use the defer or async properties. Both prevent downloads of JavaScript scripts from blocking DOM builds. But there are also differences between the two, the most intuitive performance is as follows:

Defer will be executed in the order the scripts appear after the HTML parsing is complete; Async, on the other hand, starts execution as soon as the download is complete and blocks page parsing without ensuring the order of execution between scripts.

Due to their characteristics, it is recommended to use Async on some JavaScript scripts that are unrelated to the main business. For example, statistics scripts, monitoring scripts, and advertising scripts. These scripts are typically a stand-alone file with no external dependencies, no DOM access, and no strict execution timing restrictions. Using async on these scripts can effectively prevent the loading of these non-core functions from affecting the speed of page parsing.

3. Compress page documents

The HTML document size can also greatly affect the response body download time. Generally, HTML content compression (UGLIFY) is combined with text compression algorithms (such as GZIP) for text compression. Resource compression is covered in more detail in the next section.

As an aside, do you know when the DOMContentLoaded event related to page parsing is triggered? What does interactive/complete readyState stand for? If you don’t know much about it, look at HTML Spec [2].

To paraphrase:

Returns “loading” while the Document is loading, “interactive” once it is finished parsing but still loading subresources, and “complete” once it has loaded.

The readystatechange event fires on the Document object when this value changes.

The DOMContentLoaded event fires after the transition to “interactive” but before the transition to “complete”, at the point where all subresources apart from async script elements have loaded.

Ok, in this stop we have learned the page parsing process and optimization.

As mentioned at the beginning, parsing the page, loading the resource, and using the resource are three closely related processes. Here we will focus on page parsing, but in the next leg of our “front-end performance optimization tour”, we will cover many other optimization points in this section together.

Next stop – Page static Resources [TODO] 🔜

“Performance Tuning” series

  1. Bring you a full grasp of front-end performance optimization 🚀
  2. How can caching be used to reduce remote requests?
  3. How can I speed up requests?
  4. How to speed up page parsing and processing? (this paper)
  5. What is the general idea of static resource optimization?
    1. How to optimize performance for JavaScript?
    2. How to optimize the PERFORMANCE of the CSS?
    3. Graphics are great, but they can also cause performance problems
    4. Do fonts also need performance optimization?
    5. How to optimize performance for video?
  6. How can you avoid performance problems at run time?
  7. How can preloading improve performance?
  8. The end of the

At present, all the content has been updated to ✨ fe-performance-Journey ✨ warehouse, and the content will be synchronized to the nuggets one after another. If you want to read the content as soon as possible, you can also go directly to the repository.

The resources

  1. Deciphering the Critical Rendering Path
  2. HTML5 spec: current-document-readiness
  3. Async Defer — JavaScript Loading Strategies
  4. Speed up Google Maps(and everything else) with async & defer
  5. HTML5 spec: parse HTML (the end)