Inline XBRL Rendering Performance 1.0

Working Group Note 27 October 2021

This version
Paul Warren, XBRL International Inc. <>
Semyon Chertkov, AMANA Consulting GmbH <>

Table of Contents

1 Overview

Inline XBRL is increasingly used for "highly designed" reports, such as company annual financial reports which have previously been prepared in PDF. Such reports are characterised by heavy use of images, use of specific fonts, and very precise layout of content.

HTML and modern CSS can do an excellent job of replicating the high level of design included in these documents, however, many current examples of such documents are very large, and result in poor performance when opened in a browser, particularly when used in an iXBRL viewer.

This Working Group Note discusses the performance issues and what can be done to mitigate them.

2 Page load time and iXBRL viewers

When rendering a document, browsers will start at the beginning of the document, and work down. This means that in common use, slow loading of an HTML document is often not a serious issue, as the document will be rendered faster than a reader wishes to scroll down to view it.

Inline XBRL documents are often viewed using viewer software, which often takes the form of browser-based JavaScript. In this case, page load time can be more critical, as viewer software typically needs the document to be fully loaded before it can be fully functional, as it needs access to the browser's DOM for the document.

For this purpose, we're primarily concerned about when the browser issues the DOMContentLoaded event. This indicates that the browser has fully loaded and parsed the HTML and constructed the DOM.

The time that this takes varies significantly between documents and browsers. For testing, we used two large iXBRL reports:

As per current filing system requirements, all resources (images, fonts and stylesheets) are embedded within the HTML.

These documents were tested using the following browsers:

All testing was done on the same computer, with the HTML loaded from a local file, and averaged over five loads. Chromium is an Open Source variant of Google Chrome, with the same rendering engine. Ad-hoc testing confirms very similar performance to Chrome.

Report A Report B
Chromium 21.5s (σ = 1.6s) 171.0s (σ = 10.8s)
FireFox 2.7s (σ = 1.0s) 7.7s (σ = 0.5s)

Clearly there is a very large difference between browsers on these two documents. It is also worth noting that the performance does not relate directly to file size, as the smaller document is slower.

2.1 The content-visibility CSS property

The performance of Chrome/Chromium can be very significantly improved using an experimental CSS feature, content-visibility. This feature allows content authors to indicate that rendering and layout of a content element within a document may be safely deferred, because the contents of the section have no impact on content outside the containing element.

The "highly designed" documents that are the subject of this WGN almost always simulate the pagination seen in PDF documents. This makes them very well placed to easily take advantage of this CSS feature, as each page of the document has a fixed sized, and there is no overflow of content outside the page boundary.

By setting the CSS property content-visibility: auto on the fixed-size elements (typically <div> elements) that represent the page container, the browser can skip layout of the page contents until the user tries to view the page.

The table below shows timings for modified documents (A' and B') which have had content-visibility: auto applied to the relevant page container CSS classes.

Report A Report A' Report B Report B'
Chromium 21.5s (σ = 1.6s) 3.3s (σ = 0.3s) 171.0s (σ = 10.8s) 10.5s (σ = 2.3s)
FireFox 2.7s (σ = 1.0s) 2.6s (σ = 1.5s) 7.7s (σ = 0.5s) 8.2s (σ = 0.3s)

As can be seen, this property leads to a very substantial performance improvement in Chromium.

The content-visibility property is not supported by FireFox, so it is unsurprising that it does not affect rendering time.

With this property, the timings for both browsers are very comparable, suggesting that FireFox may already be doing the optimisations enabled by this property.

The content-visibility property is not yet widely supported, with no support for it in Firefox, Safari or Internet Explorer. As described above, FireFox provides good performance on these documents even in the absence of this propety. Other browsers have not been tested.

2.2 Relevance of DOMContentLoaded

The DOMContentLoaded event indicates that the DOM is fully loaded, and ready for use by JavaScript. It does not require all external images to be loaded, or for the document to be fully laid out and rendered, however with these samples it does appear that the event fires at the point that layout is completed. During the loading process, the browser's scroll bar will be changing, and it is not possible to scroll to later pages in the document.

Even if an iXBRL viewer is not used, there is benefit to optimising the time taken to complete the layout process, as this is the point at which the full document is accessible to the user, and at which the scroll bar stops self-adjusting, which can be annoying.

3 Download speed vs rendering speed

The testing carried out above was performed with report stored in a local file, so I/O speed is unlikely to be a factor in performance. In real world usage, filings will commonly be retrieved over a network, in which case I/O speed may become relevant.

The timings from Section 2 represent the browser processing the HTML at rates between 127Mbps (43MB in 2.7s) and 1.3Mbps (29MB in 171s). Achieving the former speed over a network to a typical end-user broadband connection would be rare, whereas download speeds in excess of 1.3Mbps are common. This means that if rendering is optimised, or an inherently fast browser is used such that processing speed is closer to the former, network speed may become the limiting factor.

3.1 Performance implications of embedded resources

The filings studied here include all resources embedded into a single HTML file. This includes fonts and images, which are included as base64-encoded "data" URLs.

As noted above, the DOMContentLoaded event does not require all external resources to have been loaded, and so where I/O is a limiting factor, there is a potential performance benefit to using external resources as it reduces the amount of data that needs to be transferred before this event can fire.

More investigation is required in order to quantify the potential gains, but it seems likely that the approach of embedding image and font resources can only harm performance. Given the widespread use of the Report Package format to package an iXBRL report with its dependencies, there does not appear to be any benefit to embedding resources in this manner, and we would recommend against the practice, although we are aware that it is required by some filing rules.

4 HTML efficiency

Many iXBRL filings are produced by conversion from a PDF report into HTML using automated conversion software. Such software will attempt to replicate the appearance of the PDF as accurately as possible. Unfortunately, this process can lead to the generation of inefficient HTML. For example, the single phrase "COVID-19 had a marked impact on private", taken from Report A, is marked up as follows (additional new lines inserted for readability):

<div class="t m0 x41 ha y2af ff7 fs6 fc4 sc0 ls3 ws3">
  COV<span class="_ _1"></span>ID<span class="_ _4"></span>-<span class="_ _2"></span>19 
  ha<span class="_ _1"></span>d a mar<span class="_ _1"></span>ked 
  i<span class="_ _1"></span>mp<span class="_ _1"></span>ac<span class="_ _1"></span>t 
  on p<span class="_ _1"></span>ri<span class="_ _1"></span>vate

As can be seen, there are 10 additional <span> elements inserted within words in the phrase. The classes on these elements insert an additional pixel of spacing between certain letters. We can gauge the impact of this by removing these spans completely:

<div class="t m0 x41 ha y2af ff7 fs6 fc4 sc0 ls3 ws3">
  COVID-19 had a marked impact on private

Figure 1 shows the line in its original form. Figure 2 shows the result of removing the span elements completely. In both cases, only the first line is modified. The second line is included for reference.

Figure 1: With span elements
Figure 2: Without span elements

The difference in spacing between individual letters is barely detectable, but there is a small difference in the overall line length (219.3px rather than 222.3px), which may have an impact on the overall appearance of the document.

The overall length of the line can be restored by adjusting the CSS letter-spacing property at the line level. Figure 3 shows the same text with letter-spacing: 0.23px added to the enclosing <div> for the first line. This restores the overall line length to 222.3px. An almost identical result can be achieved by specifying word-spacing: 1.35px for this line.

Figure 3: Without span elements, letter spacing adjusted

This change reduces the source size for this line from 370 bytes to 110 bytes (70% size reduction) and the number of DOM element nodes from 11 to 1 (91% reduction).

We have not carried out any performance testing with these changes applied to a full document, but clearly the optimisation shown above has the potential to very substantially reduce the size of both the source document and the resulting DOM representation, and it is likely that this will improve rendering time and reduce memory usage.

5 Summary and Recommendations

Experience in 2021 demonstrates that highly designed financial reports prepared in HTML can result in files that exhibit unacceptably poor performance when opened in a browser. However, even for the worst cases studied in this document, acceptable performance can be achieved with a very simple CSS modification. It is likely that performance can be further improved with some additional steps, although this has not yet been quantified.

The Working Group makes the following recommendations to improve the performance of large iXBRL reports.

Report creation software vendors should:

Data collectors should:

Preparers should: