Late last year, I finally came around to using
fetch() instead of XHR to make API calls.
But the portal where students access my courses was already working just fine with XHR. Last week, I finally decided to update it to
I was not prepared for how noticeably faster that made the site.
The Fetch API might be faster than XHR
Because XHR has been around for so long, I expected that browsers would be better optimized for it and that it would be more performant.
I was wrong.
fetch()will be the same as XHR at the network level, but for things like decoding JSON, it can do that work off-thread because the API contract is promise-based up-front.
So, the actual API calls aren’t any faster.
But for APIs that return large amounts of JSON that need to be parsed from a string back into an object (like my courses portal),
How much faster is it?
When I tweeted about this last week, I had a few folks ask me exactly how much faster it is.
I’m an idiot, and didn’t think to take before/after metrics to measure the difference, so I’m not 100% sure. I suspect a lot of it will depend on how many products of mine someone has. More products means larger JSON payloads to parse.
Anecdotally, it must be at least 100ms or so faster, though, because that’s about the minimum amount of latency humans can detect before something feels “instant.”
I also talked with a few students about it, and they verified that the site felt faster for them, too.
What about getting HTML with
Unfortunately, if you’re using
fetch() to get HTML, there’s no equivalent way to make that promise-based.
If you’re working with large JSON payloads and want to give your site a little bit more of a performance boost, consider switching old XHR API calls to
If you’re getting HTML, you won’t see the same performance benefits, and can hold off.
And while the improvement was perceivable (the most important kind of performance increase), it was slight. On the scale of performance optimizations, this is a lot less important than other things you should do first.