How to develop and deploy front-end code in large companies_html/css_WEB-ITnose

This is a very interesting non-mainstream front-end field. What this field wants to explore is how to use engineering methods to solve the comprehensive problem of front-end development and deployment optimization. Question, I have been learning and practicing since I entered the industry.

In my impression, Facebook is the originator of this field. Students who are interested and have a ladder can look at the Facebook page source code and experience what engineering is.

Next, I would like to start the explanation from the principle, with many pictures, and it is quite long. I hope you can have the patience to read it.


------------------------------- I am a dividing line-------- --------------------

Let us go back to basics and start with the original front-end development. The picture above is a "cute" index.html page and its style file a.css. Use a text editor to write code without compilation. Preview locally, confirm OK, throw it to the server, and wait for user access. The front-end is so simple, it’s so fun, the threshold is so low, you can learn it in minutes!



Then we visit the page, see the effect, and check the network request again, 200! Not bad, so perfect! Then, the research and development is completed. . . . Already?

Wait, this isn’t over yet! For large companies, those abnormal traffic volume and performance indicators will make the front end not "fun" at all.

Look at the a.css request. If it has to be loaded every time a user visits the page, will it affect performance and waste bandwidth? We hope it is best like this:


Use 304 to let the browser use local cache. But is this enough? No! 304 is called negotiation cache. This thing still needs to communicate with the server once. Our optimization level is abnormal level, so we must completely eliminate this request, which becomes like this:


Force the browser to use local cache ( cache-control/expires), do not communicate with the server. Okay, the request optimization has reached an abnormal level, so here comes the question: If you don’t let the browser send resource requests, how do you update the cache?

Very good, I believe someone has thought of a way: By updating the resource path referenced in the page, let the browser actively give up the cache and load new resources. It looks like this:


Next time you go online, change the link address to a new version and the resources will be updated, right? OK, is the problem solved? ! Of course not! The pervert of a big company is here again. Think about this situation: The


page references 3 css, and only a.css was changed during a certain online launch. If all links are updated, it will It will cause the cache of b.css and c.css to also become invalid. Wouldn’t that be another waste? !

Re-enable the abnormal mode. It is not difficult to find that to solve this problem, the modification of the URL must be associated with the file content. In other words, only changes in the file content will lead to changes in the corresponding URL, thus Implement precise cache control at the file level.

What is related to the content of the file? We will naturally think of using the "data summary algorithm" to obtain summary information for files. The summary information corresponds to the file content one-to-one, and there is a cache control basis that can be accurate to the granularity of a single file. Okay, let’s change the URL to one with summary information:


This time if there is a file modification, only the URL corresponding to that file will be updated. It seems perfect when I think of it. Do you think this is enough? Big companies tell you: the pattern is broken!

Oh~~~~, let me take a breath

Modern Internet companies, in order to further improve website performance, will deploy static resources and dynamic web pages in clusters, and static resources will be deployed to CDN On the node, the resources referenced in the web page will also become the corresponding deployment path:


Okay, when I want to update the static resources, the references in the html will also be updated at the same time, just like Like this:


In this release, the page structure and style have been changed at the same time, and the URL address corresponding to the static resource has also been updated. Now the code is going to be released online. Dear front-end R&D students, please tell me, Should we launch the page first, or the static resources first?

1. Deploy the page first, then deploy the resources: During the time interval between the two deployments, if a user accesses the page, the old resources will be loaded in the new page structure, and the This old version of the resource is cached as the new version. The result is that the user accesses a page with a disordered style. Unless refreshed manually, the page will continue to execute errors until the resource cache expires.
2. Deploy resources first, then deploy pages: Within the deployment interval, users with local cache of old version resources visit the website. Since the requested page is an old version, the resource reference is not Change, the browser will directly use the local cache, in which case the page will display normally; but when users without local cache or cache expired visit the website, the old version page will load the new version resource, resulting in page execution errors, but when After the page is deployed, these users will return to normal when they visit the page again.

Okay, what I want to say from the above analysis is: No one can deploy first! This will lead to page confusion during the deployment process. Therefore, for projects that do not have a large number of visits, R&D students can work hard and wait until midnight to secretly go online. First upload static resources and then deploy the page, which seems to have fewer problems.

However, large companies are extremely abnormal. There is no such "absolute low peak period", only "relative low peak period". So, in order to provide stable service, we must continue to pursue perfection!

This strange problem originates from the overlay publishing of resources. This problem occurs when resources to be published are used to overwrite published resources. An easy solution is to implement Non-coverage release.


Look at the picture above, use the summary information of the file to rename the resource file, and put the summary information in the resource file release path. In this way, the resource with modified content becomes a new The files are published online and existing resource files will not be overwritten. During the online process, the static resources are deployed in full first, and then the pages are deployed in grayscale. The whole problem is solved perfectly.

So, the static resource optimization plan of large companies basically needs to implement the following things:

1. Configure a long-term local cache?? Save Bandwidth, improve performance
2. Adopt content summary as cache update basis?? Accurate cache control
3. Static resource CDN deployment?? Optimize network requests
4. Update resource release path to achieve non-standard cache update. Coverage release?? Smooth upgrade

Once completed, it will be a relatively complete static resource cache control solution. Moreover, it should also be noted that the cache control requirements for static resources are in All static resource loading locations on the front end must be processed in this way. Yes, all! Not to mention js and css, it also includes the resource paths referenced in js and css files. Since summary information is involved, the summary information of the referenced resources will also cause the content of the referenced file itself to change, thus forming a cascade of summary changes. The rough schematic diagram is:


Okay, now we have quickly studied the optimization and deployment issues faced by static resource caching in front-end engineering. A new question has come again: What? How should engineers do this? Write code! ! !

To explain the idea of ​​combining optimization and engineering, it will bring up a bunch of engineering issues related to modular development, resource loading, request merging, front-end framework, etc. The above is just a beginning, and the solution is It is the essence, but there is too much to say, so I will expand it slowly when I have time. Or you can go to my blog to see some of the dismantling: fouber/blog · GitHub

In short, front-end performance optimization is definitely an engineering problem!

The above is not mine. You can observe Baidu or Facebook pages and static resource source codes to view their resource reference path processing, as well as the cache control part of static resources in network requests. I once again admire Facebook's front-end engineering construction level and lick it.

It is recommended that front-end engineers pay more attention to the field of front-end engineering. Some people may think that their products are small and there is no need to be so perverted, but it is very likely that one day you may need to make such a change. And if we can take something to the extreme, why not do it?

Also, don’t think that these are problems to be solved by operation and maintenance or back-end engineers. If it is solved by other roles, everyone always throws problems they don’t care about to others , then the development process of front-end engineers will be greatly restricted. This situation is not even possible in some large companies. Rare!