Before we discuss improving app performance, I think we should take a step back to define what performance even means. To do that, we should make it a priority to understand the expectations of our target audience.
Like Accessibility, SEO, Testing, or integrating Multiple Languages, It’s wise to set goal posts / boundries for Performance and be intentional about fulfulling them. Having a goal requires planning and planning requires data.
Your Users Matter
When thinking about settings goals, a few initial questions present themselves:
- What are the primary browsers your users are utilizing?
- What is the average internet speed of your users?
- How many of your users are visiting on mobile compared to desktop?
Notice that these questions are all about the end user. Our main goal is to have a happy and reoccurring user. Performance plays a crucial role in building a good user experience. Have I said user enough? User, user, user, and user.
If you’re working on a new application you may not know the answer to these questions; set some goals anyways. When you have no boundries it’s inevitable you will compromise or get into a cycle of optimizing just to optimize. In my experience it’s more important to think about performance during development rather than afterward.
When thinking about setting goals, remember the needs of your users will differ from the needs of my users. For instance, at my current job, 90% of our users have the latest version of Chrome and most of them are on MBP / Mac Desktops. We license music to filmmakers who primarily work from their desktops with high-speed internet.
However, just because our users have the latest technologies doesn’t give us a pass to avoid basic techniques to improve performance further.
I’ve recently read the article 10 things I learned making the fastest site in the world where the author attempted to make the fastest site possible. He mentioned looking at benchmarks comparing his new smart phone to his desktop. From his observations he summarizes that his smart phone is about 10x slower than his desktop. I think it’s easy to forget that not everyone has a great computer, flashy new tablet, or a good consistent internet connection. Depending on your target audience, users with sub-optimal hardware may be large enough in number to make a dent in your company’s profit margin. It’s up to your team to determine who you’re aiming for and to adjust your performance goals accordingly.
As mentioned at the Google Chrome Dev Summit 2016 and social media alike, Google is encouraging developers to aim for a Time to Interactive (TTI) in under 5 seconds. Meaning your site should pretty much be fully loaded and operational in less than 5 seconds. At first you may say “5 seconds? isn’t that like, forever?” Indeed, 5 seconds is likend to eternity in interwebs time. There are plenty of articles with studies that show you have about a 2 to 3 second window to serve an e-commerce site before your users lose motivation and go somewhere else (Those pesky users), so what gives? Google’s less than 5 second TTI recommendation is for sub-optimal devices on slower connections! your site should really be ready in like 500ms to 2 seconds on newer devices and connections.
Thoughts on performance
Performance is presenting a responsive, snappy, and seamless experience to your users.
Performance is about perception. It’s serving your users something meaningful without distracting them with latency.
Performance is intentional and should be at the forefront of your development process to be done well.
In the next couple of posts we’ll start to cover the essentials of optimizing your application for better performance.
- Serve the minimum amount of critical resources necesssary to render the page
- Proper caching
- Maybe Code Splitting, Service Workers, who can say!?
We’ll also look at making sense of Chrome Dev Tools and other tools to help optimize site performance.
Thanks for reading,
-Andrew Del Prete