First, background:The popularization of intelligent terminals has changed people's use of the Internet, the terminal environment has higher requirements for the performance of the page, followed by a graph to analyze: 1s rendering a mobile page
Network overall consumption to analyze: 1, the server response should be less than 200ms 2, as little as possible redirect 3, as little as possible the first rendering of the request 4, avoid too many blocked JS and CSS blocking
JS execution efficiency and rendering efficiency: 1, the browser left 200ms rendering time 2, optimize our JS execution efficiency and rendering time
Second, the main Web performance optimization
Page requests: DNS Lookup, reduced redirection, parallel requests, compression, caching, on-demand loading, front-end modularityOperating Environment: interactive, animated, scrolling, memory and GC, FPS
Three, the reflection of the problem of rendering1) The performance difference between the intelligent terminal and the PC is huge x86 performance is more than 5 times times more than arm, many of the original performance problems are covered up, after the end of the market, the problem follows, in some cases:-the user holds the terminal CPU difference is huge-slow running speed-user Lag-out of memory-insufficient local storage-limited resources available-...
2) compared to iOS and Android hardware, why do you think iphone is better than Android phone in the early days? Fluency: Smooth animations and sliding energy saving: Save power Stability: rarely crash
| Operating system |
Model |
Cpu |
Ram |
| Iphone |
4s |
Dual Core A5 800MHZ |
512M |
| Iphone |
4 |
A4 800MHZ |
512M |
| Iphone |
3GS |
s5pc100 600MHZ |
256M |
| Android |
Glaxy Note |
Exynos Dual Core 1.4GHZ |
1G |
| Android |
Nexus One |
Qualcomm 1GHZ |
512M |
| Android |
MOTO XT615 |
Qualcomm 800MHZ |
512M |
| Android |
HTC Legend |
Qualcomm 600MHZ |
384M |
Iv. Performance Optimization metrics
All performance optimizations are based on measurable data analysis and cannot be optimized for things that cannot be measured.
1) standard number of frames for judging rendering performance:-Displays the device's usual refresh rate, typically 50~60HZ-1000MS/60 = 16.6ms (1 ms optimization means 6% performance improvement)
2) Browser rendering Engine: In FF, the process of layout is called reflow,painting process called repaint
3) Drop frame behavior of browser rendering
4) Performance debugging tool: The Chrome Debugger's timeline,timeline has two common patterns.
Events mode,
Frames (chrome-specific) mode,
Tip: A) the shortcut key for timeline recording behavior is CTRL + E (Mac:cmd + e) b) gray area rendering behavior for non-rendering engines c) transparent wireframe, which is the wait time in two display refresh cycles
5) Avoid common recurring renderings: Ensure that the "update render tree" behavior occurs at most 2 times per frame
6) Avoid duplication of layout calculations: Requestanimationframe (hereafter referred to as RAF)
A) Tip: Timeout and RAF are actually working on the same thread, and when the CPU is very busy the RAF execution is also blocked.
b) The difference between the event behavior and the RAF control is as follows: triggering a wasted render frame directly through the event behavior, without being displayed by the hardware frame final rendering frequency is controlled by the RAF, incorporating a large number of event calculations, reducing the number of invalid renders
7) Bad DOM operation caused by page redraw
Tip: Chromium in the source code, the Updatelayoutignorependingstylesheets () method is used to ignore the alternate style to recalculate the layout
Good DOM operation
Tip: Caching requires DOM attributes to be used for better read and write separation
7) Avoid repeated rendering behavior a) use the RAF to control the animation during a reasonable refresh time B) ensure the rendering engine atomic operation, bulk DOM read/write separation C) different styles in the rendering mode of different performance, such as
V. To achieve smooth animation
1) Dom animation of the four major artifact displacement: Transform:translate (npx, npx); Zoom: Transform:scale (n); Rotation: Transform:rotate (ndeg); transparent: opacity:0 ~ 1;
Six, interactive animation optimization
1) GPU Acceleration (Composite): How does the GPU work in the browser? In high-end browsers (WebKit, Chrome), the painting behavior is that the CPU prepares texture footage for the GPU.
Tip: In the Chrome debugger, you can turn on show composited layer borders view picture texture footage
2) Available GPU benefits: Texture cache and graphics layer GPU hack:a),-webkit-transform:translate3d (0px, 0px, 0px); Create layout and move the layer in the GPU. b), force the DOM object that needs to animate, create the layout cache-webkit-transform:translatez (0) in the GPU; Create layout, and cache. -webkit-backfface-visibility:hidden; Common attributes are as follows: Translatez, Perspective, backface-visibility, ScaleZ, RotateZ, RotateX , Rotatey, Translate3d, Scale3d, Rotate3d
3) using GPU acceleration for reasonable use, GPU acceleration, is actually leveraging the GPU layer cache to make the rendering resources reusable. b), GPU acceleration is a double-edged sword, too many GPU layers will also bring performance overhead, please note that composite layouts is more than 16ms. c) To create the GPU layer only in scenarios where user behavior and animation are needed, but need to be recycled in a timely manner.
4) Some considerations for CSS3 animations a) using translate2d alone does not produce a GPU layer independently, and does not synthesize in the GPU. b) CSS tweened animation with translate2d, you can generate a temporary layer in the GPU for operation, but the change in "layout calculation" is not valid. c) CSS3 animations are usually not blocked. You can get a separate thread to draw
Tip: 1, if you need to completely avoid the rendering tree calculation, you can consider CANVAS2, use classlist instead of className, but in chrome33 Dev common "classname=" can already be judged by the same name, to reduce the style of repeated rendering
Research on the performance of mobile-page
