Long rendering times when grid items span

[panghal0]

Hi team, I was wondering if there are some best practices/recommendations that one should keep in mind to while generating large PDF documents to optimize the generation time? I have gone through the documentation and couldn't find anything related.

In our app we generate HTML reports which sometimes result in upto 100MB+ of html files. Now few of the users are asking for report in PDF format. Since we already have system in place to generate HTML reports, we thought of using WeasyPrint to convert these HTMLs to PDFs.

I tried converting 1 HTML to PDF using WeasyPrint, but it is taking too long to generate PDF. It took around 40 minutes for converting a 50MB HTML to PDF and this generation time shoots upto 2.25 Hours for a 100MB HTML.
I tried using it via command line, like this

python3 -m weasyprint ./Desktop/Reports/report_name/report.html  ./Desktop/Reports/report_name/report.pdf

So I'll really appreciate if some one can guide me to some sort of checklist/best practice like keeping DOM tree to certain limit or any specific CSS properties to use or not use, or anything in general which can help reducing the PDF generation time.

By the way our HTML and CSS structure is pretty basic (using CSS Grid though). Here is a sample of the html/css code.

Aside form the questions, thanks a lot for the great tool. ❤

[liZe]

Hi!

In our app we generate HTML reports which sometimes result in upto 100MB+ of html files.

Then you could probably benefit from our professional support. 😄

By the way our HTML and CSS structure is pretty basic (using CSS Grid though).

Removing display: grid saves most of the generation time (from ~13s to ~1s for your example), there’s probably a performance issue in our grid code. Let me ask my profiler!

Aside form the questions, thanks a lot for the great tool. ❤

You’re welcome. ❤

[liZe]

The problem comes from:

WeasyPrint/weasyprint/layout/grid.py

Lines 270 to 271 in 603d87c

	if size_contribution in ('minimum', 'min-content'):
	space = min_content_width(context, item)

Calling min_content_width on text is quite long, because we need to render all the words one by one to find the longest. This function is almost never called for normal layouts, but it’s necessary for grid (and flex) layout.

The overall _distribute_extra_space algorithm blindly follows the specification’s pseudo-algorithm, there are probably many optimizations waiting to be found. I’ll try to find is there’s an easy workaround for your case or a quick fix in the code.

[liZe]

That’s actually extremely long because you use word-break: break-all for almost all your text, so each word letter is actually rendered separately to find the min-width of your grid items 😄.

A possible workaround is to use word-break: break-all only when you really need it. When I use it only for the hash and the path, it only takes ~2s. Far from perfect, but already much better.

(I’ve also found a typo, and fixing it makes the grid layout go… even slower 😒. Note that the problem only happens when cells span, ie. when they take multiple rows or columns.)

(And it looks like break-inside: avoid doesn’t work for grid containers, I’ve added an item to #2145.)

So I'll really appreciate if some one can guide me to some sort of checklist/best practice like keeping DOM tree to certain limit or any specific CSS properties to use or not use, or anything in general which can help reducing the PDF generation time.

There’s a short list of best practices in the documentation, we could add grid and flex layouts to tables in the list of possibly long renderings.