Recently, I made browser printing requirements and summarized two related blog articles: “Browser Printing Knowledge Literacy” and “Browser Printing Scheme Research”. Finally, I determined the implementation of browser printing scheme and encapsulated my own easy-print NPM package, which solved the following problems:

  1. Browser printing cannot customize paging behavior;
  2. Browser printing can not be customized print content;
  3. The printing style of the browser is incorrect, and the printing results of different printers are inconsistent.

But after the practical application of this scheme to our system, in the face of a large number of printing, continuous printing of 200 pages will make the system directly crashed, the page did not render, the browser did not respond…

The problem background

Our system has the demand of batch printing, so it often needs batch printing, so there is a scene of printing 200 or 300 pieces at a time. If the computer system is better, the browser may not be stuck without response, but the user’s computer configuration is uneven, there will be performance problems.

So it’s important to find out what’s causing your browser to crash by loading multiple loads, thanks to the Performance panel in chrome developer Tools.

The Performance panel in Chrome developer Tools allows you to record the browser’s rendering process over time. The results of the rendering analysis can help you understand what’s going on behind the scenes.

Here I also use the Performance panel to locate the cause.

A screenshot of the rendering result printed at a time of 200 pages is as follows:

Purple: style calculation, layout calculation, rendering time;

Yellow: time of foot parsing this calculation, DOM operation;

It can be seen that the loading time of 200 sheets is 1min, among which the time consumption of yellow and purple is the largest.

Problem analysis

Analysis of the above results, in fact, the reason is clear:

  1. Easy print generates the content of the printed document, the underlying dependency is jquery manipulation dom, continuous append… We know that jquery is designed to simplify DOM manipulation, which means that it’s easy to write and codeing time is reduced, but the actual processing of the browser is slow, similar to the performance cost of native DOM manipulation. Therefore, loading multiple pages at a time will inevitably lead to multiple dom operations, which will consume too much.
  2. Small white – the print use easy solved the problem of inconsistent results on different printers print, because the print style writing can use absolute positioning, each element has a wide high position, size, style rules, is the rules of the style is very fine, each a piece of document content, each element need to compute the layout and rearrangement of rendering, So style calculation, layout calculation, rendering time cost is not less;

But how to solve this performance problem? Tell the truth xiao Bai was a little meng!!

There are too many styles, which are very expensive to calculate, but because of these styles, we can get the consistency of browser printing on different printers. Dom manipulation with Jquery is a big drag on browser performance, this is because the hiprint library is based on Jquery.

There were a lot of solutions:

  • Considering that the printed component is the hooks function component, which uses the closure idea and has unexpected memory overhead, replace the hooks function component with a class component. The result is that the optimization is not obvious;
  • Considering that it was too expensive to load too many document contents at once, I changed it to lazy loading, but this did not really solve the performance problem;
  • When too many pages are printed at a time, batch printing is used. However, it is necessary to calculate the number of pages to be printed first, and then divide the pages into several batches according to the limit of the number of pages to be printed at a time, which is not a real solution to the performance problem.
  • In view of the high performance overhead of jquery dom manipulation, it runs counter to the concept of vue/ React virtual DOM in the project, so the optimization idea is to replace jquery DOM with react DOM.

Problem solving

Use react DOM instead of jquery DOM to add a new API to easy print:

hiprint.getReactDom(panel, printData);

Where: Panel is your printed document content panel, printData is batch printed document data.

The test results for 300 identical documents are as follows:

React DOM: The react DOM is faster than the react DOM: the React DOM is faster than the react DOM ！！！！

The React DOM API is not available in the latest version of The Easy Print API. This API has not been connected to all the HIprint API, and the part of the table has not been implemented, which will be continuously updated in the future

Ps: In the process of small white test, I also found that if your document content is only text and pictures, the loading speed will be faster, if there is bar code, two-dimensional code, it will increase a lot of rendering overhead. Especially two-dimensional code, different generation methods, consumption is not the same, SVG takes longer than canvas, but SVG is clearer than canvas to print, involved friends can choose according to their own needs.

Welcome friends can like ha ！！！！