Over at filings.xbrl.org we have indexed well over 2,000 Inline XBRL (iXBRL) filings for annual reports in the EU and UK. All are available in an iXBRL viewer, allowing the use of XBRL tags to navigate the data and understand disclosures prepared in different original languages. We find these features highly useful, but there is one problem: some filings take a frustratingly long time to open.
“How long a report takes to render in a browser depends on a number of different factors, but load times in excess of 30 seconds are not uncommon on my laptop. So what is it about iXBRL reports that makes some so slow to load, while others with similar levels of design can open almost instantaneously? The answer, for the most part, is not the iXBRL itself, but the HTML,” says Paul Warren, XBRL International’s Technical Director, in a new post in our Taggings section.
HTML is the language used to create the layout and visual appearance of reports, and can work well to reproduce the highly designed, “glossy” documents that companies want to present to the world and is being Where it is inefficient, however, it can render slowly.
Fortunately, HTML can also be fast and streamlined, and can help make documents more accessible and easier to use. “There are a number of things that can be done to dramatically reduce the size and improve the efficiency of HTML used in ESEF reports,” says Paul – and all without compromising one iota on the design quality. His suggestions include removing unnecessary HTML tags, moving embedded images and resources into separate files, and one tiny code change that can massively improve performance.
With highly designed Inline XBRL still in its initial stages, there is scope for significant HTML optimisation with relatively simple measures. We encourage vendors to implement these recommendations, and filers to check their loading speeds and discuss this issue with their providers.