JavaScript syntax highlighting is bad for performance

My visitor's satisfaction is one of the top priorities of this blog. For that reason, I decided to remove syntax highlighting completely. I found out that syntax highlighters are bad for performance. In fact, all the syntax highlighters tools used since the very beginning of this blog were actually poor when it comes to performance. Most of my visitors come from the USA, but there's a significant percentage of people who connect to this site from Asia. When the distance increases, it also affects latency and response times. I'd like to explain why JavaScript syntax highlighters are bad for performance using very simple words.

Too many GET requests

Generally speaking, a JavaScript syntax highlighter is made up of a single core file and several additional language files. Let's say that on your blog your main topics are CSS, JavaScript, HTML5 and PHP.

Four languages mean four different language files, plus the main core file. The total of five JavaScript files forces a browser to perform five different GET requests.

These additional requests, added to the overall amount of the HTTP requests of your site, result in an increased loading time of your pages. I didn't take the exact timing of such delays, but I reasonably think that they should be approximately of more that 5-10 seconds, especially on high-traffic web sites.

Poor string manipulation

In JavaScript, advanced string manipulation is handled by regular expressions (Perl-compatible, with some differences). Usually a syntax highlighter works on a target element by replacing its HTML content with new content created on the fly by searching and replacing some strings which have a special meaning for the code in use.

For example, a DOM structure like the following:

<pre class="js">
function A() {}
</pre>

becomes:

<pre class="js">
<span class="kwd">function</span> A() {}
</pre>

This search-and-replace routine is performed several times on each code block on the page. To get an idea of the process behind syntax highlighting, you should measure the duration of a single routine, multiply it for the number of significant strings of each block and finally multiply the result for the number of blocks of a page.

DOM loading delays

Most of these routines take place on page loading. More specifically, the event used is DOMContentReady or, if it's not available, the load event of the body element is used instead.

The problem is that if your page contains several other assets, such as media elements or JavaScript widgets, DOM loading will be further delayed. In fact, syntax highlighters don't feature a really flexible way of handling the bootstrapping (so to speak) of the library, meaning that you cannot preload them without affecting the way by which your code blocks will be displayed.

If you load a library too soon or too late, you won't see the CSS styles applied to your code blocks but only raw code.

3 thoughts on “JavaScript syntax highlighting is bad for performance”

  1. The "Too many GET requests" problem is avoidable if you concatenate your css files and it's the best if you also minify them. In addition you can use the SPDY protocol, developed by google (apache module is currently available). Chrome is relatively popular browser and it knows this protocol, so I think it's worth to use it.
    I think you can enhance the performance if you use the compiled html code in your posts. Yes, it's not so comfortable as if you just put it into a pre block, but as it seems it pays off. Eventually if you use wordpress, with a simple plugin you can automatize this process.

  2. Thanks Gabor. My concerns were primarily about those platforms that don't allow users to get much control over their sites, such as Blogger or other publishing platforms. Your remarks are really interesting. Thanks for sharing. :-)

  3. Yes, I wanted and then I forget to mention that you need file system access (and for the SPDY module maybe the sudo rights) to do these things.
    And the other thing is according to my experience most of the users don't like to rummage in the code, they just want to use it :)

Leave a Reply

Note: Only a member of this blog may post a comment.