Long page loading time during browsing irritates many internet users. Furthermore, measuring the performance of a loading page is not a simple task. To get rid of this problem, Google community has taken a step. The Google Developers started working in a team which is merely focusing on the Progressive Web Metrics (PWM’s).
Now you must be thinking that what are Progressive Web Metrics and which role they play in loading a page? So, let’s discuss the history of browser metrics first in order to understand Progressive Web Metrics better:
A few years back, we used to measure the performance basically on 2 main points or can say events. These two points are as follows:
- DOM Content loaded
- Load event
DOM Content loaded:
It usually starts functioning when a page is loaded. However, after that, it is time for scripts to be executed. That was the negative point of this event. Because the scripts with large sizes used to take much time in executing.
Load event:
The load event is launched when the page is completely loaded. At this moment, the users can interact with the page or the application but not both at the same time. They have to opt for only one thing.
Let’s talk about the reddit.com. The Chrome Developing tools tried to help us regarding the tracing of the timeline of reddit.com. These tools mark the timeline points with the help of blue and red vertical lines. Some users have a perception that these metrics do not help us so far. However, if we move forward and have a look into the window.onload, then it may slightly change the user perception about the metrics.
Drawbacks of Load & DOM Content loaded
There were some drawbacks of these two points or events. The first problem was with the “DOM Content Loaded” because it takes some time to process and execute Javascript. The time depends on the size of the scripts. If the scripts are too big in size, then time duration would be longer. On the other hand, Load event also lacks the timing perspective. If we start measuring the timeline trace, it will take probably 10 seconds for completing its loading process even with the 3G networking. It also takes too much time for analyzing a page performance bottleneck.
In the end, can we depend on these metrics? What type of information do they provide us?
user’s perception
Before progressing with this theory, we should understand the user’s perception.
- How do the users take the page loading process from the beginning to the end?
- Why is the loading process of too much importance?
Let try to find the answers to the above questions by using a histogram. The X-axis in the histogram shows load times. Whereas, the Y-axis represents the relative number of users who faced a load time in a specific time frame. Some users suffer extremely long loading time while others have to wait for less than 2 seconds. However, there are very few users who face less than 2 seconds of load time. Resultantly, the load time is nearly 17 seconds for our assumption. It does not imply the perception of the user about the page loading. There are three possibilities or issues which a user had seen in the duration of 17 seconds:
- A Blank screen
- Partly loaded page
- Frozen loaded content where a user could not engage himself in other activity.
The above most common issues only indicated the following answers:
- Make more improvement for the better experience of the user.
- Increases the ratio of users towards the application
- Enhance the scope of benefits which are being enjoyed by the product owners (users, customers or money).
Possible thoughts
Now, let’s try to read the user’s mind and predict the possible thoughts, which a normal user has in his/her mind for the duration of 17 seconds of load time
- Is it processing?
Has the server started responding successfully or not?
- Is it useful content?
Has the processed content of the page is sufficient for moving forward?
- Is it done or still loading?
Can I start working on a page or is it still busy?
- Is it pleasant?
Was it delightful to face the lacking scrolling junk, animation junk, flash of unstyled content, and slow web fonts, etc.?
Now, the question is that if DOM Content Loaded or load metrics cannot answer the questions mentioned above then which one can answer?
Progressive Web Metrics (PWM’s):
Progressive Web Metrics basically consists of a list. This list is supposed to be a helping hand in detecting the performance affected areas. In opposition to DOM Content Loaded or load metrics, Progressive Web Metrics provides detailed information about the page loading to the developer.
Let’s have more clear understanding of Progressive Web Metrics by using reddit.com trace. It will also help us to understand the meaning of each metrics in its depth.
First Paint (FP):
We assumed that we had only 2 metrics. Whereas, developing tools also provide one more metrics which is First Paint (FP). Basically, it is the first step of Page Load. It implies the time period during which a page is painted on the screen. Basically, it shows the blank screen at the initial stage. It is the first step that users face. Here is the example of FP:
Simplified Chromium Graphics Layer:
For a better understanding of its working, let’s have a look at the Chromium graphics layer. Initially, FP event is launched when the graphics layer is being printed on the screen. There is no text, image or any canvas content. But developers tried to use some information out of the initially given list.
As it is not standardized metrics yet, so measuring values can be too difficult. To cope with this problem, different techniques were used. Like:
- Putting together a requestAnimationFrame
- Gathering loaded CSS resources
- Also using DOM Content Loaded and load events which are problematic as described above
After all the efforts, it shows the low-level value as text, image, and canvas may show up even later than the launch of the First Paint event. The reason behind this low performance is clearly the weight of the web page, CSS, or Javascript resources size.
The above knowledge is not a part of Progressive Web Metrics (PWM’s). But it would be helpful in understanding the metrics. So we were in need of some other metric that could clearly represent the actual drawing of the content.
First Contentful Paint (FCP):
In this second metrics, users start seeing some content appearing on the page. It happens after the blank screen. This content can be anything i.e, first paint of text, first paint of SVG, or first paint of canvas, etc. After the appearance of some content, the user asks himself that finally is it processing? Has page started loading after he/she wrote a URL in the browser and pressed enter?
First Paint vs. First Contentful Paint
While talking about Chromium, we saw how the First Content Paint event was launched. In First Contentful Paint, the actual appearance of a text, image or canvas happens. One more thing is that the font of the text is usually ignored during this process. The measurement of the time difference between the FP and FCP ranges from milliseconds to seconds. It tells us about the significance of the metric which represents the real first paint of content.
Importance of First Contentful Paint (FCP) metric for developers:
There are 2 reasons behind the long time taken by the First Contentful Paint:
- Your network might have poor performance.
- The resources which include Index and HTML are too large that cause a delay in delivering them.
First Meaningful Paint (FMP):
In this stage, primary contents of the page appear on the screen. Therefore, users think that Is it enough useful content?
What is meant by this primary content? It may be:
- Header and text for the blogs and articles
- Desired text for which you have use search engines
- Any graphical shapes of the products which refer to E-commerce
But it does not include if it shows any:
- Spinners or something related to it
- Flash of unstyled content (FOUC)
- A navigation bar or uncomplete page header
In First Meaningful paint (FMP), it brings the biggest layout change on the screen. We used Layout analyzer to calculate the current print because of Chromium implementation. Layout analyzer collects all the layout changes by finding the time of the biggest layout changes. The time difference between painting this layout on the screen is called First Meaningful paint (FMP).
Importance of First Meaningful paint (FMP) metric for developers:
The reason behind the long loading time of primary content might be:
- The high loading priority of different resources. These resources maybe images, styles, fonts or JavaScript. As a result, it causes the blockage of First Meaningful paint
The developer can take a look at these factors to improve the performance of their web pages.
Visually Ready:
It seems like the page is almost loaded. But the browser has not yet completed executing all the scripts.
Estimated Input Latency:
We use this metric to measure the application response time on the user input. However, before going into its depth, let’s understand some terminology to be used in this metric.
Long tasks:
The browser usually takes the user’s input into “User interface (UI)” tasks. Then, it put these inputs into a pipeline (queue) of the main continuing line (thread). On the other hand, the browser also has to perform the execution and compilation of JavaScript on a page (Application Task). If these application tasks take too much time, user input may get blocked unless they are not fully executed. This results in a delay of interaction with a page. In response to this delay, the page may act like Junky and Leggy. These time-taking tasks of compiling and execution of JavaScript results into the larger mass which might be longer than 50 milliseconds.
By using Estimated Input Latency, the users suppose the page responses instantly. However, if the main thread is engaged in proceeding every long task (application task) one by one, it may affect the performance and bother the user. It implies that the user experience is of critical nature regarding the application.
First Interactive (FI):
After reaching this phase, the users have a question in their mind “Is it done or still loading?” They want an answer after seeing Visually Ready Page and want to connect with it.
When First Interactive (FI) occurs, it satisfies the following conditions:
- First meaningful paint
- DOM Content Loaded has been fixed
- Apparently, 85% page isVisually Complete
The First Interactive (FI) metric is separated by two metrics:
- Time to First Interactive (TTFI)
- Time to First Consistently Interactive (TTCI)
The main causes behind metrics separation are as follows:
- Defining minimal interaction with User Interface (UI). UI responses should be responding. However, it does not affect much if does not respond well.
- A complete and delightful website interaction which follows the guideline of RAIL Model.
Time to First Consistently Interactive (TTCI):
Using reverse analysis, we can see that the page loading activity is quiet for 5 seconds and realize that the browser has no more time taking tasks. The resultant period is known as a quiet window. Therefore the time after quiet window and before the first long task will be called as a Time to First Consistently Interactive (TTCI).
Time to First Interactive (TTFI):
This metric is a little bit different from the TTCI. It analyzes the traces from start to the end. After the First Meaningful Paint (FMP), there should be a quiet window for 3 seconds. After reaching this point, we can say that page is interactive and delightful for the user. There is a slight chance of lonely tasks during or after quiet window. These lonely tasks are unnoticable. Refering to lonely tasks; these are not executed from First Meaningful Paint (FMP). They have an isolation of 250ms execution time period. This execution time period is called as Envelope size. It also requires the 1-second quietness before and after Envelope size.
Examples of suc tasks can be any third party ads or analytics scripts.
These Lonely tasks often caused adverse effects on a page because of its timing longer than 250ms. For instance, this effect can be the detection of an AdBlocker.
Importance of TTFI and TTCI metrics for developers:
TTFI and TTCI help developers when a thread takes a lot of time between Visually Ready and First Interactive. This is the much hardest hurdle in the performance. Moreover, there is no customary way of fixing this type of problem. Furthermore, it varies according to different application relevant to specific cases.
Visually Complete/ Speed Index:
We can check that whether a page is visually complete or not with the help of Speed Index algorithm. Speed Index algorithm takes screenshots of the page and performs pixel analysis on them to check if the page is visually complete. It is quite a challenging task, because different pages have different formats and types of images. So. the results will also vary.
The Speed Index algorithm also represents the median value of visually complete results. The less value of Speed Index represents better performance.
It’s time to know the user’s reaction when it shows 100% visually complete. At this point, the user asks himself that Is it pleasant?
Conclusion (Progressive Web Metrics):
Progressive Web metrics is a broad term and we still need to explore it further. We have deep analyses to know about its phases, and it’s working. To some extent, now we have a clear image of Progressive Web Metrics in our minds. In the end, I want to insert few links to the tools for the measurement of similar metrics.
Meanwhile, I would suggest you to use Lighthouse or pwmetrics for getting results of all these metrics. Furthermore, there are native API’s known as PerformanceObserver which can be beneficial for you to achieve your measurement goals if you intend to perform performance measurements manually.
Example from specification:
const observer = new PerformanceObserver(list => { list .getEntries() // Get the values we are interested in .map(({ name, entryType, startTime, duration }) => { const obj = { "Duration": duration, "Entry Type": entryType, "Name": name, "Start Time": startTime, }; return JSON.stringify(obj, null, 2); }) // Display them to the console .forEach(console.log); // maybe disconnect after processing the events. observer.disconnect(); }); // retrieve buffered events and subscribe to new events // for Resource-Timing and User-Timing observer.observe({ entryTypes: ["resource", "mark", "measure"], buffered: true });
Leave a Reply