If you think about your website as a digital storefront for your brand, you will of course want everyone who visits it to have the best possible experience. One aspect that if ignored could undermine all the effort you put into the design and the content on your website, is the technical quality. We would go so far as to say that technical quality, or rather the lack of it, has the potential to affect not only how users experience your website but also how they perceive your brand.
Here are a couple of reasons why you should strive for technical excellence on your website:
- Your business results rely on your website's ranking on Google, and Google will punish your ranking if you don’t fulfill the Core Web Vitals.
- You truly value your visitors’ personal integrity.
- You want to limit your environmental impact by reducing CO2 emissions from your website.
- You believe that first impressions last and want web pages that load really fast.
- You want to maximize the reach of your brand by making your website more accessible.
- You want to be able to push the design and need your technical aspects to be in order.
No matter what your reason for wanting to showcase your brand in a storefront with excellent technical quality is, this text will guide you on how to do it.
Find out how your website is performing
A good tool to use to find out how your website is performing regarding technical quality is webperf.se. Maybe your site is already among the 4000+ websites being measured on accessibility, speed, web standards, personal integrity, and security. If not, you can try it out for free (or buy a subscription). We got excellent help from webperf.se in learning how we could improve our own performance. After all, knowing the problem is half the solution.
Picking the low-hanging fruits brought us up to a score of 4.68. That left us with three major areas to focus on to reach the maximum score of 5.0. As we understand it, those three areas are common problem areas in need to be fixed. So we hope that sharing this information will prove helpful for others also looking to make the necessary improvements on their websites to reach 5.0 on webperf.se.
Three challenging areas to fix on your website
These are the three areas we had to improve to reach 5.0 at webperf.se.
1. Supporting the QUIC protocol
This is “just” a matter of how you serve your website, no changes to the site itself are needed. It’s about supporting the modern standard of HTTP3 and will provide some long-term advantages when it comes to speed, security, and energy consumption. Typically no radical advantages, but still worth doing. And as usual, quite easy to do if you know how.
2. Decrease the time to show large, high-resolution, complex images
This is the hardest problem of the three areas. After all, there is some physics at play here so even if you haven’t done anything wrong – you’ve used the right image sizes and image formats and not added unnecessary overhead – it will take time to transfer a lot of data. In fact, this problem is so big and common you’ll find that many sites that care a lot about technical excellence are shying away from using such images. Nothing wrong with that of course, but if you want this feature, there are solutions.
Overall, the solution is high compression of the *other resources* and to do the compression before it’s needed because it will be too expensive to do just-in-time. A bit counter-intuitive perhaps, but to not have your grade punished for having large, high-resolution, complex images loaded on the area the user will first see, you also have to deal with the other resources needed for this area. (If you only use small images, it doesn’t affect the grade.) More information about that in a minute, let’s just quickly discuss the last area first.
3. Get rid of flickery and performance-expensive CSS solutions
We also had some small issues with “Cumulative Layout Shift”, which is basically page elements moving around before the page has been loaded. As a matter of fact, we wanted to move further with non-blocking load and rendering, and we already had some flickering… We also had some delays before all the needed CSS was downloaded. Those issues, which of course also had some negative effects on the user experience, were the final obstacle for us reaching 5.0.
And the solutions we used
That was a lot of talk about the challenges. It’s the solutions we want, right? Thankfully factor10-consultant Nizar Selander has done a writeup for every one of those three areas. Here’s how we did it:
- Supporting the QUIC protocol:
↳Serving Sites with NGINX QUIC - Decrease the time to show large, high-resolution, complex images:
↳Improving Website Speed with Compression - Get rid of flickery and performance-expensive CSS solutions:
↳Striving for Performance and Design Harmony in Web Development
After applying these solutions, we got to 5.0. Hopefully, you will too!
What we *didn’t* do
In a way, we made it easy for ourselves to reach 5.0 by skipping a couple of common design decisions that are hurdles. We realize that there are situations when you *have to* choose differently, but as a general rule: Don’t make it hard for yourself if you don’t have to.
We didn’t start with a technical solution out of the box
Choosing some trendy platform or framework that can do anything when we only need 10% of the functionality, would mean having to compensate for all the problems the package comes with. This choice might sound obvious, but way too many websites have functionality that never gets used but still carries all the complexity that comes with it.
We didn’t use a CMS to serve the content to the user
A (CMS) Content Management System should be considered a tool for editors to handle and create content, but not to serve content to end users. Confusing these purposes will (at least currently) make it hard for you to reach 5.0, so we didn’t.
We didn’t add unnecessary scripts or third-party dependencies
This choice helps us in many ways to stay away from technical complexity. We didn’t add Google Analytics, marketing automation, third-party tools, or Facebook pixels, and we avoided using intrusive consent tools. This also saves performance and avoids problems with personal integrity. Have you noticed we don’t have a cookie consent message? That’s because we don’t use cookies!
We didn’t use frameworks only to improve developer experience
Sometimes you might hear developers motivate a bad result with the tools they use, which is giving them a great development experience. If there is a conflict between user experience and development experience, we prioritize the first. And plain vanilla tools work just great! The web is built of standards. Use that and use low-tech. Boom!
Finally
With technical excellence, you can skip some negative compromises. Instead of choosing performance OR security OR accessibility OR integrity, you can have it all!