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.

Dr. Derek Austin 🥳
Sep 17 · 6 min read
Photo by Evi Radauscher on Unsplash

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.

Photo by Cosmic Timetraveler on Unsplash

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?

Photo by Ludomił on Unsplash

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:

  1. Single quotes, double quotes, and backticks;
  2. String comparisons to check for the empty string; and
  3. Interpolation with backticks vs. string concatenation

The results are shocking!

Photo by Fezbot2000 on Unsplash

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.

Photo by Sean O. on Unsplash

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.

Photo by Derek Thomson on Unsplash

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.

Photo by Michael Monahan on Unsplash

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.

So 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! 😁

Photo by Sai Kiran Anagani on Unsplash

Additional resources:

  • SitePoint has an article about using the built-in performance.now() function to measure the performance of JavaScript code:
  • 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:
Photo by Mickey O'neil on Unsplash

JavaScript in Plain English

Learn the web's most important programming language.

Dr. Derek Austin 🥳

Written by

😀 Full-Stack Web Developer 🤓 JavaScript 😄 React 😁 React Hooks 😆 Jest 🥰 CodeSandbox.io Contributor 🧠 Mobile App Developer 🤳 Doctor of Physical Therapy 🆒

JavaScript in Plain English

Learn the web's most important programming language.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade