Poor performance leads to exclusion. When we create heavy sites we limit what users can access our content. Those with more powerful devices and better network will get sites loaded faster. Those with older devices and slower network will need to wait more.
Study after study shows how slowing sites down results in less engagement, less time on the site and a general decrease in key business metrics. Still, in our development teams we continue to prioritize more highly shipping features over addressing web performance.
Don’t get me wrong, features are important. Serving an empty site is fast, but not very useful. It’s important to deliver a core set of features, and do it in such a way that many users can enjoy it. Just keep in mind that if they user can’t use the product we will lose them, no matter how much we have worked on the feature set.
Developers play a key role in prioritizing performance. They can steer what tasks the development team works on, and they can prove with results the impact of the changes.
While some performance improvements might be costly in time, there are usually lots of low-hanging fruits that can drive to big improvements. And we are more prepared than ever to do a good job.
We have a better understanding of how the browser and network works, and how to serve content to the user without incurring in delays. We also use tools to build our sites that help us defining dependencies and delivering a small payload, tailored to the current session.
Single Page Applications and the trend of moving most of the logic to the client comes with performance implications. There is now more work to do in the browser, like data-fetching, templating or routing, which makes sites slower out-of-the-box. If we don’t stop there and explore the beauty of component-based sites we will see that code-splitting and lazy-loading fit perfectly in the picture and they allow us, for the first time, to be smart on how we ship code while keeping complexity at a minimum.
While it can be difficult to keep track of every new tool and browser API, it’s important to be aware of them. It wouldn’t be smart to jump immediately on them and rewrite constantly our product on the latest and trendiest stack, but we can learn something from them.
I get inspired by tools like Gatsby or Next.js. They let us build sites that have a high performance out of the box. What they do is not black magic, but making a good job serving what is needed for the current page, and deferred the loading of the rest of the content. Nothing prevents us from adopting some of those techniques to our projects to give them a boost.
The future looks bright. We are decoupling UI and data. We are creating sites that can be run on a laptop, phone, TV or smartwatch. We are building offline experiences and sites that synchronize in the background and handle push notifications. We are moving desktop applications to the web, seamlessly running assembly code in the browser.