Barry Pollard

Barry Pollard

@tunetheweb.com

Web Performance Developer Advocate at Google Chrome helping to make the web go faster! All opinions my own.

3K followers444 following1.5K posts

Barry Pollard reposted

Filtering thousands of items shouldn't freeze your UI ⏱️ When tasked with complex features, basic coding agents tend to miss performance opportunities. With Modern Web Guidance, agents find best practice guides on how to break up long tasks and yield control back to the browser → goo.gle/mwg

Barry Pollard reposted

Clicking a link in a single-page app doesn't trigger a full page load. That's why it's tricky to measure. Chrome DevTools now analyzes these soft navigations in Performance Insights, alongside Live Metrics and trace views → goo.gle/4i2xbRL

Barry Pollard reposted

Now you can render live, accessible HTML buttons inside a 3D scene without losing screen reader support 🤯 The HTML-in-Canvas API makes it possible! Natalia breaks down how to use the API to keep performance high and accessibility intact → goo.gle/4dV0Km1

goo.gleHTML-in-canvas: Where interactive content and high performance graphics meetEnjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

Barry Pollard reposted

Apropos of nothing, if you're considering switching from a recently deprecated browser and want to try Firefox, I just landed `Copy Tab URL` in nightly - it's not bound by default but a quick visit to `about:keyboard` will let you set it, and also take a glance at the other neat shortcuts we have.

Not so hot take: spam offering you a birthday gift (like a month free) on your actual birthday is not good marketing and just comes across as creepy that they know that… Then again probably my own fault for announcing my birthday on things like social media. 🎂 🤷‍♂️

Barry Pollard reposted

Barry Pollard reposted

Also new in today’s v1.136 update: iPad support! One of our most-requested features is finally here in beta. Try out the Bluesky app on your iPad, and if you see anything off, let us know under Settings > Beta features.

Barry Pollard reposted

This month it's "software factory". Four months ago it was "agent harnesses". Four months before that it was "loops" and "gastowns". Four months before that it was "agent skills". Four months before that it was "MCP". Four months before that... Ughck. Feeling nostalgic for 2010s JavaScript fatigue.

Barry Pollard reposted

Looking forward to sharing what we've seen work and where the challenges are. The real gold comes in the hallway conversations, comparing notes and brainstorming ideas. @perfnow.nl is the highest concentration of devs with web performance experience and interest you'll find.

With 2 years of rollouts, we've learned a lot about compression dictionaries and the Web. Patrick will cover what works, where the footguns are, how to maximize their effectiveness, and other experiments around compressing content on the web. @patmeenan.com at perfnow.nl

Barry Pollard reposted

Do minor #curl vulnerabilities in the open (Starting Monday October 26) https://daniel.haxx.se/blog/2026/10/20/do-minor-curl-vulnerabilities-in-the-open/

daniel.haxx.seDo minor curl vulnerabilities in the openThe curl project has decided to alter its vulnerability disclosure program procedure and starting _**October 26 2026**_ , we insist that all vulnerability reports submitted to us that are deemed to be severity LOW or MEDIUM should instead be submitted as issues in our GitHub repository. Only vulnerabilities deemed to be HIGH or CRITICAL will be kept private in the HackerOne tracker. Security researchers in doubt can still submit the issue on HackerOne and we can tell them what severity we deem it to be. Over the last few years, over 90% of all submissions could quickly be assessed to be less than HIGH. Issues submitted to HackerOne we deem are LOW or MEDIUM will be requested to be resubmitted on GitHub and will be closed as informative on HackerOne (and publicly disclosed). ## Avalanche survival tricks This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in. We see no end to them and we do not anticipate this flood to decrease within the next several months. We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster. We _must_ act to survive. This is our next step in a survival strategy. It might not be our last. We aim to not drown. ## Public vs private By opening up the process we allow the whole world to participate. Both in the assessment and understanding of the report and claimed vulnerability, but also in the creating and writing the advisory and figuring out details of when the issues was introduced etc. Ideally we get better help to make sure the fix is the correct one, that it fixes the problem, and any other related problem that is similar and that it does not miss a related problem sitting next to this. An obvious recent trend is that the moment we announce a new set of CVEs and their associated fixes, there is an army of AI-using researchers who throw all those at their models and harnesses to find similar mistakes or omissions in the fixes. By taking this process to the public all the way, ideally we get more help to do that scrutiny better _before_ we ship releases. We recognize that the amount of work needed per received vulnerability report does not shrink by doing them in public, but we think that we might share the burden among more people easier, and we hope that lessons and documentation brought up in these discussions will be easier to spot and learn from. ## The risks Several people have suggested there is a risk that researchers mistakenly submit severity HIGH issues on GitHub thinking they are LOW or MEDIUM. It is basically unheard of that a researcher would have _understated_ a reported problem so I consider that a low risk scenario. Also: there was already before this a risk that someone would submit a vulnerability report in the public, it is not a new risk. Handling some vulnerabilities in the public of course makes the immediately available for both good and bad people. This policy will give bad people a slightly longer window of opportunity to exploit weaknesses at the expense of existing curl users. That is unfortunate but we see no way of avoiding this. We limit this practice to less than HIGH for this reason: at least these problems are not terrible. ## Severity LOW We have discussed simply dismissing all severity LOW issues, but within the CVE program there is an appeals process and if we don’t hand out a CVE to an actual vulnerability, then someone else will do it. We thus cannot ignore true vulnerabilities, or they will come back to bite us nonetheless. We _can_ however resist and refuse silliness and I personally aim to deny and decline more vulnerabilities harder on the basis that they do not actually hurt any users or existing applications. ## Crazy combos A clear trend these days is that many newly reported vulnerabilities are figured out by AI models that create crazy sequences or option combinations that do something unexpected, but the sequence is something that aren’t likely to ever be used in the real world, or the unexpected that happens is something that occurs _every time_ so applications doing this would spot the problem immediately. I.e problems that have almost no risk to actually trigger in the real world. We save no users by insisting on doing the CVE dance for those issues. We only get work for ourselves and a whole world that has to act on them. ## Flow control it There is an almost infinite number of combinations you can use libcurl’s many options, protocol mixes and flexible API to do things that might not be clearly documented and the AIs will continue to try them all and together with the humans driving these checks they are super eager to treat every minor discrepancy as a vulnerability. We can’t continue down this spiraling path with our sanity intact. We don’t have the bandwidth, manpower or even will to handle a never-ending vulnerability reporting stream at this pace. I believe few software projects can stand this kind of prolonged high volume deluge for extended periods. Something needs to give way. ## How to assign severity We only use these for levels in the curl project: LOW, MEDIUM, HIGH and CRITICAL. Often we refer back to recently managed vulnerabilities to see how we judged them, but we also provide a set of basic guidelines. I’m sure we can also make them better and clearer.

Barry Pollard reposted

Things I hope to push forward at TPAC: - Declarative fragment / client side include - declarative skeleton/shell - CSS navigation matching - parser/patch reflection in mutation observers - responsive image improvements - connection allowlists - focusreset - CSS module imports Gonna be interesting!

Barry Pollard reposted

Tomorrow, October 16th, marks Practical Accessibility's third birthday. 🎂 To celebrate, I am gifting everybody 25% off for the next 48 hours 🎁 Individual and team licenses alike! The discount is automatically applied during checkout—no code is needed. 👉🏻 practical-accessibility.today Enjoy! #a11y

practical-accessibility.todayThe Practical Accessibility CourseA get-right-down-to-it online course for Web designers and developers who want to start creating more accessible Web user interfaces and digital products today

People do not open a page to read/interact with, and then close it cleanly. The modern web is more complex with pages backgrounded, often silently killed in the background (by the OS AND by users) or navigated away from before restoring by the bfcache by going back. Unload did not fire for those.

When a tab is hidden (and visibilitychange happens) you should take that as the last opportunity to reliably fire events (save state, fire analytics...etc) rather than assume unload will fire late (it often doesn't). APIs like fetchLater also help here. Let me know if you've any questions!

Great article. And it’s amazing how much both formats get out of a few kb. Honestly unless I zoomed in really, really close, and flicked back and forth I couldn’t really tell difference between low quality and the top one! 100kb is more than enough for most web images IMHO. And maybe even 30-50kb?

Jake Archibald@jakearchibald.com

JPEG XL has arrived on the web, but how does it stack up against AVIF? jakearchibald.com/2026/jpeg-xl...

Barry Pollard reposted

#PWA and #SPA site owners thought they were punished in #SEO by Google's #CoreWebVitals 😬 Google didn't sit still. They came up with a soft navigations (typical navigation on SPAs) API, and then also started collecting Core Web Vitals data using that API. Still experimental, but..

If only it were that simple...

Random MDN@random-mdn.bsky.social

🦖 LanguageModel: destroy() method 🦖 https://developer.mozilla.org/en-US/docs/Web/API/LanguageModel/destroy The destroy() method of the LanguageModel interface releases the resources assigned to the LanguageModel instance it is called on and stops any further activity on it. Any ongoing … #webdev

Barry Pollard reposted

The pitch for single page apps was always “it’s faster after the first load”. Google’s Core Web Vitals, used in search ranking, now measure soft navigations. It’s true: LCP drops by about a third. But, I don't think SPAs are ever really worth all the compromises and extra code.

Barry Pollard reposted

New: I pulled the Character ai bankruptcy documents. They show: - They were spending $14 million/month on compute alone at a time their revenue was around ~$1 million/month - Currently losing $9 million a month - They admitted they enshittified & that it didnt work www.404media.co/character-ai...

404media.coCharacter.ai's Bankruptcy Documents Show the Economics of AI Don't WorkCharacter.ai enshittified its product but was still burning tons of cash, its bankruptcy documents say.

Barry Pollard reposted

I'm super excited to announce that today we've added experimental versions of Core Web Vitals metrics including soft navigations to the Chrome User Experience Report! You can see them in BigQuery, the APIs, and CrUX Vis. Check it out! web.dev/blog/crux-ex...

web.devExperimental soft navigation metrics now available in CrUX  |  Blog  |  web.devLearn about the new experimental soft navigation metrics in CrUX and how they will impact your Core Web Vital metrics.