Here are three things to prove that:

1. Recent patches committed to JSON:API in Drupal 8.8

https://www.drupal.org/project/drupal/issues/3039730 is a simple issue which is making sure that if you are requesting information of related entities then it statically caches the resource type information for that relationship so that when multiple entities of the same entity type and bundle are requested it doesn’t have to collect the resource type information for the related entities over and over again.

https://www.drupal.org/project/drupal/issues/2819335 adds a cache layer to store the normalized entities so that if we need the normalized version of an entity we can just get it from the cache instead of normalizing the whole entity again which can be a very expensive process.

https://www.drupal.org/project/drupal/issues/3018287 introduces new cache backend to store JSON:API resource type information which was stored in the static cache. This means that instead of creating JSON:API resource types every request, we are just creating them once after cache clear.

2. Profiling using blackfire.io

I was able to do some profiling to compare the JSON:API core module in Drupal 8.7 versus 8.8 . Here are the initial conditions:

• PHP 7.3
• JSON:API version 8.7
• No JSON:API Extras
• Page Cache module disabled.
• Dynamic Page Cache module is set to cache.backend.null, which forces a 100% cache miss rate.
• Cleared all caches.
• Visit user login page to rebuild the container and essential services.

Case I

Visit the first JSON:API endpoint which loads 50 nodes with 8 fields, 2 computed fields, 2 filters, and sorted by title.

Case II

Visit the first JSON:API endpoint which loads 2 nodes with 45 paragraph fields, each paragraph field has 6 fields and 2 computed fields, 1 filter.

Then update the JSON:API to 8.8, all other initial conditions were the same as before.

Case I

Visit the first JSON:API endpoint which loads 50 nodes with 8 fields, 2 computed fields, 2 filters, and sorted by title.

Case II

Visit the first JSON:API endpoint which loads 2 nodes with 45 paragraph fields, each paragraph field with 6 fields and 2 computed fields, 1 filter.

Comparison:

Case I

The comparison shows 79% improvement in response time.

There are 39 more SQL queries on JSON:API in Drupal 8.8.

After having a detailed look at those shows that there are additional calls to new cache bin added by JSON:API but the most important thing was 50 fewer queries to url_aliase table.

Function calls also show the reduced number of function calls to Entity API and normalizers.

Case II

The comparison shows 66% improvement in response time.

There are 35 more SQL queries on JSON:API in Drupal 8.8.

These are the same additional calls to the new cache bin.

Function calls also show the reduced number of function calls to Entity API and normalizers — same as before.

I ran the same scenarios with redis cache backends instead of the default database backends. The results show the same kind of improvements.

3. Raw response comparison:

What matters is how this all plays out on the website.

JSONAPI:8.7 first page load on cold cache

JSONAPI:8.8 first page load on cold cache

Conclusion:

In short, JSON:API in Drupal 8.8 is going to be significantly faster than its predecessor!

To improve the performance like this takes enormous effort and this was a community accomplishment but special thanks to @ndobromirov, @kristiaanvandeneynde, @itsekhmistro, and last but not least the hardworking maintainers of JSON:API module @e0ipso, @gabesullice, and @Wim Leers, without their work, support and guidance this would not have been possible. Please give them a shoutout on Twitter or come say ‘hi’ in Drupal Slack #contenta channel. If you are interested in JSON:API and its performance then please feel free to help out at https://www.drupal.org/project/issues/search?status%5B%5D=Open&issue_tags_op=all+of&issue_tags=Performance%2C+API-First+Initiative.

Thanks to @Wim Leers for feedback on this post!