Comments: The following article is written by Zhang Liming, an IT technician and published on InfoQ's webpage. This time, he analyzed the HTML5 performance from nine different aspects in the full text, which is worth reading by developers. From a performance perspective, HTML5 first reduces HTML documents to make it easier.
First, in terms of user readability, there were a lot of things that could not be understood by beginners for the first time, and the HTML5 declaration method was obviously more friendly to users.
Second, the declaration of document encoding, in HTML5 mode, is very simple. Many people ask what HTML5 is? We can use HTML5 to change DOCTYPE first, because many of the previous pages still use the traditional method. HTML5 is compatible with IE browsers, from IE6 to IE10, including advanced browsers. So the simplest way to embrace HTML5 is to change DOCTYPE.
1. More concise labels
Next, it may not be a very common thing, but I highly recommend it and use a more concise TAG method. HTML5 is inherited from html4. There are strict mode and transition mode in HTML4. HTML5 supports this transition mode, that is, you can leave some labels closed. However, we do not recommend all tags, for example, the BODY tag is not closed. However, for P tags, the list label LI is also the most commonly used. Why? First, from a visual perspective, this method is more concise. The key is that there will be less content during the document transmission process.
HTML5 tag attributes can be declared in three ways: single brackets, double brackets, and no parentheses. To reduce the document size, I chose not to add double quotation marks or single quotation marks. However, it should be noted that, for the declaration of class attributes, because attributes may include multiple classes, they must be enclosed in parentheses when there are multiple classes. In this regard, let's take a look at one of Google's practices. Google has a page that fully practices the above east and west, reducing the document size by 20%, and reducing the HTML document transmission by 20%. If we practice the entire process, we can reduce it by 5%-20%. This is the first step to reduce the size of HTML documents.
2. Image Optimization
Next we will discuss image optimization. Images will always be an element of love and hate. When there are many images, the loading speed of the entire page will be severely slowed down. There are many introductions in the "high-performance website" book on image optimization methods. There are three main points to summarize: using a Sprite, optimizing the image size, and using a data uri, I will not elaborate on it here.
Another idea of image optimization is: no-image. Abandon images and embrace css3. You need to set an image with a rounded corner effect, and use border-radius in CSS3. You need to set a shadow image in CSS3, and use box-shadow in CSS3; you need to set a gradient background image, and now use gradient in CSS3.
3. prefetch
Next we will talk about Prefetching and prefetch, which are another idea of optimization. Our current optimization approach is nothing more than less. Many of them are from a few perspectives. For example, we can reduce the document size and the image size. Many images are converted into a sprite to reduce the number of requests sent. Prefetch is another way of thinking. Resources are loaded in advance. When users go to the node, they actually load resources, which must be faster.
Prefetch includes two parts: Resource prefetch and DNS pre-resolution.
Note the following before resource pre-loading:
Pre-loading will only be pulled when the browser is idle, but it is not guaranteed to be pulled. This is very important. Because the browser itself has a global listener, which is an internal interface, when the browser is idle, it will execute what should be done when the browser is idle, however, this idle callback is not necessarily triggered, so it is not guaranteed that the pre-load will be executed.
Chrome does not support HTTPS resource pre-loading. For example, if Alipay is an HTTPS page, Chrome will not perform pre-pulling.
Although a pre-pulled page is invisible after it exists, it is actually parsed normally. For example, if I pre-pull the login page, there are a lot of resources on the login page, such as images, CSS files, and JS files. It is normally parsed from top to bottom. During the parsing process, this page does not appear, but it actually exists. In HTML5, the current page status can be obtained through document. visibilityState. Generally, the page has two states: visible and invisible, but now there is a new State called the pre-rendering state. You can determine whether the page is in the pre-rendering status by checking whether the document. visibilityState is equal to the prerender.
4. DNS resolution
Next is about DNS resolution. Sometimes we log on to the page, which is relatively difficult to detect where users may click. Of course, sometimes we will make some tracking to find that the next step of user behavior is mostly going in. However, in some cases, we do not know which page the user will go to next, but we know which domain the user will go. At this time, I can pre-resolve DNS. In fact, there is a long DNS resolution process in the request process of the entire page. If we say this is done in advance, we can further let the user see this page.
The following are examples of Q + wallpaper. Q + wallpaper is a system of Q +. First, the entire architecture of Q + is based on WEB + client. What we see now is a WEB page. Although it is a client shell outside, its heart is WEB. The whole process was completed for the first time. Due to the large number of images, all the static resources were allocated to a dozen static servers. That is to say, when I want to pull, I will resolve 10 DNS records. This time is quite time-consuming, and the slowest time may be several seconds delayed, which we can see with the naked eye. If DNS pre-resolution is performed, because I don't know which resource is specific, and all images are random, we can only talk about how hard it is to speed up DNS pre-resolution. In this case, it may take 2 seconds for me to change to 1 second.
Next we will talk about the application in Q +. Like QQ, there are many text links in QQ and Q +, that is, there is a text APP information push in the lower left corner of the window. Here, the backend is pulled from time to time through the WEB, and the backend is pulled and displayed on the front-end. However, in a certain period of time, the operation information pushed by all apps is fixed. If you use a specific APP to analyze the corresponding array of each text chain, this is very big data. This is because there are about 300 or 400 bytes here. From the optimization point of view, we will save these latencies locally. Save the local localStorage. We are in the same domain, and the information of all apps can access each other. Then, all the pulled IDs will not be pulled again.
There is also a point to note here. Currently, many vendors implement localStorage synchronously. If you call the localStorage interface in large quantities, it will actually block your rendering process. At this time, when the user is dragging down the page, and then you are doing data storage at this time, the data is relatively large, the user will feel that your page is very card. Previously, they all discussed this issue. The design of this interface IE is designed to be asynchronous, and they are designed to be synchronous. This will cause you to call this excuse, assuming that you have many programs, because there is a serialization process that is serialized to the disk. In this way, the entire process will be slow. In addition, localStorage can share the data between different windows. It locks the data. If a large amount of data is calling this local interface, it will appear relatively slow. So there are no good solutions, but this should be remembered. Even if you use more than five megabytes at the maximum of five, it will make the user sad. If you call this excuse, the user will feel very stuck when dragging the mouse.
5. offline storage
Next we will talk about the benefits of offline storage in terms of performance. The first is definition files stored offline. All system modules in Q + support definition offline. That is to say, all applications can still be used if the network is disconnected. Add a MANIFEST file to the document. MANIFEST is a definition file that declares which of the current pages need to be stored locally? Which do not need to be stored? Which of the following images should be used to replace the request if the request fails? There are three parts as follows:
First, CACHE, which need to be stored locally.
Second, the NETWORK won't be stored locally. It will go back and request again each time, but it should be noted that local storage and browser storage are actually two different situations, they store two different parts. Even if the NETWORK side needs to tell the APP that I need to pull it once every time, because like Chrome, the storage cache is very hateful and hard to clear. It must be cleared manually, to take effect. So even if you do not want it to be stored locally, the browser may store it because it stores two different parts.
Third, FALLBACK. If the request fails for an image, it is 404. So what image should I use instead? I think this is quite fun.
How to Set MAEIFEST? MANIFEST:
Same-source MANIFEST restrictions;
The MIME type must be text/cache-manifest, which is standard and will not take effect if it is in another format;
CHROME. If you want to check whether this item has taken effect, you may enter it in the browser using the pseudo protocol CHROME: // appcache-internals.
Update the application cache. Why offline storage? Offline storage is locally stored. When the browser knows that you have offline storage, it first goes to the offline storage directory to check whether the resource has been cached. When it has been cached, he will get the resource directly from this side and will not send a request again. Because browser requests are like this, when there is offline storage, even requests will not be sent, so it will be faster. What should we do if we need updates?
You can manually clear the browser Cache, which automatically clears the local storage.
Modify any content of MANIFEST, which is recommended and used online. That is to say, we can modify the specific project in it, but it is best to modify the annotation here, because every time I publish, We will automatically release the mechanism and modify it in the above annotations during the release. In this way, each published content will be synchronized to the local client in real time;
Run the program window. applicationCache. update (). That is, I want to operate on offline storage. In fact, I sometimes call it application storage because it refers to application storage. We will update the application storage manually.
6. Web Worker
Next, the Web Worker. Web Worker is a multi-threaded JS process. In fact, we don't have any online application scenarios. I won't talk about them anymore. But I can talk about the specific application scenarios I have seen.
What is WEBWORK first? It is an OS-level thread. We used to simulate multithreading. In fact, we opened one more window. But now, the browser itself is provided, which will make operations more convenient. It is not a recommended method to make the entire document heavy.
Then, WebWorker has limited access capabilities and cannot access many global objects. For example, the ingress net object cannot be accessed. The most suitable scenario for WebWorker is CPU-intensive computing operations. We used BOX2D when we were playing games. Many people have heard that it involves a lot of computing, that is, the entire page, all the objects below need to calculate their collision relationships. This calculation is very large. However, if it is executed in the current JS process, this computation workload is huge. Once calculated, the entire page is very stuck. However, if WebWorker is used for processing, it is an asynchronous process. When real-time transmission is passed, other tasks can be done in the computing process. This is multithreading.
7. device API
Let's talk about the device API. In terms of performance, the device API is also the first API to be implemented. One is CONNECTION, that is, network bandwidth. What is the role of this? In this Chinese scenario, we must remember that the network speed of many users is still very low. We hope that users can automatically downgrade to a relatively low solution when their network speed is low. We cannot use the existing technologies. However, we can use the device API. Because we know that this information can be obtained from the device. What is its bandwidth and what we can do when it comes to bandwidth. For example, when bandwidth is good, I use high-definition images. When bandwidth is relatively low, images with lower definition are used.
8. Battery
The following is about the battery. I think from the performance perspective, it is mainly about power. If the battery power of a user is relatively low, I think we should do as little as possible. The battery technology of mobile phones has not been broken through. I think it is also a publicity highlight to make apps look high.
9. CANVAS
Next is CANVAS. Let's talk about several performance optimization points of CANVAS. With these things, the performance will be improved 10 times.
First, each CANVAS is a CANVAS. When we want to render an image, we can layer it. Like PS, It is a layer-2, layer-3. Many users directly put everything in a layer when playing games, and update everything as soon as they are updated. However, if you layer it, you can place the background on the background layer and the role on the role layer. In this case, when I want to update a role, it only updates the role, and the background layer does not need to be changed. This reduces the number of CPU tasks and naturally improves performance.
Second, context. drawImage. Don't scale the image. We made a mistake at the beginning. Our artist made the same image as ours, and then we needed to scale the image. Because the image size of the device is like this, we must scale the image proportionally. After zooming images, we can see that on low-end devices, for example, the iPad or iPhone is very card-shaped. What do we want to do? When this method is used, it takes a lot of time to analyze the code.
Third, requestAnimationFrame. This is a method dedicated to rendering optimization. The principle of this method is as follows. When a browser goes through a single commit, this method is triggered. When I trigger this method, canvas, you can see that the browser is ready to perform the prepare operation. If you use the traditional method, you will not consider more things. It will only know how much time I have passed and I will execute it. If the user is blocked before, and the method is executed every 10 seconds, the user will be delayed after 10 seconds, but the previous task has not been completed. It is optimized to make the animation look smoother, because every seek tells you that you can do something. (Article: infoq)
