background
Performance is the backbone of websites and applications. Higher website performance means better user experience. At the same time, website speed is also a factor in search engine rankings. Therefore, good website performance directly affects our revenue indicators, so it is necessary to improve the performance of the website to obtain business benefits from a technical perspective.
Indicators for performance optimization
The RAIL model is a set of user-centric performance models given by Google, which provides a structure for considering performance. The model breaks down user experience into key actions (for example, click, scroll, load) and helps you define performance goals for each action. RAIL stands for:
- Response: Response
- Animation: animation
- Idle: idle
- Load: Load as shown in the figure below:
response
Transitions initiated by user input are completed within 100 milliseconds, making the interaction feel instant to the user.
- To ensure a visible response within 100ms, user input events need to be processed within 50ms. This works for most inputs, such as clicking a button, toggling a form control, or starting an animation. However, this doesn't work with touch dragging or scrolling.
- Paradoxical as it may sound, responding to user input immediately isn't always the right thing to do. You can use this 100-millisecond time window to perform other resource-intensive work, but be careful not to get in the way of the user. Should work in the background if possible.
- Feel free to provide feedback on operations that take more than 50ms to complete.
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
50 milliseconds or 100 milliseconds?
The goal is to respond to input within 100ms, so why is our budget only 50ms? This is because there is often other work that needs to be performed besides input processing, and that work consumes some of the time available for acceptable input responses. If an application performs work in the recommended 50-millisecond chunks during its idle time, this means that if input occurs in one of these work chunks, it may be queued for up to 50 milliseconds. With this in mind, it's safe to assume that only the remaining 50 milliseconds are available for actual input processing. This effect is illustrated in the following diagram, which shows how input received during an idle task is queued, reducing the available processing time:
animation
Generate a frame in 10 milliseconds
- Generate each frame of an animation in 10 milliseconds or less. Technically, the maximum budget per frame is 16 ms (1000 ms/60 frames per second ≈ 16 ms), however, the browser takes about 6 ms to render a frame, so the guideline is 10 ms per frame.
- The goal is smooth visuals. Users will notice a change in frame rate.
idle
Maximize idle time to increase the chances that the page will respond to user input within 50 milliseconds.
load
- Optimize the relevant fast loading performance according to the user's device and network capabilities. Currently, it is desirable to be interactive in 5 seconds or less for first load on mid-range mobile devices using slower 3G connections .
- For subsequent loads, the ideal goal is to load the page within 2 seconds.
Get metrics dynamically through APIs
How to obtain some real-time index data of web pages through API is very important for us to optimize. In general, we obtain regular performance indicator data through the performance object.
Below we present only our most commonly used values
- navigationStart: The start time when the browser processes the current web page
- fetchStart: The millisecond timestamp when the browser initiates HTTP to read the document
- domainLookupStart: The timestamp when domain lookup starts
- domainLookupEnd: The timestamp of the end of domain lookup
- connectStart: The timestamp when the HTTP request starts to be sent to the server
- connectEnd: The connection between the browser and the server is established
- requestStart: The timestamp when the browser sends the HTTP request to the server
- responseStart: The timestamp when the browser received the first byte from the server
- responseEnd: The timestamp when the browser received the last byte from the server
- domLoading: The time when the browser starts parsing the DOM structure of the web page
- domInteractive: The time when the DOM tree of the web page is created and the embedded resources start to be loaded
- domContentLoadEventStart: The time when the webpage domContentLoad event occurs is wrong
- domContentLoadedEventEnd: The time when all scripts that need to be executed on the web page are completed, and the time of domReady
- loadEventStart: The time stamp when the current web page load event callback function starts to execute
- loadEventEnd: The timestamp of the end of the execution of the current web page load event callback function
| performance data name | describe | calculation method |
|---|---|---|
| Time-consuming DNS query | Time-consuming DNS resolution | domainLookupEnd - domainLookupStart |
| Time-consuming request response | Time-consuming network requests | responseStart - requestStart |
| DOM parsing time-consuming | DOM parsing time-consuming | domInteractive - responseEnd |
| Time-consuming resource loading | Time-consuming resource loading | loadEventStart - domContentLoadedEventEend |
| DOM_READY time-consuming | DOM stage rendering time-consuming | domContentLoadedEventEend - fetchStart |
| First render time | First render time/white screen time | responseEnd - fetchStart |
| First interactive time-consuming | First interactive time-consuming | domInteractive - fetchStart |
| Time-consuming for the first package | First package time | responseStart - domainLookupStart |
| It takes time for the page to fully load | page full load time | loadEventStart - fetchStart |
| TCP connection time | Time-consuming TCP connection | connectEnd - connectStart |
Custom indicator collection We can collect the data we want by customizing some indicators
const observer = new PerformanceObserver((list) => {
for(const entry of list.getEntries) {
console.log(entry)
}
})
observer.observe({ entryTypes: ['longtask'] })Tools for performance optimization
There are some tools that can help you automate RAIL measurements. Which one to use depends on what type of information you need, and what type of workflow you prefer.
The following are supporting learning materials. For friends who do [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse also accompanied me through the most difficult journey. I hope it can help you too!
Software testing interview applet
The software test question bank maxed out by millions of people! ! ! Who is who knows! ! ! The most comprehensive quiz mini program on the whole network, you can use your mobile phone to do the quizzes, on the subway or on the bus, roll it up!
The following interview question sections are covered:
1. Basic theory of software testing, 2. web, app, interface function testing, 3. network, 4. database, 5. linux
6. web, app, interface automation, 7. performance testing, 8. programming basics, 9. hr interview questions, 10. open test questions, 11. security testing, 12. computer basics
Information acquisition method:
