Understand Web performance concepts and common analysis tools

Understand Web performance concepts

Web performance is about improving the user experience. The core is: reduce waiting, use not card

The following will be introduced in two parts:

1. Performance metrics: The goal is to solve the waiting problem so that users can see the page as soon as possible and interact with it
2. Experience optimization: The goal is to not get stuck during use, or feel less stuck

Performance indicators

Purpose: To solve the waiting problem, so that users can see the web page as soon as possible, and can interact (the following indicators and tools are mainly related to the first screen loading)

Core:

1. Want to see things as soon as possible (see FCP below)
2. Want to see everything as soon as possible (see SI, LCP below)
3. Want to operate as soon as possible (refer to TTI, TBT below)
4. Page element layouts are best left unshifted (see CLS below)

How to use tools to generate performance reports with one click and provide solutions?

Blog’s companion series: Web performance analysis tools PageSpeed Insights and Lighthouse Tutorials

Performance Specifications

1. FCP (First Contentful Paint) : First content rendering, see the sister blog:Web Performance – White screen time details and optimization
   • From – the user starts typing the URL (to start the navigation) to – something appears on the page (the browser renders the first DOM. Images, non-white < canvas > elements, and SVG are considered DOM content, and anything in iframe is not included)
2. TTI (Time to Interactive) : first actionable (e.g. clickable and scrollable)
   • From — the user starts typing a URL (start navigation) to — actionable (e.g. clickable and scrollable)
3. SI (Speed Index) : indicates the Speed Index
   • shows how quickly the contents of a page are visibly populated.
   • How fast you can display the content of the page (all the content is rendered)
4. Total Blocking Time (TBT) : indicates the Total Blocking Time
   • Total elapsed time of all long tasks over 50ms between FCP and TTI
   • TBT = (T(Long Task 1) -50ms) + (T(Long Task 2) -50ms) + (T(Long Task 3) -50ms)
     • Long Tasks are JavaScript code that keeps the main thread busy, delays user interactions, and ‘freezes’ the UI
     • Why 50ms? RAIL model recommendations
5. Largest Contentful Paint LCP (Largest Contentful Paint) : “Maximum content” rendering time on the current page
   • Why concepts are born: Sometimes simpler is better. Based on discussions in the W3C Web Performance Working Group and research at Google, it has been found that a more accurate way to measure when the main content of a page is loaded is to look at when the largest elements are rendered
     • Range: visible area. How to find the largest element, see link above
6. CLS (Cumulative Layout Shift) : Cumulative Layout Shift
   • The position of the cumulative layout movement in the visual area
   • The offset of the element, such as the initial rendering of element a at position (1, 1), turns out to be the bit value of element (7,7) one second later. May cause the user to mistakenly touch

Experience optimization

Purpose: Not stuck in the process of use, or feel less stuck (the following focus is optimized in the process of use)

There are no tools available to quantify the experience. So here are some examples and solutions, hoping to clarify some possible experience problems

The plan is presented in two aspects:

1. Smoothness and Interactivity
2. Perceived Performance (Perceived performance, which may be slow in reality but not Perceived as slow)

Smoothness and Interactivity

Experience points such as: Is scrolling smooth? Can the button be clicked? Does the popover open quickly and does the animation transition smoothly?

Best practices include:

1. Use CSS animations instead of JavaScript for animations
2. AvaScript is to be used for animation, with Windows. RequestAnimationFrame (), he will tell the browser until the next redraw calls the specified callback function to update the animation. Much higher performance than the stiff timer
3. Minimize the number of rearrangements and redraws required due to DOM changes

Perceived Performance (Perceived performance, which may be slow in reality but not Perceived as slow)

Sometimes it may be hard to make your site run faster, but you’ll probably be able to make it feel faster.

A simple example:

1. An action may take a long time (such as interface loading, long Tasks). You can use a loading icon + text (such as “loading like crazy”) to tell the user that your action (such as clicking) has taken effect and the application has started loading
2. Skeleton screen
3. Large images can be loaded with thumbnails first
4. If there are ads, images or other resources that may cause the page to be rearranged and redrawn, it is best to plan the layout in advance and leave space. (Fluency and interactivity also apply.)

---

Code word is not easy, praise encouragement

---

Performance optimization set quick entry:

• How to determine the best caching strategy for front-end resources?
  • Starting point for browser Cache- > cache-control
  • Browser caching mechanism (combined with response headers)
• The relationship between <link> and <script> and DOM parsing rendering
  • Introduction to browser multi-process architecture
• Understand Web performance concepts and common analysis tools
  • Using the Web performance analysis tools PageSpeed Insights and Lighthouse Tutorial
• Web Performance – White screen time details and optimization
  • Web Performance -HTML and CSS optimization
  • Web Performance – Image optimization
  • Web Performance – Font optimization
  • Web Performance – JS optimization
  • Web Performance – Optimizing DOM operations (rearrange and redraw)
  • The basic principle of TCP transmission and optimization
  • Web Performance -CDN architecture introduction and optimization
    • Configure the CDN of the third-party library in the Webpack project and perform CDN fault tolerance
• Front-end performance monitoring for real users