How fast your web pages are — from DOMReady to Element Timing

some crap

As we all know, writing an article needs a title. Although those of us who work on code generally like to go straight to the point, subject to the constraints of style and the requirements of publishing carriers, sometimes we have to think of a title. And starting a title is no less than giving a function name or variable name. For this article alone, I have several draft titles such as: "The Evolution of Page Load Metrics", "Element Timing: A New Page Speed ​​Metric", "How to Most Accurately Measure Page Load Speed", " Page Loading Speed ​​under the New Front End", even "Element Timing In Action", "Learn to Measure Page Speed ​​in Three Minutes". In the end, I took into account the readers' affordability, the editor's opinion, and the most important thing: my weak writing ability, so I took such a very popular one, which will not be regarded as garbage at first glance, nor will it be picked by others. Come out carefully to find the difference in the title.

Well, let's not talk nonsense, let's get to the point directly.

DOMReady

In ancient times (referring to the jQuery era 10+ years ago), our web development was still stuck in writing static page structures, using JS scripts to directly manipulate the DOM, adding and deleting some extra page elements. At this point, DOMReady can basically meet the needs of calculating the completion time of page loading. DOMReady (DOMContentLoaded in the DOM event) represents that the page document is completely loaded and parsed, which generally includes HTML document analysis, DOM tree creation, and external chain script loading. , the execution of external chain scripts and the execution of inline scripts without waiting for the loading of style files, image files, and subframe pages. Generally, a timestamp is placed in the page header, and then a timestamp is placed in the DOMReady event of jQuery, and we can calculate the approximate DOMReady time.

Navigation Timing

In the Middle Ages (referring to the Ajax era about 10-5 years ago), the interactive forms of web pages were more abundant and diverse. The rich web applications led by Gmail not only greatly enhanced the user experience, but also brought fine-grained web page loading time records. need. Therefore, since 2010, the Web Performance Working Group has introduced a large number of time information records for the Web, which can be obtained through the performance property of the window object. This is what we later know as Navigation Timing.

The data provided by the Navigation Timing interface is roughly as follows:

Basically, it covers the time from when the web page starts a network request to when the page is fully loaded and the resources are executed and the DOM node is initialized. Using performance.timing directly, we can easily obtain these times to help analyze page load times.
​

FP, FCP and LCP

In recent times (referring to the React era about 5-2 years ago), various front-end frameworks (React, Vue, etc.) have sprung up like mushrooms, and the emergence of Webpack, a front-end construction artifact, has made the development of Web pages difficult. Falling down rapidly, complexity also skyrockets. Front-end-heavy applications are popular, and the time it takes to load scripts on a page is also rapidly increasing. Many websites adopt a progressive loading strategy for experience, so as to solve the problem of excessive white screen time when waiting for scripts to execute. Hence, Progressive Web Rendering Metrics came into being.

Progressive web metrics generally include the following:

• First Paint (FP): The full name is First Paint, which marks the point in time when the browser renders any content that is visually different from the content of the screen before navigation
• First Content Paint (FCP): The full name is First Contentful Paint, which marks the point in time when the browser renders the first content from the DOM, which may be text, images, SVG or even <canvas> elements.
• First Effective Paint (FMP): The full name is First Meaningful Paint, which marks the time point when the main content of the page is drawn, such as the video component of the video application, the weather information of the weather application, and the news entry in the news application.
• Largest Content Drawing (LCP): The full name is Largest Contentful Paint, which marks the point in time when the visible element with the largest "content" in the visible area begins to be drawn on the screen.

Among them, FMP has been basically deprecated because it relies on algorithms to guess valid elements. The visualization meaning of these indicators can refer to the following two figures:

Because of the complex elements of the page are often a lot of elements observed FCP may only insignificant a Loading marker or a sidebar, so for real users, and can not represent the "first screen time" page. On the contrary, in some pages with complex logic, due to the long execution time of JS code, or relying on many back-end interfaces to render the page, the most important data display time of the page is often much longer than the time when the page OnLoadEvent is triggered. , the most intuitively perceived "first screen time" for users is often the LCP time.

This is why many front-end page performance tools now list LCP as an important reference indicator.

Element Timing

Modern period (refer to about 1-0 years ago, front-end micro-era), computational logic LCP browser is given in different pages, the browser thought largest visible element it may not be our business content that really matters. And in the modern era of micro-frontends, not only different pages of the same application use single-page mode, but even the loading of different sub-applications may be driven hash For such a single-page application, none of the above indicators can actually satisfy the recalculation when switching between different pages after the main frame is loaded. So can we only rely on the business development itself to actively manage and report the loading time in the code? Not necessarily.

Let's take a look at a new draft from the W3C, the Element Timing API: https://wicg.github.io/element-timing/ . Although this API is still in the draft stage, Chrome and Edge are already supported in the new version: Compatibility

The purpose of the Element Timing API is to allow web developers or analysis tools to measure the rendering time of key elements on the page. Compared to LCP, we can define key elements ourselves, which is the greatest charm of Element Timing.
Elements supported by Element Timing are:

• <img> element
• <svg> in <img> elements
• poster image in <video>
• Element with background-image
• a set of text nodes

for example:

<img src="image.jpg" elementtiming="big-image">
<p elementtiming="text" id="text-id">text here</p>

const observer = new PerformanceObserver((list) => {
  let entries = list.getEntries().forEach(function (entry) {
      console.log(entry);    
  });
});
observer.observe({ entryTypes: ["element"] });


// 输出 entry 内容：
// {
//   duration: 0
//   element: p.aimake-site-name
//   entryType: "element"
//   id: ""
//   identifier: "text-id"
//   intersectionRect: DOMRectReadOnly {x: 236, y: 130, width: 144, height: 28, top: 130, …}
//   loadTime: 0
//   name: "text-paint"
//   naturalHeight: 0
//   naturalWidth: 0
//   renderTime: 10850.899999976158
//   startTime: 10850.899999976158
//   url: ""
// }

However, it should be noted that not all text nodes can be elementtiming="" . There is a note in WICG's explanation:

We say that a text node belongs to the closest block-level Element ancestor of the node. This means that an element could have 0 or many associated text nodes with it.
We say that an element is text-painted if at least one text node belongs to and has been painted at least once. Thus, the text rendering timestamp of an element is the time when it becomes _text-painted_.
Let the text rect of a text node be the display rectangle of that node within the viewport. We define the text rect of an element as the smallest rectangle which contains the geometric union of the text rects of all text nodes which belong to the element.

It's hard to read, but what it actually means is that only text nodes that meet the following conditions can be recorded:

• must be block-level elements : As <p> , <h1> , <div> , <section> the like, i.e., a separate <span> inline elements and other elements, adding instant elementtiming="" attribute can not be recorded.
• direct child node must contain one or more text nodes : e.g. plain text, <span> , <i> , <b> , etc. Block-level elements such as <p> <img> images do not count.

To give some examples to understand:

<html>
  <p elementtiming = "p1"><p>1</p></p> <!-- 无效 -->
  <p elementtiming = "p2">2</p> <!-- 有效 -->
  <span elementtiming = "span1">span1</span> <!-- 无效 -->
  <div elementtiming = "div1"><image elementtiming = "img1" src="https://img.alicdn.com/tfs/xxx.png"></image></div> <!-- div1 无效，其中的 img1 有效 --> 
  <div elementtiming = "div2"><span>1</span></div> <!-- 有效 -->
  <div elementtiming = "div3"><p>2</p></div> <!-- 无效 -->
  <div elementtiming = "div4"><h1>3</h1></div> <!-- 无效 -->
  <div elementtiming = "div5"><b>4</b></div> <!-- 有效 -->
  <b elementtiming = "b1">b1</b> <!-- 无效 -->
  <i elementtiming = "i1">i1</i> <!-- 无效 -->
  <h1 elementtiming = "h1">h1</h1> <!-- 有效 -->
  <section elementtiming = "section1">section1</section> <!-- 有效 -->
</html>

After adding elementtiming custom attributes, when the marker image or text nodes are actually rendered , the browser will record the time. Therefore, we can let developers directly add this attribute to the elements that first screen in different applications, and the collection script can uniformly collect the time point (renderTime) of element drawing PerformanceObserver

By using the Element Timing API, we can more accurately record the loading time of each application, page, and even function modules. This is the most modern and cutting-edge page load time solution, the rest will eventually be buried in the dust of history! kidding

some other crap

There are talented people in the country, each leading the way for hundreds of years

Generally speaking, the ending is not as important as the title, so I don't need to think about N endings, so I can simply summarize: No matter how far the front end develops, Timing's standards will always catch up with you!

I hope that if there are readers who have been inspired a little bit, they can benefit us by writing a performance library that includes Element Timing indicators. After all, I am lazy, and the above are all my own YY ​​usage. Thanks in advance.

Author: ES2049 | Anonymous

The article can be reproduced at will, but please keep the original link.
We welcome you with passion to join ES2049 Studio , please send your resume to [e-mail] .