background
product: Look at this page load so slowly, how can there be users? (and threw me a screen)IThe front-end needs to load VUE, JS, HTML, CSS, these all need time, is not it? Let alone interface request, database query, JS execution, these all need time is not it, so it is normal to load slowly, let the user use wifi. (HMM… Peace of mind, that’s all.product: Didn’t your last company go under because of good employees like you? !
Let’s take a look at the video:
foreplay
If you want to practice this skill, you must first go to the palace. The forehead.. Not right. To solve the performance, must first analyze. There are many kinds of checkup packages on the market, but they are all the same. What is the drug? We’ll explain that below. For my performance checkup, I chose Google’s own son, LightHouse.
Specific meaning
FCP (First Contentful Paint)
The First Contentful Paint (FCP) metric measures the time it takes for any part of the page content to appear on the screen from the start of the page. For this metric, “content” refers to text, images (including background images), < SVG > elements, or non-white
SI (Speed Index)
The Speed index measures the visual display speed of content during page loading.
LCP (Largest Contentful Paint)
The LCP measures when the largest content element in the viewport appears on the screen. This is about how long the main content of the page is visible to the user.
TTI (Time to Interactive)
TTI measures how long it takes for a page to fully interact. Pages are considered fully interactive when:
- Pages display useful content, as measured by First Contentful Paint,
- Event handlers are registered for most visible page elements
- And the page responds to user interactions within 50 milliseconds.
TBT (Total Blocking Time)
The sum of the time that the main thread was blocked by long task(more than 50ms) between FCP and TTI
TBT measures the total time a page is prevented from responding to user input, such as a mouse click, screen click, or keyboard press. The sum is calculated by summing up the blocking portion of all long tasks, the first content rendering and interaction time. Any task that takes more than 50 milliseconds to execute is a long task. The amount of time after 50 milliseconds is the blocking part. For example, if Lighthouse detects a task 70 milliseconds long, the block will be 20 milliseconds.
CLS (Cumulative Layout Shift)
Cumulative layout offset
FID (First Input Delay)
Measure the first input delay for the worst case scenario that your users might encounter. The first input delay measures the time from the first time a user interacts with your site, such as clicking a button, until the browser is actually able to respond to that interaction.
A medical results
Hahahaha, a good front end engineer… Five of the six performance indicators fail.
Operation scheme
Optimization Suggestions
Reduce initial server response time
Here’s my friendly conversation with the back end:
I: You this home interface 2.39s, you are closed eyes to write interface?The back-end bosses: xxxBeep beep beep beep XXXXWant to die? ! ****** XXXXX beep beep beep beep beep beep beepI: I also think it’s the front end, um, excuse me…
Ok, next optimization point.
Reduce unused JavaScript
After analysis, I found that the home page only involved resource requests, and did not require the loading of the request libraries (which we encapsulated internally), and the libraries relied on by third parties did not require lengthy version updates, so did not need to be bundled separately into chunk-Vendors. Looking at the volume analysis reports generated based on Webpack-Bundle-Analyzer, I found two large artifacts that can be optimized:
The internally encapsulated request library required MD5 and SHA256 encrypted requests, resulting in an extra 600KB package, so I decided to rewrite the package with AXIos after discussing with the leader.
Vue, VUex, VUE-Router, Clipboard, VUE-I18N, AXIos and other three parties of library upload CDN, home page preloading.
After optimization, the bundle size (pre-GIZP) was reduced from 841KB to 278KB.
Avoid providing older versions of JavaScript to modern browsers
Visual stability
Optimizes unsized image elements
One of the high priority optimizations mentioned in the recommendations is to set explicit widths and heights for image elements to reduce layout offset and improve CLS.
<img src="hello.png" width="640" height="320" alt="Hello World" />
Copy the codeAvoid page layout deviation
The header in our product is configurable, and this header will cause the overall layout of the site to move down. This results in a large layout offset. After trading with product ‘QS’, the page is elongated and the header is fixed at the top of the text stream.
Draw the largest content element
Replace the maximum content draw element
In the improvement suggestions, I found that the largest content drawing element of the home page is a piece of text, which is no wonder that the data performance of THE LCP indicator is not ideal, the reason is: the link is too long – the home page load JS -> load language package -> display text in use.
I decided to change the maximum content drawing element to improve THE LCP time. I take a look at the Largest Contentful Paint API’s definition of this element type, which locks the “target” to a loading element. After I tweaked the size of the element, the element was successfully “in place “.
other
In addition to the optimization of the above index dimensions, I also made several optimization, which are briefly mentioned here:
- Optimize the DOM nesting level and number
- Reduce unnecessary interface requests
- Replace top with Translate for displacement/animation
The optimization results
Ah, excellent, or a good front end engineer ~~~~~hahahhahaha