[Robin]: This week I read this great piece by Gareth Clubb about creating a culture of web performance at The Telegraph:
We knew web performance was crucial to the success of our new website but didn’t know how to introduce the topic into an organisation with more than 160 years of history and in excess of 1000 employees. We recognised that with millions of visits per month, performance improvements would be of huge value to our users.
We started slowly, fixing the immediate problems within our technical control: this brought good results but only accounted for 5% of the requests. We knew we would have to start working with the wider business to tackle the rest.
This measures up with what I’ve discovered joining a large company and what I faced several years ago when I started a similar project. At the beginning I believed that bad web performance was a technical issue where all you have to do to fix the issue is to sit in a room for a long time and delete/refactor everything until your website is lightning fast.
Well, spoilers: I couldn’t have been more wrong about that.
I believed that I could do it myself, too. I mean – I knew how to defer JavaScript, how to keep the CSS tiny, how to switch out big ol’ images for inline SVG where it made sense, and how to track progress over time. But after a month or so butting my head against a wall I realized I was tackling the issue from the wrong angle entirely.
I wanted to see progress overnight. I wanted to see kilobytes sliced off megabytes every day until the problem was resolved and our website was up to snuff. This impatience of mine to fix the problem stressed out a ton of my colleagues and overall made me less than helpful. Alternatively, Gareth makes note of how his team worked together:
Improving the performance impact of third-party scripts on a website takes time; results won’t come overnight, but by being patient and chipping away slowly, eventually these efforts will be rewarded.
After a month of working on improvements it dawned on me one morning whilst I was deleting CSS and optimizing images that web performance is a cultural problem, and not a technical one. No matter how good I was at tackling web performance issues, the problem was sure to return if not tomorrow then in a month or so. The analytics scripts would slip back in, more CSS would be written unnecessarily, more junk would pile up and up.
I learnt that if no-one in an org understands or values web performance work then the technical knowledge of how to optimize images or refactor CSS is pretty much irrelevant.
That’s why this post by Gareth is so important! It appears that his team understood that from the get-go – they knew that educating, measuring, and communicating the benefits of web performance to everyone at The Telegraph was more important than trying to play the hero by fixing everything in an evening.
And so I think this post underlines a few things I’ve been thinking a lot about in recent years when it comes to tackling a web performance project, or really any project now come to think of it:
- don’t try and be the hero
- over communicate why X is important
- measure the before and after of every project
- educate the whole org as to the benefits of X
Finally, and perhaps most importantly: be patient. Don’t fret if you can’t change the entire org over night. Just focus on making things 1% better every day and you’ll get there eventually, I promise.
? From the Blog
Near-daily occurrence: interact with a form on a mobile website, get disappointed that they didn’t do anything to help trigger a useful keyboard. There has been a variety of somewhat hacky ways to trigger the right keyboards on mobile over the years, but the real answer is inputmode, and Christian Oliff deeps dives into that.
Here’s how to iterate on a React Design System with Styled Components – but! – the neat thing about this post is how Cliff Hall walks through a realistic example of how technical debt occurs on a team and how to go about tackling it whilst building this nifty little web app:
I really like the way Cliff walks through these business decisions in this hypothetical example and how they can eventually lead to work for us as developers. But there’s also a ton of neat info in here about styled components, too.
We’ve gone and published a deep-dive into native lazy-loading for images and frames, where Erk Struwe excitedly writes:
If you read through other lazy-loading guides on this or other sites, you’ll see that we’ve had to resort to different tactics to make lazy-loading work. Well, that’s about to change when lazy-loading will be available natively in HTML as a new loading attribute… at least in Chrome which will hopefully lead to wider adoption. Chrome has already merged the code for native lazy-loading and is expected to ship it in Chrome 75, which is slated to release June 4, 2019.
This is all thoroughly exciting stuff! In the post Erk then dives into the history of lazy-loading and explains why this is going to be a boon for web performance and for us as developers.
Working with SVG is still one of my favorite parts of being a web developer but there’s a few tricky things about it, and one them is how to change their colors on hover. In this post by Chris, he shows that there are a few caveats depending on the approach you use to implement them on your website.
Inline SVG, SVG Symbol/Use, SVG as background images, masking, data URLs! There’s a lot to think about and it all really depends on the problems you’re trying to solve – make sure to bookmark this one because I’m sure it’ll come in handy soon enough.
Netlify
We want to thank Netlify both for sponsoring this newsletter and for providing a service that we love to use. If you missed it, Chris recently spun up a little static site on Netlify that displays past and upcoming front-end conferences. It’s hosted by Netlify. Its content is managed by NetlifyCMS. It can even share any event by email using Netlify functions.
Netlify can work for you, too! Try it now and deploy your site in seconds.
Check out our new Weekly News section on CSS-Tricks, published each Friday courtesy of Šime Vidas at Web Platform News.