I have worked on many sites and projects over the years, and I have found the single best way to ensure that quality is a core area of focus, is to make that work visible and easily understood. We must do more than just make things faster; we must be able to explain what we did and what impact it had.
A couple of years ago, my first few days on a new web performance project were always slow going. […] In a bid to address this, I introduced a new tool into my arsenal so that I could hit the ground running much faster, and get answers to my clients much sooner.
Sadly, I think the current state of “modern” web development reverses that principle. Developer efficiency is prized above all else. Like I said, that would be absolutely fine if we’re talking about technologies that only developers are exposed to, but as soon as we’re talking about shipping those technologies over the network to end users, it’s negligent to continue to prioritise the developer experience.
In this post, I’ll discuss what I did at ALDO to measure the revenue impact of web performance without having to spend time making performance improvements.
Back in October, rendering performance was something we had never focused on. Nobody was really talking about it, so there must be nothing there. It was only after we started measuring that we saw the potential.
Performance improvements are a never-ending journey. The key is to strike the right balance. As noted above, we made significant progress on speed in 2019. But that is not the end of the story. Going forward, we have put a few things in place that will always keep us on the edge when it comes to performance.
A committee of Speed Champions
Synthetic monitoring to check budgets before each release
Setting performance budgets doesn’t need to be complex or confusing, you simply need some existing data, some monitoring, and to remember that budgets and targets are two different things. Don’t make life difficult by treating performance budgets as aspirations.
If you do find yourself in a position where your site’s initial rendering depends on a third-party script, refer to your mitigation plan to see what you can do to eliminate or ameliorate your dependence on it. Depending on a third party for core functionality is never a good position to be in, as you’re relinquishing a lot of control to others who might not have your best interests in mind.
The tools to make our websites fast and accessible are here but we’re not using them. And that’s what makes me mad […] it’s not just bad software design and development if a website is slow. Performance and accessibility aren’t features that can linger at the bottom of a Jira board to be considered later when it’s convenient.
"Third-party scripts are probably the #1 cause of poor performance and bad UX on the web. It's no wonder things like AMP exist. The fact that it disallows third-party scripts is probably the largest contributor to it making sites fast. Controversial as hell, though, in its other choices."
TL;DR: We are making changes to how AMP works in platforms such as Google Search that will enable linked pages to appear under publishers’ URLs instead of the google.com/amp URL space while maintaining the performance and privacy benefits of AMP Cache serving.