Element Inline Styles vs Classes - Browser Rendering Speed

The Speed of Browser Rendering: Element inline styles vs classes

We had an interesting issue while supporting an application here at my client. We had a list of elements that we needed to filter based on text inputs. The way the code worked it was using jQuery to take up the collection and iterate through it based on the filter. It would then show or hide the element based on the filter criteria. The problem was that the entire process was slow and the business users were starting to find it burdensome.

Why was it slow? We spent several hours examining the legacy code to understand exactly what it was doing and why. The project was constrained to using jQuery to accomplish many of its UI tasks. Further, the original writer of the code seemed to not think much of classes because they were using inline element styles on all the elements.

We were unsure why the code did not perform quickly, but as an exercise in best practices we replaced the inline element style with a class (which we quickly defined in a style tag in the HTML). Immediately, the code started to perform five times better. So, it seems that simply switching to a class made the difference – but why?

The answer is that the browser has two separate pipelines for HTML and CSS which are compiled together and sent to the browser’s Rendering engine:

See the performance issue for yourself, check out this benchmark: https://jsperf.com/inline-style-vs-css-class/2 (credit to Sergey Ermakovich )

So how are inline element styles handled in this process?

Per https://www.html5rocks.com/tutorials/internals/howbrowserswork/#style , it turns out that inline styles are eventually translated into CSS rules for the element upon which it sits. This means that for JavaScript processes that are dynamically composing or changing large lists of elements each individual element has its own style rule for the browser’s rendering engine to consider.

This, in effect, meant that there were hundreds of style rules being created and changed for our application. Using a CSS class corrected this problem because it reduced the style rules from hundreds to one. Also, the browser can cache the CSS class for the benefit of the rendering engine.

Furthermore, the CSS style rule that element inline styles are eventually created into are one of the slowest types of CSS rules available. The inline style results in an extremely specific ‘Descendent’ selector. This type of selector is slow because CSS is read from right to left by the browser. So for example if we had this selector:

html body ul li a {}

Then the browser would first find all the <a> tags in the document, then it would find all of the <a> tags with a <li> parent and so on until the specific elements that match the criteria are resolved into a set and the rendering engine can apply the styling required. (reference https://css-tricks.com/efficiently-rendering-css/ )

Finally, the Google reference guide warns us that inline styles on HTML elements are blocked by default with Content Security Policy.

https://developers.google.com/speed/docs/insights/InlineCSS

https://www.w3.org/TR/CSP/#should-block-inline

But why should the CSP block inline styles? CSP doesn’t give us an explanation – but I found one for you:

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values

Before you even click, if you were thinking ‘I bet IE…’ the answer is ‘yes’.

So, element inline styles – simply put, you probably should not use them. If you do use them then be aware of the risks: they are slow and they are a potential security problem.