Thinking of front-end optimization, talking about front-end engineering "Turn"

Thinking of repetitive optimization

This period of time on the project to do an overall optimization, the total station has about 20% of the promotion (originally loaded speed has been about 1.2S, optimization is very low), calculate a has done four rounds of the whole station performance optimization, review several times the optimization means, basically a few words can say clearly:

Transmission plane: Reduce the number of requests, reduce the volume of requests
Implementation level: Reduce Redraw & Reflow

The transmission plane is always the core point of optimization, and this level of optimization to the browser has a basic understanding, such as:

① Web page top-down parsing rendering, edge parsing edge rendering, the page CSS file will block rendering, asynchronous CSS file will cause reflux

② Browser at the end of document download will detect static resources, new thread download (with concurrency limit), under the condition of bandwidth constraints, disorderly concurrency will cause the main resource speed down, affecting the first screen rendering

③ cache resources are used when the browser cache is available, which can avoid the transfer of the request body and greatly improve the performance.

Important metrics to measure performance the first screen load speed (refers to the page can be seen, not necessarily interactive), the biggest factor affecting the top screen is the request, so the request is the real killer of the page, in general we will do these optimizations:

reduce the number of requests

① merging styles, script files

② Merging background images

③CSS3 icons, Icon Font

Reduce Request Volume

① Open gzip

② optimize static resources, Jquery->zepto, castration iscroll, remove redundant code

③ Picture Lossless compression

④ Picture Lazy Loading

⑤ Reduce Cookie Portability

In many cases, we will also adopt similar "time-space, space-time-change" practices, such as:

① Cache is king, cache newer slow resources & interfaces (browser cache, Localsorage, application cache pit)

② load on demand, load main resources first, delay load of remaining resources, scroll load for non-first screen resources

③fake page technology, the page will initially need to display html&css inline, at least before the end of the page to load the resources to see, ideally index.html download end is displayed (2G 5S)

④cdn

......

From the engineering point of view, more than half of the above optimization points are duplicated, generally at the time of release directly using the project building tools, and some are simply server configuration, development without concern.

As you can see, the optimizations we make are either reducing the number of requests, reducing the amount of requests, reducing the time spent on the transmission, or by a policy, loading the first screen with the required resources, and then loading the resources needed for the interaction (such as loading the UI component when clicked), Hybrid The app should put as much public static resources in native as possible, such as third-party libraries, frameworks, UIs, and even city lists, which are common business data.

Stumbling block

Some sites are faster early, but as the amount of accumulation, bugs more and more, the speed is more and more slow, some front end will use the above optimization means to optimize, but the results are very little, a more typical example is the code redundancy:

① before the CSS all put in a file, a new round of UI style optimization, new and old CSS difficult to split, CSS volume will increase, if the business team used the public style, the situation is more optimistic;

The ②ui component is updated, but if there is a business team leaving the interface to manipulate the component DOM, the new component Dom update will be limited, and the worst case, the user will load two components of code;

③ random use of third-party libraries, components, causing the page to load a lot of useless code;

......

The above problems will increase the amount of the resources under different levels, if not, it will produce a series of engineering problems:

① page relationship is complicated, the demand iteration is easy to make a bug;

② Framework each upgrade will result in additional requests, often loading some of the business does not need code;

③ third-party library flooding, and difficult to maintain, there are bugs can not be changed;

④ business code loads a large number of asynchronous module resources, the number of page requests increased;

......

In order to quickly occupy the market, business development time is often urgent, using frame-level html&css, bypassing the CSS sprite using background images, introducing a third-party tool library or UI, will often occur. When encountering performance bottlenecks, if you do not solve the problem from the root cause, using the traditional optimization method to do page-level optimization, there will be a very quick page and be playing bad situation, a few optimizations after the end I was thinking about a problem:

The front-end performance optimization of the means are similar; Code maintainability is basically in the subdivision of responsibility, since each optimization is the same purpose, each time the implementation of the process is similar, and every time the redevelopment project is basically to repeat the same, then engineering, automation may be the final answer to all of these problems

Engineering problems may occur after the project has accumulated to a certain amount, in general there will be a number of phenomena indicating that engineering problems arise:

① Code Writing & Debugging Difficulties

② business code is not maintenance

③ website performance is generally bad

④ performance problems are repeated, and there is a potential for irreparable

As described above, is a typical engineering problem, positioning problems, identifying problems, solving problems is our means of dealing with problems, and how to prevent the same type of problem recurrence, is the engineering need to do things, simply speaking, optimization is to solve the problem, engineering is to avoid problems, Today we stand in an engineering perspective to solve some of the front-end optimization problems, to prevent its resurgence.

The article is my personal development experience, I hope to be useful to you, but also hope that you support the discussion , point out the lack of the text and put forward some of your suggestions .

Eliminate redundancy

The first thing we do here is to eliminate the first obstacle to optimization: Code redundancy (for code simplification), and from the loading of a single page, he needs the following resources:

① Framework MVC Skeleton Module & frame level CSS

②ui components (header components, calendars, pop-up layers, message boxes ...) ）

③ Business HTML skeleton

④ Business CSS

⑤ Business JavaScript code

⑥ Service Interface Service

Because product & Vision often toss the entire station style coupled with the flexibility of the UI, the UI is most likely to produce redundant modules.

UI components

The UI component itself consists of a complete html&css&javascript, a complex component that can download up to 10K, and easily lead to two engineering problems in the UI section:

① upgrade generates Code redundancy

② external interface changes lead to additional development of business upgrades

UI Upgrade

The best upgrade is to keep the external interface unchanged or even keep the DOM structure unchanged, but in most cases the UI upgrade is actually UI redo, the worst case is not to do the old interface compatibility, this time the business colleagues need to modify the code. To prevent business complaints, UI creators tend to keep two components (UI+UI1), and if the original UI is a core dependent component (such as a uiheader component), it will be packaged directly into the core framework package, where the new and old components coexist, a situation that must be avoided, UI upgrades are subject to two principles:

① core dependent components must remain single, core components of the same function can have only one

② component upgrade must be interface compatible, new features can do addition, never allow the interface to be subtracted

UI composition

At the beginning of the project, a well-layered team would have a common CSS file (main.css), a business CSS file, a main.css containing a common CSS, and would contain all the UI styles:

Six months after the business channel increases, the UI component needs a lot of easy to expand, the drawbacks immediately exposed, Initially main.css may only be 10K, but it will swell to 100K in half a year, and each business channel needs to load the 100K style file page at the beginning, but most of the UI styles are not available for first-screen loading.

So the good thing is, MAIN.CSS only contains the most core of the style, ideally what business style features are not provided, the styles of each UI component are packaged into the UI on-demand loading:

With this UI split, Main.css is always in the most basic styling section, and the UI is loaded on demand, even if two identical components do not cause multiple download resources.

Split page

A PC business page, the module is very complex, this time can be divided into several modules:

Once split, the page is made up of business components that focus on the development of individual business components and then assemble the business components in the host controller, which increases the control of the page by the host controller.

Business components generally less reusability, will produce inter-module business coupling, but also the business data dependent, but the main is still html&css&javascript, this part of the code is often caused by redundancy, if the module can be split, can be very good control of this problem occurs:

As described above, the current load rule is:

① Public Style Files

② framework file, business Portal file

③ import file, asynchronously load the business module, and then asynchronously load other resources within the module

This way down the business development will not need to reference the style file, you can maximize the first screen loading speed; One thing to be concerned about is that when an asynchronous pull module, the internal CSS load requires a rule to avoid the impact on other modules, because the module has style attributes, page reflow, page flicker issues need to be concerned about.

A practical example of this is that clicking on the list of cities after the departure is a complete business component, where the resource chosen by the city is clicked before the request occurs, and the business components are subdivided into small modules, and the subdivision of the resource control is determined by the actual business situation, and too much subdivision can lead to an increase in understanding and code writing:

Demo demo address, code address

If the demand side needs to use the new city to select components, it can be directly re-developed, so that the business between the use of the latest city list, because it is a separate resource, so the old is also available.

As long as you can do the UI-level split and page business components of the split, it will be good to cope with the needs of style upgrade, this aspect of redundancy as long as it can be avoided, the other redundancy problem is not a problem, there are two specifications are best to abide by:

1 Avoid using the global business class style, even if he recommends that you use 2 to avoid directly manipulating the DOM through the interface

Redundancy is the first screen loading speed of the biggest stumbling block, is the history of the burden, as long as the redundancy can be eliminated, you can go in the back of the road more smoothly, this component programming method can also make the site follow-up maintenance more simple.

Resource loading

To solve the redundancy of the history of the burden, is the front-end optimization of the first step is also a difficult step, but the module split will also be divided into a lot of small modules, the load of scattered resources will increase the number of requests, if all merge, will cause the first screen to load unnecessary resources, will also cause the next page cannot use the cache. How to make reasonable import resource loading rules, how to use the cache reasonably, is the second step of front-end optimization.

After several performance optimization comparisons, a better first-screen resource loading scheme is obtained:

① Core Framework layer: MVC skeleton, asynchronous Module loader (REQUIRE&SEAJS), tool library (Zepto, underscore, lazy load), data request module, core dependent UI (header Component message Class component)

② Business Public Module: Entry file (require configuration, initialization work, business common module)

③ independent page.js resources (including template, CSS) that load standalone UI resources on demand

④ Global CSS Resources

If the pursuit of the ultimate, Libs.js, Main.css and main.js can choose to merge, after the end of the partition can determine the static resource caching strategy.

Resource Cache

The resource cache is for two request acceleration, and the more commonly used caching techniques are:

① Browser Cache

②localstorage Cache

③application Cache

Application cache update a piece of bad grasp prone to problems, so more is dependent on the browser and Localstorage, first of all, the browser-level cache.

Timestamp update

As long as the server configuration, the browser itself has a caching mechanism, if you want to use the browser mechanism for caching, it is bound to care about when to update the resource problem, we generally do this:

Original address: http://www.cnblogs.com/yexiaochai/p/4901341.html

Thinking of front-end optimization, talking about front-end engineering "Turn"