Chrome’s IndexedDB— from best in class to the slowest

Chrome has historically been the most stable and fast implementation of IndexedDB compared to the other browsers, but running some tests today tells a different story. It’s still the most stable (or 2nd most after Firefox) but the speed has fallen behind.

When I open Dexie’s simple performance fiddle, it looks like this in my Chrome:

And when I run the same on Safari:

Wow! 1 ms to find 99 documents and 21 ms to find almost 4000 matching docs!

And on Firefox:

Firefox is not that bad either! And unlike Safari, it isn’t slow in object deletions.

Now, this test puts random numbers into the indexed property, so it might not be 100% fare. So if I run the test 10 times on each browser and divide the querying time with the number of query results, it boils down to the following average results for each browser and test-part:

• The average time for Chrome to create 10 000 objects, is way slower than both Safari and Firefox.
• The average time for Chrome to query a range is loads slower than both Safari and Firefox.
• Deleting docs though, is fastest in Chrome but not far from Firefox.

The tests were totally non-scientifically run on my laptop browser but at least 10 times each to get average results. But after writing down the results of each test in my spreadsheet, I noticed a slight slowdown on Chrome of query speed the more times I had run the test. I thought this could be due to some kind of index fragmentation so I couldn’t be 100% sure that database wasn’t more fragmented from start on my Chrome browser. So to be fair to Chrome, I gave Chrome some special care that the other browsers didn’t get: I deleted the database and re-ran the tests 10 times again to eliminate that possible unfairness. It made a difference! But still, Chrome is falling behind:

So, after recreating the database on Chrome to eliminate fragmentation causes, we get much better results, but still far away from how Safari and Firefox perform: 0.038 milliseconds per result row compared to 0.009 ms on Firefox and 0.005 ms on Safari. Still, I never measured how Safari or Firefox performed after database recreation — they might also perform better. But at least we know one thing: Safari and Firefox are way faster than Chrome in populating and querying IndexedDB.

Initial sync for offline applications

An offline-capable application will typically do large bulk-add operations on its initial sync. The time this take will affect usability for PWAs. In this use case, Safari outperforms the other browsers, Firefox is somewhere in the middle, Chrome is twice as slow as Firefox and 5 times as slow as Safari.

Summary

Chrome seems to have fallen behind both Firefox and Safari in IndexedDB querying speed and that:

• Safari seems to have become the fastest browser in regards to adding and querying IndexedDB, but still falls behind due to its slow deletions.
• Firefox performs much better than Chrome in adds and queries, but falls behind Safari. On the other hand, it doesn’t suffer from extremely slow deletions, as Safari does.
• Chrome performs a lot slower than the other two in all but deletions — where Chrome is the fastest.
• Bulk-putting objects into IndexedDB is at least 5 times slower in Chrome than Safari and 1.8 times slower than Firefox.
• Querying a large range is at least 8 times slower in Chrome than Safari, and 4 times slower than Firefox.
• Deleting objects is still fastest in Chrome: More than 30 times faster in Chrome than Safari and slightly faster than Firefox (1.2 times faster).

Test environment

The tests were performed using this fiddle on my laptop.

Laptop configuration:

• macOS Big Sur, Version 11.2.1. MacBook Pro.
• Processor: 2,2 Ghz Quad-Core Intel Core i7
• Memory: 16 GB 1600 Mhz DDR3

The versions of browsers were:

Chrome: Version 88.0.4324.192 (Official Build) (x86_64)
Safari: Version 14.0.3 (16610.4.3.1.4)
Firefox: 86.0 (64-bit)