What developers need to know about HTML5 performance analysis

Comment: The following article was written by an IT technician named Zhang Liming, and it was published on the InfoQ webpage. This time, he analyzed the performance of HTML5 from 9 different aspects in the full text, which is still worth reading by corresponding developers.

First, from the perspective of user readability, there were a lot of things that were originally not understood by beginners for the first time to see these things, and the HTML5 declaration method is obviously more friendly to users.

Second, the document encoding declaration is very simple if it is in HTML5. Many people ask what HTML5 is? We say that the way we can use HTML5 first is to change DOCTYPE first, because many pages are still in the traditional way. The HTML5 method is compatible with IE browser, and can be used from IE6 to IE10, and it can be supported by advanced browsers. So the easiest way to embrace HTML5 is to change DOCTYPE.

The next thing may not be a very common thing, but it is something I prefer, using a simpler label method. As you can tell from this name, HTML5 is inherited from HTML4. HTML4 has strict mode and transition mode. HTML5 supports this transition mode, which means you can not close some tags. However, I do not recommend all tags, for example, the BODY tag is not closed, which we do not recommend. But the most commonly used P-label is also the list tag LI. Why do you say this? First of all, from a visual perspective, this method is a bit simpler. Then the key is that during the document transfer process, there will be less content.

The declaration of HTML5 tag attributes supports three ways: single brackets, double brackets and unbranched brackets. To reduce the size of the document, I chose the method without double quotes or single quotes. However, it should be noted that assuming it is a declaration of class attributes, because attributes may include multiple classes, and when multiple classes, they must be enclosed in brackets. In this regard, let me show you a practice of Google. Google itself has a page that completely practices the above, reducing the size of the document by 20%, reducing the transfer of HTML documents by 20%. If the whole thing is practiced, it can achieve a decrease of between 5% and 20%. This is the first step, reducing the size of the HTML document.

Next is about the optimization of pictures, which are always elements that love and hate. Because when there are too many pictures, it will seriously drag down the loading speed of the entire page. Regarding the optimization methods of pictures, there are many introductions in the book "High Performance Website". To summarize, there are three main points: using elves, optimizing the size of pictures, and using DATA URI. I won't go into details here.

Another idea of ​​image optimization is: no-image. Abandon the pictures and embrace CSS3. Originally, I needed to set a picture with a rounded corner effect, but now I used border-radius in CSS3; I used the picture with a shadow effect, but now I use box-shadow in CSS3; I used to set a gradient background image, but now I use gradient in CSS3.

3. Pre-fetch

Next, let’s talk about Prefetching, which is another way of optimization. Our current optimization ideas are nothing more than few. Many of them are from the perspective of fewer things, for example, the document size was reduced before and the image size was reduced. Many pictures become elves, in order to reduce the number of sending requests. For prefetching, it is another way of thinking. Loading resources early. When the user goes to the point, it has actually loaded, so it will definitely be faster.

There are two parts for prefetching: one is prefetching of resources, and the other is pre-resolving of DNS.

There are several points to note when resource preloading:

Preloading will only pull when the browser is idle, but it is not guaranteed to pull it. This is a very important point. Because the browser itself has a global listener, which is an internal interface. When the browsing air is idle, it will execute the browser when it is idle, but this idle callback may not be triggered, so it does not guarantee that preloading will be performed.

Chrome does not support preloading of HTTPS resources. For example, Alipay is an HTTPS page, Chrome will not pre-pull.

Although a pre-pulled page is not visible after it exists, it is actually parsing normally. If I pre-pull the login page, the login page has many resources, such as pictures, CSS files, and JS files. It will be parsed from top to bottom normally. During the parsing process, this page does not appear, but it actually exists. In HTML5, you can get the current page status through document.visibilityState. Usually the page has two states, visible and invisible, but now there is a new state called pre-rendering state. You can directly determine whether the page is in the prerender state by whether document.visibilityState is equal to prerender.

4.DNS resolution

Next is the resolution of DNS. Sometimes when we log in to the page, it is relatively difficult to detect where the user may click. Of course, sometimes we will do some burying points to find out that the user's next behavior is mostly going in. 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-parse 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 let users see this page.

The following is a case of Q+ wallpaper. Q+ wallpaper is a certain system. First of all, the entire architecture of Q+ is based on WEB+ client. What we are seeing now is a WEB page. Although it is a client shell outside, its heart is WEB. When we completed the whole process for the first time, because there are many pictures, all the static resources are allocated to more than a dozen static servers. In other words, if I want to pull, I have to parse 10 DNS. This time is quite time-consuming, and the slowest time may be delayed by a few seconds, which is something we can feel with the naked eye. If you perform DNS pre-resolution, because I don’t know which resource it is, all pictures are random, so we can only say that we work hard on DNS pre-resolution to improve its speed. In this way, it may take 2 seconds, and I will become 1 second.

Next, let’s talk about the application in Q+. We will have many text chains in QQ and Q+, just like in QQ, which means there is a text APP information push in the lower left corner of the window. This is the backend is pulled from time to time through WEB, and the backend is pulled from and then displayed in the foreground. But at a certain period, the total operational information pushed by all APPs is actually fixed. If you analyze the corresponding array of each text chain according to a specific APP, it is very big data at this time. Because one here has about three or four hundred bytes, from the perspective of optimization, we will pull these areas over locally. Then save the local localStorage. We are in the same domain, and all the information between APPs can be accessed by each other. Then you will not pull all the IDs you pulled again.

There is also a point that needs to be paid attention to here. Currently, many manufacturers of localStorage are synchronized. If you call localStorage in large quantities, it will actually block your rendering process. At this time, when the user drags the page down, you are storing data at this time, and the data is relatively large. At this time, the user will feel that your page is very stuck. They have discussed this issue before. The design of this interface is designed asynchronously, and they are designed as synchronous. This will cause you to make this excuse when you make more apps because there is a serialization process, sequence to disk. In this way, the whole process will appear slower. In addition, localStorage can share this data between different windows, and it will lock on this data. If a large amount of data is calling this local interface, it will appear to be relatively stuck. So there is no particularly good solution at the moment, but this is something to remember. Even if the largest one at the moment is over 5 o'clock, if you use over 5 o'clock, it will make the user very sad. Because if you call this excuse and the user is dragging and using the mouse, it will feel very stuck.

Next, let’s talk about the benefits of offline storage to users in terms of performance. First of all, the definition file is entered offline storage. All system modules in Q+ have definition offline support. That is to say, if all applications are disconnected, they can still be used. Add a MANIFEST file to the document. MANIFEST is a definition file that declares which pages need to be stored locally? Which ones do not need to be stored? Which ones should be replaced if the request fails? This is divided into three parts:

First, CACHE, which need to be stored locally.

Second, NETWORK will not be stored locally. It will go back and request it every time. But it should be pointed out here that local storage and browser storage are actually two different things. They store two different parts. Even if NETWORK needs to tell the APP that I need to pull it once every time, because like Chrome, its storage cache is very hateful and difficult to clear. It must be manually cleared to take effect. So even if you set it not to store it locally, the browser may store it itself because it stores two different places.

Third, FALLBACK. If a picture fails, it is 404. So what pictures should be used instead? I think this is more fun.

How to set MAEIFEST? There are three things to note about MANIFEST:

MANIFEST homologous restriction;

The MIME type must be text/cache-manifest, which is standard and will not take effect if it is in other formats;

CHROME, if you want to see if this thing takes effect, you may enter it in the browser through the pseudo-protocol CHROME, chrome://appcache-internals.

About how to update the app's cache. Why do you need offline storage? Store offline locally. When the browser knows that you have offline storage, it will first go to the offline storage directory to find out whether this 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 we update?

Users can manually clear the browser's cache, and the local storage will be automatically cleared at this time.

Modifying any content of MANIFEST is a more recommended way and it is also the way we use it online. That is to say, we can modify the specific projects inside, but it is best to modify the comments here, because every time I publish, we automatically publish the mechanism, and just comment and modify it when publishing. In this way, every time the content is published, it will be synchronized to the client's local area in real time;

Execute through the program, and the program is window.applicationCache.update(). It means I want to operate offline storage. In fact, I sometimes call it application storage because its semantics is application storage. We go to manually update the application storage.

6.Web Worker

Next Web Worker. Web Worker is a multi-threaded JS process. In fact, if we don’t have application scenarios online, I won’t talk about them. But we can talk about the specific application scenarios I have seen.

First, let me introduce what WEBWORK is? It is an OS-level thread. Before, we imitated multi-threading, but in fact we opened one more window. But now, the browser itself provides it, which will bring more convenience to the operation and is a way to make our entire document heavier and not very recommended.

Then WebWorker has limited access capabilities and 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 were playing games before, we used BOX2D. Many people have heard of it. It involves a lot of calculations, that is, all the objects below in the entire page need to calculate their collision relationship, which is very large. However, if it is executed in the current JS process, the calculation is large, and once the calculation is calculated, the entire page will be very stuttering. However, if you use WebWorker to do it, it is an asynchronous process that is sent in real time and can do other things during the calculation process, which is multi-threading.

Let’s talk about the device API. I think the most important thing about device API is performance, and it is also the earliest API currently implemented. One is CONNECTION, which is network bandwidth. What is the function of this? In this scenario in China, it is necessary to remember that many users' internet speeds are still very low. We hope that when users’ internet speed is low, they can automatically downgrade to a relatively low solution. We can't do it if we use existing technology. But we can use the device API. Because we know that this information can be obtained from the device. What is its broadband? What is the broadband? What we can do when it is. For example, when broadband is good, I use high-definition pictures. When the broadband is relatively low, use pictures with lower clarity.

8. Battery

The following one is about the battery. I think from a performance perspective, it is mainly about power. If the user's battery power is relatively low, I think he should try to do fewer things. The battery technology of the mobile phone itself has not yet made breakthroughs. I think making the APP look more high-performance is also a highlight of publicity.

9.CANVAS

Next is CANVAS. Let’s talk about several performance optimization points of CANVAS. If you use these things, the performance will be improved by 10 times.

First, each CANVAS is a canvas. When we want to render a graph, we can layer it. Just like inside PS, it is one, two, and three layers. Many users directly imitate everything in one layer when making games, and update everything as soon as they update. But if you layer it, you put the background in the background layer and the character in the role. In this way, when I want to update the role, I will only update the role, and the background layer does not need to be changed. As the CPU does less, the performance will naturally improve.

Second, context.drawImage. Don’t scale the picture. We made a mistake at the beginning. The pictures made by our artists are always inconsistent with us, and then we want to scale the picture. Because the image size of the device itself is like this, we must scale the image by ratio. After zooming in on the picture, I found that on low-end devices, for example, iPad or iPhone will be very stuck. Why? Just conduct code analysis. When using this method, it will cost a lot.

Third, requestAnimationFrame. This is a method specifically optimized for rendering. Its own principle is this: when the browser passes a frame, this method will be triggered. When I trigger it, Canvas gets the browser is ready to do the next frame. If you use the traditional method, you won’t consider more of your things. It will only know how much time I have passed and I will execute it. If the user is blocked before and executes this method every 10 seconds, within 10 seconds, the previous work has not been completed, and then the work will be postponed. It is optimized for the animation to look smoother, because every frame, it tells you that you can do something. (Text: infoq)