12.23 Yuan Chuanghui·Shanghai Station, let’s talk about LLM infrastructure

Introduction

CLS measures the maximum burst of each unexpected layout shift that occurs over the lifetime of the pageThe layout shift score . Layout changes occur because browsers tend to load page elements asynchronously. What's more, there may be some media elements on your page whose initial size is unknown. This combination means that the browser cannot determine how much space an individual element will take up until it has finished loading. Therefore, drastic layout changes caused by this uncertainty will lead to a high CLS score, which means that the user experience will be poor.

The calculation formula of cumulative layout offset = influence proportion * distance proportion (Reference: https://web.dev/articles/cls ?hl=zh-cn)

Influence ratio:The ratio of all unstable elements in the previous frame to the visible area of the current frame (total area of the viewport) The union is the influence ratio of the current frame.

Distance scale:Distance scale is anyunstable elementThe maximum distance of movement within the frame (horizontally or vertically) divided by the maximum size of the viewport (width or height, whichever is larger)

solution

1. Find all factors that may cause cumulative layout offset

2. Determine what factors caused such a large cumulative layout offset? We need to find a reliable tool to help us confirm and locate the specific cause.

3. What are the problem codes that lead to these reasons? Once we find the code, how should we solve it.

Plan execution

1 Factors leading to cumulative layout offset

The most common causes of poor CLS include:

Picture without size
Unsized ads, embeds, and iframes
Dynamically injected content, such as ads without dimensions, embeds, and iframes
web fonts

2 Use auxiliary tools to confirm which factors

You can first use the internal monitoring platform to find the pages most visited by users, and use lighthouse to analyze the performance of each page one by one.

(Note: Friends outside the site can find out the users’ commonly used pages based on their own system understanding~)

Case--take our project A as an example

1. In the performance business overview, we compared the performance comparison of the top 10 URLs with the number of visits and the list of the top 100 page performance reports, and found that the two pages most visited by users—— Home page Alist and Bdetails page.

2. Use lighthouse to analyze the performance of the two pages locally (click the analyze page load button to trigger the detection. To ensure that the overall performance is biased towards the real scenario, it is recommended that you perform the detection Perform some common operations on the current page)

The performance screenshots are as follows:

1. A list

2. B details page

3 solutions

Based on the reasons given in the above report for the extremely large CLS value, modify them one by one.

Among them, there are two main reasons for the CLS exception of list A data on the homepage: First, the excel image has no size; second, the height of the table is not clearly set, causing the interface to dynamically fill the screen directly after returning the data, causing cumulative layout offset. larger. The main reason for the CLS exception on the B details page is the same as the home page. The table height is not set, causing the CLS to be too large.

For the above two reasons, the following modifications are made:

1. Specify aspect-ratio based on the original size of the image. After the change, the CLS dropped from0.425 to 0.422. It can be seen that the main influencing factor is the height of the table.

<template>
...
<el-table-column label="自己的label" min-width="140">
        <template slot-scope="scope">
          <img
            class="monitor-link"
            :src="excelIcon"
            width="40"
            @click="(e) => handleDownload(scope.row)"
          />
        </template>
      </el-table-column>
</template>
<style lang="scss" scoped>
.monitor-link {
  cursor: pointer;
  aspect-ratio: 40/42;
}

</style>

2. Reset the table height according to the current page layout. After the change, CLS dropped from 0.422 to 0.041. The optimization effect is remarkable.

<template>
  <div class="table-wrap">
   <!-- 使用max-height，而不是height : 为了解决增减展示列造成的固定列高度错位展示问题，方法参考https://github.com/ElemeFE/element/issues/4976-->
    <el-table
      class="fixed-head-table"
      :data="data"
      width="100%"
      :max-height="tableHeight" //设置高度表格 
      header-row-class-name="table-header-row"
    >
    ...
  </el-table>
  </div>
</template>
<script>
export default {
  data() {
    return {
      tableHeight: 0,
      ...
    };
  },
  mounted() {
    this.$nextTick(() => {
      // 后面344一般是根据你上下导航栏、表单等的高度来减掉即可
      this.tableHeight = window.innerHeight - 344;
    })
  },
}
</script>

After the above optimization, the two pages with excessive cumulative layout offset achieved better optimization results. The CLS of list A dropped to 0.041, and the CLS of detail page B dropped to 0.136. The screenshots are as follows:

Online effect

Since 2023.11.14, after the above performance optimization code was put online, as of 11.30, checking the internal performance monitoring platform, it can be seen that within 15 days of going online, the overall performance score of project A rose from the previous 59 to 70 points to 87 points, reaching Performance experience good results.

Author: JD Retail Li Mengshuang

Source: JD Cloud Developer Community Please indicate the source when reprinting

How to use Zhulong and Google plug-ins to optimize CLS (cumulative layout offset) | JD Cloud technical team