JAMstack is fast only if you make it so

JAMstack often promotes itself as an excellent way to provide performant sites. It's even the first listed benefit on jamstack.wtf, a "guide [which] gathers the concept of JAMstack in a straight-forward guide to encourage other developers to adopt the workflow". But too many JAMstack sites are very slow.

Vous pouvez aussi lire la version française, merci Arnaud pour la traduction.

You may have seen Alex Russell's frequent rants about Gatsby:

@matthewcp @justinfagnani @gatsbyjs @kylemathews @addyosmani Looking across the full set of traces, modern Gatsby seems to produce pages that take 2-3x as long as they should to become interactive.

This is not OK. Gatsby/NPM/React regressively tax access to content.

In less generous moments, I'd go as far as to say it's unethical.

Gatsby is an easy target (among many others) because it is currently not optimized for performance out of the box, despite what's promoted. It is possible to fix it, for example with this plugin, and I believe good React developers can make it shine, but it should be the default, not an afterthought.

Eleventy is very different, as Zach Leatherman reminds us in Eleventy’s New Performance Leaderboard:

Eleventy doesn’t do any special optimizations out of the box to make your sites fast. It doesn’t protect you from making a slow site. But importantly it also doesn’t add anything extra either.

The issue with most slow JAMstack sites is that they load a loooot of JavaScript. Remember that any added JavaScript has to be sent to the browser, which also needs more computation for it. It quickly impacts performance.

Sometimes, using the server-side build is enough to get data from an API and serve HTML to all visitors, which is much better for performance.

For example, swyx wrote Clientside Webmentions about implementing Webmention with Svelte. Any article promoting Webmention and easing its adoption is welcome! But even if it's nice for a demo of Webmention and Svelte, I wouldn't recommend doing it client-side.

Server-side first

I prefer doing it on the server.

It allows to:

  • call webmentio.io API only when building the site, which should be less often than visitors viewing pages.
  • cache the result of requests to webmention.io and the timestamp of the latest, so that the next one only asks for new webmentions.

It puts less pressure on webmention.io, with one single request per build, when a client implementation makes a much larger request (or even several, with pagination) for each page view.

For example:

  • my website received 75 webmentions in April 2020. I have probably built it a hundred times during the same period, so let's say 100 requests to webmention.io with small responses.
  • in the same period, my website had 3,746 page views (underestimated, I still use Google Analytics 🤷‍♂️), which would have made 3,746 requests to webmention.io with large responses.

Using the server-side build to get the webmentions provides multiple benefits:

  • The performance for the users is much better, with HTML already computed on the server and statically served.
  • Much fewer API calls, requiring much less computing time and power.
  • Everyone should know that Aaron Parecki provides the awesome webmention.io service for free, and most Webmention users seem to use it nowadays, so being nice with its API feels better.

Enhance client-side, if really needed

If you know you receive a lot of very useful webmentions that you have to show to your visitors, you can enhance the server-side generated list with a bit of client-side.

But remember every JavaScript added to the page has a cost, so the few additional webmentions have to be really useful.

So, instead of doing this for every page view, at least:

First, try to wait for some time after the site build before making client-side API calls. Keep the build timestamp available to client-side JavaScript, and wait for an hour, a day, or more, depending on the frequency of webmentions. You could even use the page's "age" to query webmention.io less for older content that probably receives less webmentions, as Aaron Gustafson did even for server-side call in his Jekyll plugin.

Then, keep track of a user's calls to the API, in localStorage or IndexedDB, so that you don't make these calls again a short while after. You could even use a Service Worker to cache requests and their timestamp.

Client-side only API calls sometimes make more sense

I agree Webmentions are not the most complex use case to explain that most of the time you should call APIs from the server at build time rather than from the client:

  • Webmentions to show are the same for all visitors.
  • Missing a few of the latest ones is probably not an issue.

So yes, many other use cases make client-side API calls necessary, or better than server-side ones, I understand that.

I say it should not be the default.

Promoting the AJMstack Mstack

That's also something I don't really like in current JAMstack trend, promoting JavaScript and APIs much more than Markup.

Here's for example what you can see on jamstack.wtf (simplified):

JAMstack
  1. JavaScript
  2. APIs
  3. Markup

As suggested by Yann, I would like to start by using this better presentation[1]:

JAMstack
  1. JavaScript
  2. APIs
  3. Markup

It makes more obvious there is a pile of things, quite useful for a "stack".

But I would like to suggest this modification:

AJMstack
  1. APIs
  2. JavaScript
  3. Markup

Of course, it reads as AJMstack instead of JAMstack, so I bet I won't be successful promoting it… 🤷‍♂️

But at least it feels more accurate, it shows JavaScript is the link between APIs and Markup.

It even allows to present this as a great progressive enhancement platform, as we can start with plain old (did I hear "boring"?) Markup…

Here's the Mstack:

Mstack
  1. Markup

Make sure this "stack" is great, and then enhance with JavaScript and APIs.


  1. CSS Grid and Flexbox are so fun to use, it took me just a few minutes to get this, look at this stylesheet! 💪 ↩︎

33 Webmentions

8 likes

4 reposts

  1. Damien Pobel avatar
  2. Vincent M. avatar
  3. m4dz avatar
  4. Kraus Vincent avatar

21 mentions

  1. Brian Rinaldi avatar Brian Rinaldi
    An interesting take on building for performance in the Jamstack by @nhoizey, which gets at something I personally keep trying to build awareness around - just because the J is for JavaScript, does not mean the solution for everything is client-side script. nicolas-hoizey.com/articles/2020/…
  2. Boris Schapira 🚀 avatar Boris Schapira 🚀
    #boostmark "JAMstack is fast only if you make it so", @nhoizey nicolas-hoizey.com/articles/2020/…

    I really like the concept of MStack.
    Client-side JS tends to slow websites, use it wisely.
  3. Arnaud Ligny 👨‍💻 💡 🚀 avatar Arnaud Ligny 👨‍💻 💡 🚀
    Et si on faisait d'avantage la promotion de la Mstack ?

    "JAMstack is fast only if you make it so"
    nicolas-hoizey.com/articles/2020/…
    #JAMstack
  4. Boris avatar Boris
    [Bookmark] "JAMstack is fast only if you make it so", Nicolas Hoizey (@nhoizey) nicolas-hoizey.com/articles/2020/…
  5. Baldur Bjarnason @baldur@toot.cafe avatar Baldur Bjarnason @baldur@toot.cafe
    “JAMstack is fast only if you make it so - Nicolas Hoizey”

    “That’s also something I don’t really like in current JAMstack trend, promoting JavaScript and APIs much more than Markup.” nicolas-hoizey.com/articles/2020/…
  6. Nicolas Hoizey avatar Nicolas Hoizey
    I updated the diagrams at the end of the article, with better use of CSS Grid, that was fun! 😁

    I hope the HTML used for these makes it accessible, too. But I don’t know how to test that.
  7. Ken Sherwood avatar Ken Sherwood
    "The issue with most slow JAMstack sites is that they load a loooot of JavaScript." - nicolas-hoizey.com/articles/2020/…
  8. Phil Hawksworth avatar Phil Hawksworth
    I'm with @nhoizey.

    Jamstack offers an opportunity for web developers to build great experiences for users. But as with all tools, we can mess that up if we're not thoughtful.

    Doing as much as possible on the server ahead of time is my mantra.
  9. Page screenshot https://wipdeveloper.wpcomstaging.com/around-the-web-20200515/
  10. JAMstacked 📮 avatar JAMstacked 📮
    JAMstack is fast only if you make it so — nicolas-hoizey.com/articles/2020/…
  11. Angsuman Chakraborty avatar Angsuman Chakraborty
    Jamstack is fast only if you make it so nicolas-hoizey.com/articles/2020/…
  12. Page screenshot http://virusno.tk/jamstack-is-fast-only-if-you-make-it-so/
  13. Randall Degges avatar Randall Degges
    JAMstack is fast only if you make it so nicolas-hoizey.com/articles/2020/…
  14. Bejamas.io avatar Bejamas.io
    JAMstack is fast only if you make it so by @nhoizey
    nicolas-hoizey.com/articles/2020/…
  15. CoderYoga🧘‍♂️ avatar CoderYoga🧘‍♂️
  16. Varun A P ⚡ avatar Varun A P ⚡
    Came across this today! And I couldn't agree more.

    JAMstack is fast only if you make it so by @nhoizey

    nicolas-hoizey.com/articles/2020/…
  17. FullStack Bulletin avatar FullStack Bulletin
    JAMstack is fast only if you make it so - Nicolas Hoizey nicolas-hoizey.com/articles/2020/…
  18. Marc Radziwill avatar Marc Radziwill
  19. TakeShape avatar TakeShape
    When you're building on the Jamstack, don't forget that sturdy Markup is a key component! The speed gains of a static site are lost if you're relying too heavily on Javascript for your rendering.

    nicolas-hoizey.com/articles/2020/…
  20. PageSpeed.cz avatar PageSpeed.cz
    🤔 Proč i weby postavené na #JAMstack mohou být pomalé?
    Aneb rychlost backendu není všechno.
    nicolas-hoizey.com/articles/2020/…
  21. Page screenshot https://your.cheer.id/towards-a-lightweight-jamstack/