What developers need to know about HTML5 performance analysis_html5 tutorial skills

From a performance perspective, HTML5 first reduces the HTML document to make it easier.
First, in terms of user readability, there were originally a lot of things that beginners could not understand when they saw them for the first time, but the HTML5 declaration method is obviously more user-friendly.
Second, the declaration of document encoding is very simple using HTML5. Many people ask what HTML5 is? We say that the way to use HTML5 first is to change the DOCTYPE first, because currently many pages still use the traditional method. The HTML5 method itself is compatible with IE browsers, from IE6 to IE10, including advanced browsers. So the easiest way to embrace HTML5 is to change the DOCTYPE.

1. More concise tags
The next thing may not be a very common thing, but it is something I recommend, and it is simpler to use. labeling method. As you can tell from the name, HTML5 is inherited from HTML4. HTML4 has strict mode and transition mode. HTML5 supports this transition mode, that is, you can not close some tags. However, I do not recommend all tags. For example, if the BODY tag is not closed, we do not recommend this. But the most commonly used P tag is the list tag LI. Why do you say this? First of all, from a visual perspective, this method is simpler. Then the key is that during the document transfer process, the content will be less.
HTML5 tag attribute declaration supports three methods: single brackets, double brackets and no brackets. In order to reduce the document size, I choose the method without double quotes or the method with single quotes. However, please note that assuming is a declaration of a class attribute, because the attribute may include multiple classes, and must be enclosed in parentheses when there are multiple classes. In this regard, let me show you a practice of Google. Google itself has a page that completely implements the above, reducing the size of the document by 20% and reducing the transmission of HTML documents by 20%. If you put the whole thing into practice, you can achieve a reduction between 5% and 20%. This is the first step, reducing the size of the HTML document.
　2. Image Optimization
Next is the optimization of images. Images are always a love-hate element. Because when there are many pictures, it will seriously slow down the loading speed of the entire page. Regarding the optimization methods of images, there are many introductions in the book "High Performance Website". In summary, there are three main points: using sprites, optimizing the size of images, and using DATA URI. I will not go into details here.
Another idea for image optimization is: no-image. Ditch images and embrace CSS3. It was originally necessary to set a picture with a rounded corner effect, and now it uses border-radius in CSS3; it was originally necessary to set a picture with a shadow effect, and now it uses box-shadow in CSS3; it used to be a background picture that needed to set a gradient, and now it is used in CSS3. gradient.
　3. Prefetching
Next let’s talk about Prefetching, prefetching, which is another idea for optimization. Our current optimization ideas are nothing more than few. Many of them are from the perspective of reduction, such as reducing the size of documents and reducing the size of pictures. Many pictures are turned into a sprite image in order to reduce the number of requests sent. Prefetching is another way of thinking. Resources are loaded in advance. When the user clicks on them, they are already loaded, which is definitely faster.
Prefetching has two parts: one is resource prefetching, and the other is DNS pre-resolution.
There are several points to note about resource preloading:
Preloading will only be done when the browser is idle, but there is no guarantee that it will be done. This is a very important point. Because the browser itself has a global listener, which is an internal interface. When the browser is idle, it will perform things that the browser should do when it is idle, but this idle callback may not be triggered, so There is no guarantee that preloading will be performed.
Chrome does not support preloading of HTTPS resources. For example, if Alipay is an HTTPS page, Chrome will not preload it.
Although a pre-fetched page is not visible after it exists, it is actually being parsed normally. Suppose I pre-fetch the login page. The login page has many resources, such as pictures, CSS files, and JS files. It will be parsed normally from top to bottom. During the parsing process, this page does not appear, but it actually exists. In HTML5, the current page state can be obtained through document.visibilityState. Usually the page has two states, visible and invisible, but now there is a new state called pre-rendered state. You can directly determine whether the page is in the pre-rendered state by whether document.visibilityState is equal to prerender.
　4.DNS analysis
Next is the analysis of DNS. Sometimes on our login page, it is relatively difficult to detect the places where users may click. Of course, sometimes we will do some digging to find out that most of the user's next actions are to go inward. But in some cases, we don't know which page the user will go to next, but we know which domain he will go to. At this time, I can pre-resolve DNS. Because in fact, there is a long DNS resolution process in the entire page request process. If we do this in advance, we can further allow users to see this page.
The following is an example of Q wallpaper. Q wallpaper is a certain system of Q. First of all, the entire architecture of Q is based on the WEB client. What we see now is a WEB page. Although it is a client shell on the outside, its heart is WEB. When we completed the whole process for the first time, because there were many pictures, all static resources were allocated to more than a dozen static servers. In other words, if I want to pull, I have to resolve 10 DNSs. This time is quite time-consuming. At the slowest time, it may be delayed for a few seconds, which we can feel with the naked eye. If we perform DNS pre-resolution, I don’t know which resource it is, and all pictures are random, so we can only say that we should work hard on DNS pre-resolution to improve its speed. In this case, it might take 2 seconds, but it will take 1 second.
Next let’s talk about the application in Q. We will be like in QQ. There are many text links in QQ and Q, that is, there is a text push of APP information 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 over and displayed in the foreground. But at a certain period, the operational information pushed by all apps is fixed. If we analyze the array corresponding to each text link according to a specific APP, this is a very large amount of data. Because each one here is about three to four hundred bytes. From an optimization point of view, we store these files locally every time. Then store it locally in localStorage. We are in the same domain, and all information between APPs can be accessed by each other. Then all the IDs that have been pulled will not be pulled again.
There is also a point that needs attention here. The current implementation of localStorage by many manufacturers is synchronous. If you call the localStorage interface a lot, it will actually block your rendering process. At this time, when the user drags the page down, and you are storing data at this time, and the data is relatively large, the user will feel that your page is very stuck. They have discussed this issue before. The interface design of IE is asynchronous, while their design is synchronous. This will lead to the assumption that you have many programs when adjusting this interface, because there is a serialization process, serializing to disk. In this case, the whole process will appear slower. In addition, localStorage itself can share this data between different windows, and it will lock this data. If a large amount of data is calling this local interface, it will appear to be stuck. So there's no particularly good solution right now, but it's something to keep in mind. Even if the current maximum is more than five megabytes, if you use more than five megabytes, it will make users miserable. Because if you call this excuse and the user drags the mouse, it will feel very stuck.
　5. Offline storage
Next let’s talk about the benefits that offline storage brings to users in terms of performance. The first is the definition file for offline storage. All system modules in Q have offline support defined. This means that 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 parts of the current page need to be stored locally? Which ones do not need to be stored? Which ones should be replaced with new pictures or something if the request fails? This way Divided into three parts:
First, CACHE, which needs to be stored locally.
Second, NETWORK will not be stored locally. It will go back and request it every time. But what needs to be pointed out here is that local storage and browser storage are actually two different things. They store two different pieces. place. Even if NETWORK needs to tell the APP that I need to pull it every time, because like Chrome, its storage cache is very hateful and difficult to clear. It must be cleared manually to be fully effective. So even if you set it not to store it locally, the browser may store it itself because it stores it in two different places.
Third, FALLBACK. If a picture says that the request failed, it is 404. What picture should I use instead? I think this is more fun.
How to set MAEIFEST? There are three points to note here in MANIFEST:
MANIFEST same-origin restriction;
The MIME type must be text/cache-manifest. This is standard. If it is in other formats, it will not work. Effective;
CHROME, if you want to see whether this thing is effective, you may enter it in the browser through the pseudo-protocol CHROME, chrome://appcache-internals.
About how to update the application cache. Why offline storage? Offline storage is local. When the browser knows that you have offline storage, it will first go to the offline storage directory to find out whether the resource has been cached. When it has been cached, he will get the resource directly from here and will not send another request. Because the browser's request is like this, when there is offline storage, even the request will not be sent, so it will be faster. If sometimes we need to update, what should we do when updating?
Users can manually clear the browser’s Cache, and the local storage will be automatically cleared at this time.
Modify any content of MANIFEST. This is the recommended method, and it is also the method we use online. That is to say, we can modify the specific items inside, but it is best to modify the comments here, because every time I publish, we have an automatic publishing mechanism. When publishing, just modify the comments above. In this case, every time the content is published, it will be synchronized to the local client in real time;
It is executed through the program, and the program is window.applicationCache.update(). That is, I want to operate offline storage. In fact, I sometimes call it application storage because its semantics is application storage. Let's update the application store manually.
　6.Web Worker
　 Next is the Web Worker. Web Worker is a multi-threaded JS process. In fact, we don’t have application scenarios online, so I won’t go into them. But I can talk about the specific application scenarios I have seen.
First, let’s introduce what WEBWORK is? It is an OS-level thread. Before we imitated multi-threading, we actually opened one more window. But now, the browser itself provides it. This will bring more convenience to the operation and make our entire document heavier, which is not a very recommended method.
Then WebWorker’s access capabilities are limited, and it cannot access many global objects. For example, the documnet object cannot be accessed. The most suitable scenario for WebWorker is CPU-intensive computing operations. When we made games before, we used BOX2D. Many people must have heard that it involves a lot of calculations, that is, in the entire page, all the objects below have to calculate their collision relationships. This calculation amount is very large. But if it is executed in the current JS process, the calculation amount is huge. Once calculated, the entire page will be very stuck. But if you use WebWorker to do it, it is an asynchronous process, sent in real time, and you can do other things during the calculation process. This is multi-threading.
　7. Device API
Let’s talk about the device API. I think the device API is the most important in terms of performance, and it is also the earliest API currently implemented. One is CONNECTION, which is network bandwidth. What does this do? In this scenario in China, we must remember that the Internet speed of many users is still very low. We hope to allow users to automatically downgrade to a lower plan when their network speed is low. We can't do it with existing technology. But we can use the device API. Because we know that this information can be obtained from the device. What is its bandwidth, and what can we do with that bandwidth? For example, when broadband is good, I will use high-definition pictures. When the bandwidth is relatively low, pictures with lower definition are used.
　8. Battery
　The next one is about the battery. I think from a performance perspective, it’s mainly about power. If the user's battery power is relatively low, I think they should do as little as possible. There has never been a breakthrough in mobile phone battery technology. I think making the APP look more high-performance is also a promotional highlight.
　9.CANVAS
　Next is CANVAS. Let’s talk about several performance optimization points of CANVAS. Using these things, the performance will be improved by 10 times.
First, each CANVAS is a canvas. When we want to render a graphic, we can layer it. Just like in PS, there are one layer, two layers and three layers. When many users are making games, they directly put everything into one layer, and everything will be updated when it is updated. But if you layer it, you put the background on the background layer and the characters on the character layer. In this case, when I want to update the character, only the character will be updated, and the background layer does not need to be changed. Let the CPU do less work, and the performance will naturally improve.
Second, context.drawImage. Don't scale the image. We made a mistake at the beginning. The image our artist made was always inconsistent with ours. Then we have to scale the image. Because the image size of the device itself is like this, we must scale the image proportionally. After zooming the picture, we found that it would be very stuck on low-end devices, such as iPad or iPhone. We thought why? We conducted code analysis. When using this method, it costs a lot of time.
Third, requestAnimationFrame. This is a method specifically optimized for rendering. Its principle is this. Every time the browser passes a frame, this method will be triggered. When I trigger it, Canvas gets that the browser is ready to do the next frame. If you use the traditional method, it will not consider more of your things. It will only know how much time has passed and I will execute it. If the user was blocked before and this method is executed every 10 seconds, within 10 seconds, his previous work has not actually been completed, and then this work will be delayed. It is optimized to make the animation look smoother, because at each frame, it tells you that you can do something. (Text: infoq)