Mobile page performance exploration_html/css_WEB-ITnose

1. Background:

The popularity of smart terminals has changed people’s usage habits of the Internet, and the terminal environment has a higher impact on page performance Requirements, let’s analyze it with a picture: Render a mobile page within 1 second

Analysis of overall network consumption:

1. Server response should be less than 200ms

2. Minimize redirects

3. Minimize the first rendering request

4. Avoid excessive blocking of js and css

js execution efficiency and rendering efficiency:

1. Give The 200ms rendering time left by the browser

2. Optimize our js execution efficiency and rendering time

2. Main web performance optimization

Page request: DNS Lookup, reduced redirects, parallel requests, compression, caching, on-demand loading, front-end modularization

Running environment: Interaction, animation, scrolling, memory and GC, FPS

3. Thoughts on rendering issues

1) Smart terminal and PC The performance difference is huge

The performance of x86 is more than 5 times or even more than that of ARM. Many of the original performance problems were covered up. After the terminal market broke out, problems followed, as shown in the following situations:

- There is a huge difference in the quality of the terminal CPU held by the user

- Slow running speed

- User operation lags

- Insufficient memory

- Insufficient local storage

- Limited controllable resources

-...

2) Comparison of IOS and Android hardware

Why did people think iPhones were easier to use than Android phones in the early days?

Fluency: smooth animations and sliding

Energy saving: power saving

Stability: few crashes

操作系统	型号	CPU	RAM
iphone	4s	双核A5 800MHZ	512M
iphone	4	A4 800MHZ	512M
iphone	3GS	S5PC100 600MHZ	256M
Android	Glaxy Note	Exynos 双核 1.4GHZ	1G
Android	Nexus One	高通 1GHZ	512M
Android	MOTO XT615	高通 800MHZ	512M
Android	HTC Legend	高通 600MHZ	384M

4. Performance optimization metrics

All performance optimization is based on measurable data analysis Above, you cannot optimize things that cannot be measured

1) Criteria for judging rendering performance

Number of frames:

- Display The usual refresh rate of the device is generally 50~60HZ

- 1000ms/60 = 16.6ms (1 millisecond optimization means 6% performance improvement)

2) Browser rendering engine: In FF, the Layout process is called reflow, and the Painting process is called repaint

3) Frame dropping phenomenon in browser rendering

4) Performance debugging tool: Timeline of chrome debugger, Timeline has two commonly used modes.

Events mode, as shown in the picture:

Frames (chrome-specific) mode, as shown in the figure

Tips:

a) The shortcut key for Timeline recording behavior is ctrl E (Mac: Cmd E)

b) The gray area is rendering that occurs in non-rendering engines Behavior

c) Transparent wireframe, wait time between two monitor refresh cycles

5) Avoid common re-rendering: ensure every The "update rendering tree" behavior only occurs at most 2 times in a frame

6) Avoid repeated layout calculations: requestAnimationFrame (hereinafter referred to as RAF)

a) Tip: Timeout and raf actually work on the same thread. When the CPU is very busy, RAF executes the same Be clogged.

b) The difference between event behavior and RAF control is as follows:

The wasted rendering frames are directly triggered by the event behavior and will not be finally displayed by the hardware frame.

Control the rendering frequency through RAF, merge the calculation of a large number of events, and reduce the number of invalid renderings

7) Causes page redraw

Poor DOM manipulation

Tip: In the chromium source code, the updateLayoutIgnorePendingStylesheets() method is used to ignore the alternate styles and recalculate the layout

Good DOM operation

Tip: Caching the Dom attributes you need to use can be better Separate reading and writing

7) Avoid repeated rendering behavior

a) Use RAF to control animation within a reasonable refresh time

b) Ensure the atomic operation of the rendering engine, and separate reading and writing of batch DOM

c) Different performances of different styles in rendering modes, as shown below

5. Achieve smooth animation

1) Four artifacts of DOM animation

Displacement: transform: translate (npx, npx);

Transform: scale(n);

Rotation: transform: rotate(ndeg);

Transparency: opacity: 0 ~ 1;

6. 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 materials for the GPU.

Tip: show composited can be turned on in the chrome debugger Layer borders View picture texture material

2) Available GPU advantages: texture cache and graphics layer

GPU Hack:

a), -webkit-transform: translate3D(0px, 0px, 0px); // Create Layout and perform it in GPU The layer moves.

b) Force the DOM object that needs to be animated to create a Layout cache in the GPU

-webkit-transform: translateZ(0); // Create a Layout and cache it.

-webkit-backfface-visibility: hidden;

Common attributes are as follows: translateZ, Perspective, backface-visibility, scaleZ, RotateZ, RotateX, RotateY, Translate3D, Scale3D, Rotate3D

3) Proper use of GPU acceleration

a) Using GPU acceleration actually uses the cache of the GPU layer so that rendering resources can be reused.

b). GPU acceleration is a double-edged sword. Too many GPU layers will also bring performance overhead. Please pay attention to whether Composite Layouts exceeds 16ms.

c) Only create GPU layers in scenes where user behavior and animation are required, but they need to be recycled in time.

4) Some notes on css3 animation

a) Using translate2D alone will not generate a GPU layer independently and will not be synthesized in the GPU.

b) CSS tweening animation combined with translate2D can generate a temporary layer in the GPU for calculation, but it will be invalid when encountering changes in "layout calculation".

c) CSS3 animations are usually not blocking. You can get independent threads for drawing

Tips:

1. If you need to completely avoid rendering the tree For calculation, you can consider Canvas

2. Use classList instead of className. However, in chrome33 dev, the ordinary "className=" can already be judged by the same name to reduce repeated rendering of styles