“To paraphrase Tolstoy, all fast websites are alike, but all slow websites are slow in different ways.” — Kyle Mathews, creator of Gatsby
Making fast websites is hard.
Site performance isn’t just a technological challenge. It’s also an organizational challenge. If one team owns the CMS, another owns the UI and another owns the app server, coordinating around performance improvements becomes difficult. And these variations can be endless. To paraphrase Tolstoy, all fast websites are alike, but every slow website is slow in its own unique way.
The good news is that there are established patterns for improving website performance, no matter what your initial setup looks like. The bad news is that front-end performance checklists are 40 items long (example). Your team probably doesn’t have the time for a checklist that long, and that’s why our approach is different.
Gatsby bakes these performance improvements in at the framework level. We nerd out about performance, so you don’t have to!
We combine best-practice front-end development patterns like route-based code splitting, PRPL, service workers, and offline support with dynamic data integrations via a rich set of plugins (WordPress, Drupal, Contentful, to name but a few).
In other words, in a Gatsby site, all data is “alive” and on call, reacting to browser behavior such as a user hovering near a button or scrolling toward the bottom of a page. The Gatsby framework anticipates what is likely to be wanted next, then starts to fetch and preload that content in the background before it’s even requested by the browser—meaning that the user’s wish is delivered almost instantaneously. (That kind of pre-fetch hot loading can feel kind of magical, actually 🔮).
As a result, people use adjectives for Gatsby sites like “disgustingly fast.” Users report speedups between 3x and 10x after migrating a website to Gatsby.