30th October, 2025
Intro
What's been happening in web performance?
It has been a mixed year for me. I have been involved in a number of projects where web performance has been core, from full site builds to small analytics projects, although personally I feel that I have lacked time to really keep up-to-date.
One large project I have been involved in gave me the opportunity to help the client bake-in web performance, performance analytics and accessibility, setting some high standards from inception, which has been great.
Unfortunately most projects are not like that, a greenfield project is relatively rare, most of what we all do is try to improve long established sites with long established issues. So it has been great to work with a number of clients on how to approach web performance strategically, creating a measurement strategy upon which to build a performance roadmap.
It has obviously been a year where the rise of AI cannot be ignored, I have seen some interesting work being done to include AI agents into performance optimisation workflows. This could be a game-changer in introducing performance best practices to the wider developer community.
Casting out a bit further though, the question has to be asked, what will websites be for in the next 5 years? But one thing is for sure, AI agents will start to care about website quality and site speed, slow sites will be harder for them to pull content from (creating a worse downstream experience for the human users) and cost them more compute cycles.
On a personal level, I just wish I had more time through the year to get into the details of performance more, but life is busy, too much time running but that is another story!
The Conference
As ever, it is great to see some old friends and make some new ones. There are plenty of new faces, which is great, I know they will learn a lot.
The first two sessions are Tammy and Harry, who I have seen speak many times and they always deliver, but after that we have a number of speakers who are new to me who I am looking forward to hearing from, some great topics!s
My notes from previous years:
Image Credit: Henri Helvetica (thanks Henri!)
Our speaker roster for the two days:
- Tammy Everts Notes
- Harry Roberts Notes
- Marcy Sutton Todd Notes
- Michael Hladky Notes
- Ines Akrap Notes
- Umar Hansa Notes
- Ethan Gardner Notes
- Tim Kadlec Notes
- Andy Davies Notes
- Michal Mocny Notes
- Nadia Makarevich Notes
- Barry Pollard Notes
- Vinicius Dallacqua Notes
- Rich Harris Notes
Day 1
Our MCs for the two days are Tim Kadlec and Phil Hawksworth, Tim on day 1.
-
Tammy Everts - How Fast is Fast Enough?
Summary
A great topic to start with, how fast should your site be?
IMO, Core Web Vitals have almost become victim of their own success, passing Core Web Vitals is table stakes. They are a starting point. But we should be chasing the magic!
Any stats on the benefit of instant navigations? Maybe Barry will have some when talking about Speculation Rules.
Key Points
- Fast eliminates cognitive friction. Fast is magical.
- Fast should be pragmatic. Fast enough to improve business metrics.
- Ideal is where pragmatic and magical meet.
- Evidence shows that slower sites have lower conversion, but also lower returning visitor rate.
- There is no one size fits all for the correlation between speed and conversion.
- Google thresholds are not your thresholds.
- Metrcs do not map to feelings.
-
Harry Roberts - How to think like a performance engineer
Summary
Great talk as ever by Harry (who we all know is slightly shorter than Tim), and as ever brings a fresh perspective on things we should all already know, I think he does this better than almost anyone.
For me, the big message was that it is worth the effort to really spend the time setting up your tests correctly. Personally, I sometimes do this with cookie banners (test with them pre-closed by setting a cookie), but not often enough and I dont think I have ever pre-populated a basket. But I will now!
Key Points
- treo - great tool for visualising CrUX data.
- Webpagetest still the gold standard tool.
- Too often businesses do not have exact agreement on what metrics to use and exactly how they are defined.
- Core Web Vitals should be the metrics of choice, but there are also enabling metrics for example TTFB, Domcontentloaded for deferred JS execution(for SPAs)
- 75th percentile is not good enough, leaves to many people out, aim for 95th
- When testing a site, agree on URLs, device type, connection speed (usually not run fast enough) and geography
- Ignore lighthouse test numbers, they are not useful.
- Establish connection speed by running lots of tests with connection speed variations until you can align lab results with CrUX results.
- We over-focus on worst case scenario, for example cold start. Dont always disabled cache.
- Ensure you sometimes test with cookie banners pre-accepted
- Do things like use Webpagetest scripting to pre-populate baskets.
- Soft navigations need different tactics. Needs clicks, not navigations
- Knowing how to segment your data is key.
-
Marcy Sutton Todd - Accessibility and Performance
Summary
This is one of the talks I have been looking forward to most, the intersection of two areas I care about a lot.
A few key things to take back to the office is, I need to up my game with keyboard navigation, I usually just test whether elements can be navigated to with the keyboard but I dont think enough about ensuring a logical flow for keyboard navigation; I also dont consider whether there are any keyboard traps that cant be navigated out of. I dont test enough with zoomed in sites.
Marcy also mentioned that a good metric is the number of keystrokes to execute a task; I dont normally think about recording accessibile usage in analytics, it is generally considered bad form and also in many ways it sits at a lower level than the browser. However, I do wonder if there is merit in detecting keyboard navigation and recording it in GA4.
Key Points
- Acessibillity covers sensory, cognitive, physical disabilities and more.
- The intersection is how quickly it loads when you cant see it.
- Skeleton Loaders - you need to ensure that as content gets loaded in that the markup is high quality, but also ensure that before it is loaded that you user ARIA to announce that it is still loading or busy.
- Mobile traffic globally is 62.2%, so vital to be mobile centric.
- Devices should be usable in either mobile orientation, zoomable (handles reflow well) and more.
- Keystroke level performance- how many keystrokes does it take for an accessible user to carry out a task?
- Enure all functions are accessible by keyboard - so many websites miss this basic step. GitHub a good example of it done well. Also ensure there are no keyboard traps you cant get out of with the keyboard.
- You can measure the number of seconds until the page is ready for the screen reader to read.
- prefers-reduced-motion can and should be supported.
- The big gap is awareness and knowledge.
- Accessibility overlays are not the answer and can erode trust.
-
Michael Hladky - Big Data, Zero JS: virtual scrolling
Summary
How some lesser used CSS can improve performance.
Not the easiest talk to take notes on, as it was highly visual with a lot of live demos, which was very brave of Michael! But I would summarise it as "useful CSS properties which gives the browser contextual information about what might happen within a container and how changes should be limited to certain areas of the page. I definitely feel this is something I need to read up more on, I do not really understand the basics of it.
Key Points
- Useful tool to understand which CSS causes which rendering processes: CSS-Triggers
- Shared a useful snippet to trigger a controlled amount of zooming, for reproducing measurement of improvements.
- CSS Contains: is a really powerful powerful information for the browser to understand where impacts to the page should be contained within, instead of impacting the whole page. Layout and Paint have the biggest impact.
- content-visibility:auto very powerful for deferring work happening off-screen
-
Ines Akrap - Fast, Green, Responsible
Summary
Our planet is not infinite, we have resource constraints
There was a pretty extensive bridge analogy, but also some great perspectives on how to look at digital sustainability.
The big take home message is that we should all be reading W3C Web sustainability Guidelines
Key Points
- Ines is part of the W3C interest group on web sustainability.
- They have documented areas that have an impact (for example images) , how they create an impact and what you an do about it.
- Great to see Website Carbon Calculator and Ecograder mentioned
- It is also great to hear more about emissions from users (Scope 3), as I would say a lot of focus has been about optimising and reporting on origin and network carbon impacts.
- Brands should support dark mode, great for UX but also uses less energy on the browser.
- You could implement a grid-aware website which varies the UX based on current grid conditions and energy sources based on your location. Pretty cool!
- There is a move to add a legal framework around digital sustainability.
-
Umar Hansa - Modern Performance Workflows
Summary
A dev tools masterclass! Never heard Umar speak before, he really knows his stuff.
Personal note from me, I think I am not close enough to modern front end development practices to fully grasp all of what Umar was saying when it comes to some of the more advanced AI integrations with other tools, however it all sounded like gold and when the videos come out I will be sharing it with some developer colleagues.
Key Points
- Insights panel in performance, great route into the details in the flame chart
- Lighthouse Timespan reports. Great for capturing INP and other interactivity metrics.
- Use Recorder to record interactions and replay in performance panel.
- Network Throttling. You can now throttle by URL, not just site wide. Great for testing things like font loading.
- AI assistance, like Debug with AI context menu, in dev tools is worth looking at
- MCP tools within dev tools is very powerful
-
Ethan Gardner - Make Performance Allies
Summary
I have certainly been guilty of being a bit abrasive in the past about a lack of cooperation on web performance or some other best practices, and it has been to the detriment of inter-team harmony. It is a difficult situation, sometimes change is needed but you cannot force change through.
Change which fades is done to people, change which lasts is done with people.
Ethan has some great tips about ally building
Key Points
- Writing problem statements which is really speaks to the stakeholder
- In Ethan's example, he was able to remove some low value add providers, which didn't impact revenue but did improve performance.
- Looking for real world feedback, Reddit in Ethans example, has been a powerful tool.
- Ethan makes a great point about visually presenting data (graphs), make sure to call out the important points, you cant be too obvious.
- Creating (inter)team working agreements that codify the relationship between people and teams to avoid ambiguity can be a powerful tool. My take: ensure you don't approach this as a chance to set bear traps for people or teams. It should not feel like a noose.
- Dont be afraid to diagnose your own (and other team members) skillset. Be explicit and deliberate about your own soft skills development. You can start with a quiz/questionair to objectively understand yourself.
- Use team inclusive language. We not I.
- Reflect and Iterate
Day 1 Round Up
Well, that was exhausting! So much to take in, both from the presentations but also the conversations in the breaks. Particular shout out to Barry for the good chat and help around a question I had about web-vitals.js, I have been thinking about how best to zoom into the instrumentation of ultra-fast page loads, two topics I need to consider are the navigation types and delivery types.
Day 2
-
Tim Kadlec - Stubborn Empathy
Summary
Who better to start day 2 than Tim? Well, given these jokes, almost anyone...
We need stubborn empathy for users, their wants and their needs.
Key Points
- There is a monoculture. There has been a huge focus on Chrome due to their innovation in the space, they made tools and metrics available therefore we gravitated towards it.
- Core Web Vitals are great but again Chrome focused.
- Safari visibility is a major issue, and we don't test enough on it. And Safari behaves quite differently.
- Cross browser testing is an act of user advocacy
- AI code tools favours generation time over lifetime quality. 154% increase in PR size with AI tools, 9% increase in bugs per user.
- We are in danger of losing that empathy due to the rise of code generated by AI, it is abstracting the developer even further from the user.
-
Andy Davies - Lo-AF
Summary
Runtime costs are a hidden danger
This is something I have only looked at briefly and this is a major fail on my part! LoAF is a super powerful diagnostic tool.
Key Points
- How long does it take to present frame to the user. Gold standard is 50fps.
- Pages per session is a useful metric for comparing with site speed. Faster experiences encourage people to view more pages.
- LoAF data only available for visible pages/tabs
- Covers more events than INP, so things like scrolls and zooms.
- You can use LoAF can be used to estimate FPS.
- Attribution of LoAF is much better than Long Tasks.
- For example Next JS typically causes issues, and its easy to identify with LoAF
- INP can be thought of as time waiting for other tasks to complete before the event handler can start and then the time for the event handler itself.
-
Michael Mocny - Interactions and (soft) navigations
Summary
Key Points
- The line between MPA & SPAs is increasingly blurred, both can deliver great experiences and it doesn't need to be an either/or decision.
- Soft navigations will be added to the performance observer events
- INP includes the click out of the page, which could be slow due to things like unload event handlers.
- Soft LCP measured similar to hard navigation, and can include unload handling on the previous soft page.
- LCP for pre rendered pages (via speculation rules, for example) could look really high as the start time is at request but the LCP might not happen until the user actually navigates to that page.
-
Nadia Makarevich - React, Rendering & Performance
Summary
How do React Server Components affect performance
This one might be a bit over my head!
I am afraid the big takeaway message from me is that it is a lot of complexity to make React as performant as a server generated HTML page with progressively enhanced interactive features. The benefits of React for the developer never seem to manifest into benefits for users. Most sites are not highly interactive (think brand or ecommere sites, for example) and just do not benefit (the users) from the alleged strengths.
Key Points
- Starting with classic CSR React: LCP 4.1s, sidebar: 4.7s, messages 5.15s, or with caching LCP 800ms
- CSR is cheap, easy and transitions are nice
- Now SSR: much faster LCP but no interactivity for 2.5s
- It isnt necessarily straightforward to move to server components.
-
Barry Pollard - Speculations about Web Performance
Summary
Expectations are high and Barry delivered as usual.
Speculation Rules have been one of the best innovations from the past few years
Key Points
- Barry shared some of the greatest recent performane improvements such as lazy loading, which work well because they have been standardised, made easy and baked into the browsers.
- Speculation Rules have been around for almost 3 years, but they have been itterated on and improved over that time.
- Speculation Rules is meant for page loads, doesn't help SPAs
- There are risks using it, for example if you prerender pages with analytics, you will trigger a page view even if the user doesn't go to that page, although many of the anlytics platforms (GA4 included) have now put fixes in place.
- Speculation Rules have a lot of optimisations to limit the impact of excess load on the client
- You can send clear-site-data to tell the browser to clear any loaded pages
- A new change that will ake prerender safer: prerender until script. Available in origin trials in Jan and should be a game changer.
- When it comes to hover-triggered loading, there are some mobile heuristic optimisations coming to replicate hover.
- Yoav did some work to add it into Safari. Three Cheers!
- Barry gave a few examples sites using it, Rayban were called out.
- Two ways to make your site faster, either make it faster or cheat!
-
Vinicius Dallacqua
Summary
Transforming verbose performance data into insights is a tough job.
Some of this was over my head, but really powerful demo with the agent generating optimised code, not just identifying the issue.
Key Points
- Interesting take, to get a specialist agent which understands web performance data to train an agent which can help with code
- Dev tools gets easier and more powerful all the time
- Performance data sets are difficult to work with, for humans and LLMs
- MoE routing for working out the best way to analyse the problem
- using MCP to connect agents with specialised performance insights
- Great example of the agent then generating an optimised file and have it demoed in the browser.
-
Rich Harris - Fine Grained Everything
Summary
Rich works on Svelte, and is here to demonstrate how it is a better way and how to approach performance. So far I am impressed. It was a demo-heavy talk, so not easy to describe in bullet points.
Key Points
- There are too many conventions that you need to know for how React handles server vs. client components.
- Svelte instantly looks more rational that what I have seen of React
- I like the inclusion of ARIA in form handling.
- I also like the fact that a lot of the functionality seems to be progressively enhanced and will fall back to being usable without JS.
Round Up
