First, resource loading

1. First screen loading:

(1) On-demand loading: Although on-demand loading can improve the loading speed of the first screen, it may bring more interface redrawing and affect the rendering performance. Therefore, it is necessary to evaluate the specific business scene before making a decision;

(2) LazyLoad: in fact, it is lazy loading, which is not a new technology and is also a very common performance optimization method in the PC era. The principle of this scheme is to load the resources off-screen or without affecting the overall rendering effect, such as pictures and backgrounds, after the interface is ready.

(3) Scrolling loading: Scrolling loading is a common scheme for dynamically loading data without refreshing, which is usually used in tabular data display; On the one hand, data is not loaded by turning pages, so as to avoid one request and rendering the whole page. On the other hand, the number of data display is limited. For example, only 10 data are requested for the first time, so only the 10 data are rendered.

(4) Media Query (Responsive loading) : Responsive design is a popular trend in web design; Through this technology, we can easily control the loading and display of resources, for example, in the mobile phone with different resolutions, using different CSS, loading different sizes of picture resources;

(5) the third party asynchronous loading: sometimes uncontrolled third-party resources, such as page statistics, map display, share components, etc., these third-party resources to use when you need to choose carefully, give full consideration to their effects on performance, using asynchronous loading manner, to prevent the third party resource load affect the function of the page itself.

(6) Loading progress bar: When the loading time is long, the user must clearly perceive the hint of loading completion. Usually, the loading progress bar is displayed during the loading process and hidden when the loading is complete. Psychologically, this will make users have a sense of anticipation, not too boring. For some heavyweight H5 applications, such as games, where a lot of resources need to be loaded before you start to make the game flow more smoothly, a progress bar with a percentage of progress is even more important.

(7) avoid 30*/40*/50* HTTP status code: 200 normal, 304 hit cache, 301,302 jump is commonly used, especially the former one, in our authentication sometimes used, but this practice should be optimized as far as possible, a page access, up to a 302 jump, avoid frequent jump. 404 and 500 May occur when a third party library is loaded, especially when the third party library has its own load component. For example, in the case of The third party micro application, dojo component loading problems have been encountered. It’s easy to ignore that some of the loaded child components fail without affecting the page display.

(8) Faviicon ICO: If we do not set icon ICO, the default icon will be loaded: Favicon. ico in the domain directory, which many developers don’t notice, will result in a request 404 or 500. Usually, when we open a web page in the app, we don’t show this icon (unless we display the page in the browser), we need to make sure that the icon exists as small as possible (usually less than 4KB). And set a long cache expiration time.

2. The use of pictures

(1) format selection: good display effect format, webp, JPG, png24/32 these several, generally webp picture is the smallest, but in ios or android4.0 system may have compatibility problems; JPG is our most commonly used scheme and modest, decoding speed, compatibility issues and basic does not exist, is to use in our application in h5, most valuable png24/32 in general, the display effect is better, but actually it is difficult to perceive to the naked eye, so to avoid the big picture of this format in the h5, for a small amount of pictures, It is recommended to use smart map or Tinypng and other tools to help you choose the appropriate size and format;

(2) Pixel control: in THE H5 application, the pixel of the picture should be strictly controlled. Generally speaking, it is not recommended that the width exceed 640 pixels;

(3) small image merge: in HTML pages, if there are many small images need to load, might as well try CSS Sprites scheme, especially some basic unchanged, the size of the operation type icon;

(4) Avoid HTML resize: in HTML or CSS, if there is a similar width:**px; If the image is square, the display effect is 100px wide, and the downloaded image is 200px wide, the actual image is 4 times the set area, so in H5, the principle of using the image is to display as big as you need to download the resources;

(5) Avoid Dataurl: Dataurl is a Base64 method to transform the image into a string of text encoding into the code, which has one advantage, it can reduce an HTTP interaction request, for some very small size of the image, or dynamically generated images can be considered to use, but in H5 applications, generally, We avoid dataurls because they are usually one-third larger than binary image formats, and they are not cached by browsers and require reloading with every page refresh.

(6) Use image replacement (CSS3, SVG,iconfont): CSS3 and SVG can better use GPU to accelerate rendering, and will avoid the HTTP request this time, such as div rounded corner effect, can be fully realized by CSS, Iconfont, can be considered as a vector type of operation font, If the page has a lot of action ICONS, consider iconfont instead of image.

3. Domain name/server deployment

(1) Gzip: Enable Gzip compression on the server.

(2) Resource cache, long cache: reasonably set the expiration time of resources, especially for some static resources that do not need to be changed, set the cache expiration time to be longer;

(3) by domain name deployment resources (static resource domain name) : dynamic resources and static resources deployed in different domain names, such as pictures, in their own specific domain name, this advantage is that static resource request, not with cookie header information set in the dynamic domain name, so as to reduce the size of HTTP requests;

(4) Reduce cookie: try to reduce the size of cookie header information, because this part of data uses uplink traffic, uplink bandwidth is smaller, so the transmission speed is slower, so try to simplify its size;

(5) CDN acceleration: deploy CDN server or use third-party CDN acceleration service to optimize the bandwidth speed of access network stations in different regions;

4. Code resources:

(1) JS and CSS merge: try to merge all JS and CSS to reduce the number of resource requests.

(2) External use of JS, CSS: this can effectively use the cache, avoid the HTML page after the reload of this part of the code;

(3) Compress HTML, JS, CSS: compress code, especially JS and CSS resources, the compressed code can be reduced to 1/3 of the original size, effectively save traffic;

(4) Update of resource version: Library js, CSS usually don’t update, however, our business of js, CSS may be updated, if hit the browser cache, may bring some new features is not show in time, even logically conflict, so for the js, CSS resource introduction, had better use the version number or update the suffix, time to do so, the suffix is changeless, Hit the cache, the suffix changes, the browser automatically updates the code;

(5) CSS location: the CSS should be placed before the end of the HEAD tag of the HTML code. If the page is dynamically generated, it can be forced to output after the head is complete (such as the PHP flush() operation). In this way, the browser will parse the contents of the HEAD faster and start downloading the CSS file.

(6) JS position: js is placed before, so that js loading will not affect the initial page rendering.

5. Code specification:

(1) Avoid empty SRC: setting an image to an empty SRC address will add an invalid HTTP request in some browsers, so avoid this;

(2) Avoid CSS expressions: it may make the page perform calculations many times, resulting in performance problems such as lag,

(3) Avoid empty CSS rule sets: reduce the cost of CSS rendering;

(4) Avoid directly set element style: directly set the style attribute, on the one hand in THE HTML code is not conducive to caching, on the other hand is not conducive to the use of style, so to avoid, by specifying id or class way, in the CSS code block style adjustment;

5. Server interface:

(1) Interface merge: If the page needs to request more than two parts of the data interface, it is recommended to merge them, otherwise an HTTP request will be added.

(2) Reduce the amount of interface data: remove the irrelevant status information from the interface return value;

(3) cache: cache interface data, which is very useful in some scenarios where the sensitivity of old and new data is not high. When loading data for the first time, cache data from the last request is preferred, which can make the page render more quickly;

6. Other Suggestions:

(1) Use CSS properly:

Use display properties. display can affect page rendering, so use it wisely

1. Display: Inline should not be used after width, height,margin,padding, or float;

2. Display: Inline-block should not be used after float;

3. Display: do not use vertical-align after block.

4. Display: Do not use margin or float after table;

5. Don’t abuse float;

6. Don’t declare too much font size;

7. When the value is 0, no unit is needed.

8. Standardize various browser prefixes;

9. No prefixes should come last;

10. CSS animation only (-webkit-, no prefix) two can be used;

11. Other prefixes are -webkit-,-moz-,-ms-.

12. Avoid making selectors look like regular expressions. Advanced selectors are harder to read and take longer to execute.

13. Select as many ID selectors as possible;

14. Use CSS3 animation as much as possible;

(2) Resource loading:

1. Use srcset;

2. The first load should not exceed 1M(the smaller the better)

(3) HTML and JS:

1. Reduce redrawing and reflow;

2. Cache DOM selection and calculation;

3. Cache list.

4. Use event agents to avoid binding events in batches.

5. Use touchstart,touchend instead of click;

6. HTML using the viewport;

7. Reduce DOM nodes; 8. Use requestAnimationFrame instead of setTimeOut properly.

9. Use canvas animation properly;

10. The TouchMove, Scroll event will cause multiple renders;

One step faster:

Many of the previous suggestions are consistent with normal PC web development, but in mobile Internet applications, just doing this, may only be 60 points, so how to achieve 80 points or higher:

One. Single page application: Nail approval micro applications, using a single page architecture. In this architecture, there is basically no waiting time for page jump, only need to execute JS logic to trigger the interface change, at most one network request to obtain server data, other resources do not need to request again;

Second, resource offline: no matter how fast the network interaction is, after all, it also spans several network nodes. Therefore, a picture, a JS, optimized to the extreme, may still need hundreds of milliseconds. If you want to break it, you need to use resource offline strategy. The “offline package” strategy is used in the pinning micro application. Fixed images, JS libraries, etc., are packaged into the app (or, as needed, downloaded and updated when the app starts). In microapplications, the need to load network resources in the web code becomes the need to load local files directly, which increases the speed;

Three, local data continued and update mechanism (versioning) : in the first time into the interface, the page doesn’t need to wait for network data to return to the interface of can be rendered, rendering the initial data from the local cache, pages can be seconds, and when the data returned from the server, the local rendering will update again, the cache is updated also;

4. Preloading: The user behavior statistics are used to predict the next possible operation of the user. Disadvantages: customers without predictive operations will lose unnecessary traffic;

At this point, h5 optimization is basically completed;