slowed the site down for some users, and demonstrated that poor perf would cost money • This helped get agreement from stakeholders, all the way up to the board that speed is important. • So able to avoid pitfalls such as ◦ Tag managers and other 3rd party nonsense ◦ “My thing absolutely must go on the front page” ◦ “The design uses this font-weight, and you will respect the design’s authority!” • There is no secret recipe - we’re just empowered to apply best practice and to say no when it matters
less important features • Initial page load only includes the most important things - content, navigation, minimal amount of styles • Use IntersectionObserver (thank you polyfill.io) to load images, comments, ads etc. as the user scrolls down the page later Bandwidth is not taken up by less important downloads, so the main content loads super fast ...so everyone’s happy?
load what is already a slow third party service… but it makes the site quicker • Yes, very interesting... so let's load them earlier. It’s what the users want How to respond to this? Stakeholder conversation:
baseline for the core features every user needs - being able to read a news story For secondary features identify which users care about them and personalise their experience accordingly … DATA is your friend again The answer - performance isn’t one size fits all
interacted with comments in the last month - passive comment user seen comments in the last month - everyone else fingers in their ears Data to identify the user’s cohort is stored in localstorage and used to decorate analytics Users in each cohort
possible after the dom finished loading. Step 3 - apply discretionary performance tweaks Big improvement for active users... Without penalising the bandwidth of unengaged users % of comment views loaded within 2s
prioritise performance, you may still be asked to implement “improvements” that harm performance overall • Explain what the trade-off is - you often can’t make a part faster without slowing down the whole - and try to say no to anything that will harm performance of your core product • Use data to ◦ put the demand for performance-harming features in perspective ◦ learn more about users who are perceiving performance to be slow • Personalise feature delivery based on what you learn about your users