When tasked to develop new projects, conscientious developers do all they can to ensure that the sites they make are as performant as possible. The opposite can often result. Even as we approach the end of a project, we find that performance budgets are exceeded, but budgets be damned, we’ve got to get that site out the door.
This is what happens when speed to market outweighs speed itself.
You’re not the only performance-minded developer who struggles with this. It can be easy to blame yourself when this happens, but there’s a lot you can do to help the situation, before and after the fact.
Discuss performance early on in project planning
It sounds like a no-brainer as far as advice goes, but if you’re not discussing performance in the planning phase of a project, you’re likely to suffer poor outcomes. You have to do more than just talk about performance. You need to present the issue to your team in a way that evokes genuine concern for the user. Web performance is a user experience issue, after all. Especially when you consider that no experience exists until a site begins rendering. If an experience is sufficiently janky when interacted with, it’s poor by its very nature.
Understand your audience
Every projects should have a target audience defined. This demographic is not only essential to the project’s success, it’s also a key data point for setting meaningful performance goals. You’ll want to know aspects of your audience such as their average connection speed, what percentage of them are on mobile devices, and so forth. When it comes to this type of data, Akamai’s State of the Internet Connectivity Report is the gold standard.
Case in point: Let’s say you have a project targeting folks in The United Kingdom. As of the second quarter State of the Internet report for 2016, the average speed for a UK citizen is 15 megabits per second. With testing tools like sitespeed.io (or even just by defining a custom throttling profile in Chrome’s developer tools), you can simulate to a degree what the average user in your audience may experience when they visit your website. This kind of insight can be valuable in determining if your site’s performance is up to snuff.
Beyond internet speed, you have to consider the capabilities of your users and their browsers. Let’s say you’ve written a site that is optimized for and runs on HTTP/2. You ought to check your targeted audience’s browser support for this feature via caniuse. If your audience has a significant portion of users that don’t support a feature, consider how this could hinder performance for them. HTTP/2 isn’t the only thing to consider. WebP images are supported by Chrome and similar browsers, which may be an optimization opportunity for your development team.
Set a performance budget
Performance budgets are important. As Chris Coyier and Tim Kadlec have pointed out, it may not be best to rely on time-based metrics. These are figures like first paint and page load time. While time is the quantity we most often seek to reduce when it comes to web performance, it’s relative to a given user’s connection speed. Therefore, those figures are not authoritative without context. A large, media-rich site is likely to be intended for an audience using powerful hardware and a blazing-fast broadband connection. In cases like these, you can get away with some complexity (or perhaps even a lot), but you still have an obligation to deliver content as optimally as possible. In light of this, we’ve got to think about what metrics are suitable for inclusion in performance budgets.
When you set a budget, place less emphasis on timing. Instead, consider quantity-based metrics, such as the amount of requests and the total payload of a page with an unprimed cache. Request amount may not mean as much to you if your site will run on HTTP/2 (which is not guaranteed to be the case for HTTP/2-incapable clients), but it’s not unreasonable to assume that more requests could mean that you’re transferring more data to the user.
Beyond quantitative metrics, there are a few indices worth mentioning. The latest version of sitespeed.io introduces a speed index called The Coach, which is based on how well your site adheres to a number of defined best practices. As always, there’s Pat Meenan’s Speed Index and RUM-SpeedIndex. You can rely on indices such as these to establish realistic performance budgets that, when met, will translate into better performance overall.
Limit the use of unnecessary frameworks and libraries
Sounds like another no-brainer, yet it’s good advice. Ask yourself if you need Bootstrap in a time where smaller CSS frameworks exist. Ask yourself if you need a CSS framework at all. If you’re churning out sites with few unique templates, consider using a CSS reset such as Eric Meyer’s and write your site-specific styles from scratch. This can be difficult to do when speed to market is crucial, but it’s worth thinking about. At the very least, seek to balance convenience with speed the best you can.
On the JavaScript side, ask yourself if you even need jQuery. APIs like querySelector, addEventListener and classList provide a good chunk of the same functionality. If you need a familiar jQuery-like API, consider more diminutive options like Zepto, Shoestring or Sprint.
Test often as development proceeds
As your project winds its way through development, use an automated testing tool (such as the aforementioned sitespeed.io) to monitor for fluctuating performance indicators. Doing so will allow you to see if your budgets are being exceeded before your site launches.
We couldn’t do these things and had to launch anyway. What now?
We’ve all been there. It’s okay. External pressures forced you and your team to get something out the door to make good on a commitment. Now you’re left with a site that, while well-designed and useful, is sluggish. Don’t beat yourself up. Just remember one thing: This is the web. You’ve always got an opportunity to revisit your work and improve on it.
Optimize images
This is the one thing that will likely yield the biggest benefit, though the level of effort may vary. If you’ve built a static site, you can use tools like imagemin or TinyPNG. If your site is powered by a CMS, things get a little more complex. WordPress sites can use a plugin like EWWW Image Optimizer. Sitecore users can use Dianoga to accomplish much the same thing. Whatever your CMS is, see what its plugin ecosystem offers.
If you have time and resources at your disposal, another option to consider is serving WebP images for users on Chrome and Chrome-derived browsers. It does take some work, but it can be done. The savings can be significant, and the technology is reasonably well supported. HTML features such as the <picture> element allow you to specify fallbacks with ease. Picturefill can fill in the gaps for older browsers.
Use a CSS postprocessor
You’ve heard of CSS preprocessors like LESS and SASS, but what about a CSS postprocessor? PostCSS is one such tool. PostCSS has its own ecosystem with a myriad of plugins available, and some of them can help you trim down the size of your CSS files.
The first such plugin is cssnano. This tool makes many optimizations to your CSS, reducing it further beyond what mere minification can provide. cssnano is also reasonably safe to use. Should it introduce problems, you can instruct it to act more conservatively via the safe option.
Another such plugin, though not strictly a PostCSS-only offering, is uncss. This tool compares your CSS against the contents of HTML files and/or URLs you provide and strips out the unused portions.
Both of these tools can potentially yield significant savings in the way of file size (and thus quicker first paint times) in exchange for relatively little effort. If these tools aren’t in your workflow, give them a go!
Use resource hints
Resource hints are small instructions that tell the browser to do all sorts of things. Things such as connecting to a remote host ahead of time, preloading an asset, or even prefetching and rendering an entire page. They can be specified in an HTML document using the <link> tag, but can also be specified as Link HTTP response headers.
Resource hints take little effort to use, but they inch your site a bit closer to better performance. For instance, say your site loads fonts hosted by Google. Requests for those fonts come from two domains: fonts.googleapis.com, and fonts.gstatic.com. Because opening a connection to another domain can take some time, you can give the browser a head start with the preconnect resource hint to these domains like so:
Link: <https://fonts.googleapis.com>; rel=preconnect,<https://fonts.gstatic.com>; rel=preconnect
This is just one of many uses for resource hints. There are many others to consider, so experiment and see what works for your project.
Things aren’t going to be perfect overnight
Performance is a tricky thing to get right. When speed to market works against you, do your best to be proactive. Don’t sweat it if you can’t fine-tune everything before a project launches. The great thing about working with the web is that we can revise our work later on. Improvements can be made after the fact. If you have honest conversations about performance early on in the process, you’re going to be better off. If you have a post-launch plan, you’ll be able to remedy problems after the fact as well.
Jeremy Wagner is a front end developer and the author of Web Performance in Action, an upcoming title from Manning Publications. Use coupon code
wagnerdzto save 38% on it or any other Manning book.