Are backticks (``) slower than other strings in JavaScript?
I ran some tests using jsperf to find out which string character works the fastest and whether comparing to the empty string is slower than other methods of checking for an empty string.
The speed of string literals in JavaScript
A recent comment on my Medium blog got me wondering about whether there are performance differences between the character used to create a string literal in JavaScript:
Author Brian Mearns had stopped by with an interesting perspective that I had never thought of. He said backtick literals are less performant (in other words, slower) because they need to processed.
In other words, the variable interpolation that we want from backtick literals are an Achilles’ heel — processing the template literals slows performance.
This left me wondering whether this was true, and if it were whether it is one of those performance optimizations that doesn’t matter much now that computers are so fast. Or is it still a big deal for JavaScript performance?
It left me wondering how much performance we would be sacrificing if we chose to only use backtick literals, almost like like re-rendering a component vs. re-rendering the DOM. Extra component re-renders will slow an app a bit, but re-rendering the DOM too many times can wreck performance.
Performance comparisons with jsperf
Are string literals slower when created using one character compared to another? It sounded odd and a little nonsensical, but was it true?
Similarly, I had read that using the empty string “” for checking whether a string is empty using comparisons is slow compared to checking length or making a falsy comparison. But does that matter either?
The solution: speed tests with jsperf
I wanted to find out, so I ran some test cases using the free tool jsPerf to measure performance. I examined three groups of code snippets:
- Single quotes, double quotes, and backticks;
- String comparisons to check for the empty string; and
- Interpolation with backticks vs. string concatenation
The results are shocking!
First test: Creating string literals and empty strings
Backtick literals were actually the fastest string literal to create across the board, although the difference is less than 1%.
Both when creating a Hello World string and creating the empty string, jsperf picked the backticks as the fastest string literal.
From this point of view, there should be no reason that a linter like ESLint would disallow template literals (backticks ``) by default, at least not with the justification that the backticks are less performant.
Second test: Checking for the empty string
Another urban legend busted! Using the string literal actually results in the fastest comparison, although again by less than 1%.
Noticeably, creating string literals (the first set of tests) was over 10000 faster than running these comparison tests in JavaScript.
So, even if there were extra time spent creating a string literal, creating string literals is probably a lot faster than all the rest of your code.
Like almost 1 trillion string literals can be created per second faster.
In fairness, I used extremely short strings, and performance could very well vary when dealing with larger amounts of data.
Third test: Concatenation vs interpolation
Here’s the rub: Interpolation is actually slower than string concatenation, which is what I think Brian Mearns’s original point may have been.
On the other hand I don’t think Brian is suggesting we give up the code readability backticks give us and go back to string concatenation.
And, for my point of “If we are going to standardize, let’s standardize to backticks” — that’s still valid, since backticks are just as fast for non-interpolated strings, as we saw in the first round of tests.
In other words, interpolation may be slower than string concatenation, but most JavaScript developers are going to prefer backtick literals for the ability to write cleaner code despite the small hit to performance.
Wrap up: Strings are strings in Javascript
Testing the performance of string literals using jsperf, I found only very small variations in performance speed of different literals.
These were within the measurement error, so there is likely no actual difference in performance between the types of quote literals in JavaScript.
We can put the myth to bed that backticks are slow while still recognizing that most people prefer the readability of single or double quotes.
As I wrote previously, I usually use double quotes with liberal use of backticks for variable interpolation and multi-line strings.
There’s no need to be picky! 😁
Additional resources:
- Jimmy Breck-McKye wrote a guide on his blog about how to use
jsperf:
- SitePoint has an article about using the built-in
performance.now()function to measure the performance of JavaScript code:
- Nicolás Bevacqua writes that template literals are strictly better than other strings in all circumstances at PonyFoo:
- This StackOverflow answer by Andrew Odri has additional data finding similar results regarding the performance of string literals:
- Maya Shavin reports that whether string concatenation or interpolation is faster is probably browser dependent so is likely not worth optimizing:
- I examine whether using Babel to transpile backtick literals restores any lost performance in a follow-up article in Better Programming:
Dr. Derek Austin is the author of Career Programming: How You Can Become a Successful 6-Figure Programmer in 6 Months, now available on Amazon.
