The copy and paste version from earlier screenshot:
params=("utm_campaign" "utm_content" "utm_medium" "utm_source" "utm_id" "utm_term" "brid" "fbclid" "gclid" "wbraid" "gbraid" "gclsrc" "gad_campaign" "gad_campaignid" "gad_source" "msclkid" "epik" "pp")
4/4
Do note:
You would still want to add them to your local caching mechanisms! 💡
Let's make cache popular again! 🤓
Way longer description by @tunetheweb.com in last year's Web Performance Calendar edition:
calendar.perfplanet.com/2025/fixing-...
3/4
.. separate cache entries or duplicate URLs.
By telling browsers and CDNs to ignore them for caching, the same page can be reused instead of fetched again.
Result:
Cleaner caching, fewer unnecessary URL variants, and a slightly faster site without breaking analytics.
2/4
Yes, I know it's Friday… but I deployed this anyway! 😎
We added the No-Vary-Search response header to a bunch of sites to ignore tracking parameters like `utm_*`, `gclid`, and `fbclid`.
They’re consumed by third party tracking scripts, but they should not create ..
1/4
A fix is already here! That's fast 🚀
Thank you @webkitgtk.org Team!
Hopefully already there in next Safari release 🤓
bugs.webkit.org/show_bug.cgi...
Can imagine and I'm not even going to try it 😅
I'm afraid it will take up too much vertical space, and I typically need that for my DevTools 🤓
Links to bug reports:
🔗 bugs.webkit.org/show_bug.cgi... (with open pool request)
🔗 bugs.webkit.org/show_bug.cgi... (already resolved)
5/5
There's already good news too:
The WebKit team created a pull request (within barely 2 weeks) to address the inflated INP values for bfcache navigations 🎉
So, a fix should be shipped soon!
(and yes: it's nice and nerdy to know that we contributed to this 🤓)
4/5
But the pattern was very consistent across sites and datasets. Moreover:
1️⃣ Safari only recently started supporting INP
2️⃣ another edge case was reported before by @tunetheweb.com
So I ended up filing a WebKit bug report including:
→ screenshots
→ percentile charts
→ Chrome comparison data
3/5
So I segmented it per browser and saw:
→ Google Chrome: 53ms
→ Safari: 11013ms (207x higher)
And I'll admit: Before calling something a browser bug, I always assume the problem is on my side first 😅
So I double-checked the methodology, the segmentation, and the raw data.
2/5
With #CoreWebVitals data, we usually help agencies and merchants improve their sites and shops. But sometimes the data helps browsers too.
An example:
We recently spotted very inflated INP numbers across many sites on mobile (P75) specifically for `back-forward-cache` aka #BFcache navigations.
1/5
Nice, on my watch list for this evening! 🤓
After implementing Compression Dictionaries back in December, I sat down with @yoav.ws and @patmeenan.com to discuss getting the most out of them and provide some visuals for those new to the concept. Check out the video below:
youtu.be/YR2er3EiYnM / lessonsofacto.com/videos/032-c...
Will do, thanks!
Mainly looking for: is it a browser difference, or is there still something that I can influence here?
Background info: I already open the dialog before starting the VT to at least have visual/UX feedback instead of waiting for full VT.
Once opened, I start the VT.
Maybe for @webdevs.firefox.com or @jakearchibald.com.
Any idea why this VT for image zoom during gallery click is more shaky compared to what Chromium does?
terras.nogmeebezig.nl/geoceramica-...
And why btn-prev & next vt-names are flickering despite giving them a higher z-index than .gallery-img?
I did a lot of testing and even moved to `beforetoggle`.
But turns out that using but hiding `::scroll-marker-group` is the culprit:
bsky.app/profile/erwi...
Presence of <dialog> didn't play a role here.
I did additional testing and updated bug report:
When applying but hiding (via `display:none`) a `::scroll-marker-group`, the browser is likely to crash (likely, as initial rendering is fine and then crashes upon interaction)
Found it: `::scroll-marker` in `dialog` seemed to be the trigger here
bug report: issues.chromium.org/issues/47665...
markdown didn't go well, and I already filled in the summary/title before testing way more (and then actually finding it 👌)
But I can't seem to change the title myself anymore 😬
This seems to be my latest finding:
bsky.app/profile/erwi...
I'm going to fiddle a bit more by using different event listeners and will then file a report :)
Culprit seems to be too much DOM mutation within the dialog according to AI (scrollTo, IntersectionObserver is mentioned).
But even when commenting that out, it keeps crashing. So, something doesn't sit well with <dialog> on Chrome mobile 🤷
Ah, didn´t know it could be used for dialog, but probably won´t help.
It happens with and without commandfor and with and without view transitions:
terrasentrends.nl/file/upload/...
So it's <dialog> itself, but there probably is another factor here too 😭
Not that I know of. But I'm afraid this bug is more nuanced and is related to view transitions instead of dialog close.
Testing a bit more as I speak
This means I don't get to use natively available `<button commandfor="myDialog" command="close">..</button>` 🥲
MDN clearly states it's not canceable though:
developer.mozilla.org/en-US/docs/W...
Which is a shame, as I wanted a no-JS close button, but still do some additional view transition work
Using`preventDefault` within <dialog> close event causes mobile Chrome (but not Brave) to crash 😬
```
document.body.addEventListener('command', (e) => {
if (e.command === 'close') {
e.preventDefault();
}
},
{ capture: true }
)
```
(crashing on v143 & 144 @ Android 13 & 16)
ooh nice! Thanks for swift reply!
@una.im is something like this already possible?
`@container (scroll-state(scrolled: bottom)) and (scroll-state(stuck: top)) {`
Asking as I'm trying to animate sticky search bar along with a sticky header, to visually glue it to its bottom.
Header is already animated with `scrolled: bottom`
Vary interesting for sure! I suddenly got way more stuff to do + fix this Christmas holiday 😅
Yep, already seperated it 🤓
I was still a bit surprised though that even the selector syntax was not allowed at all and the whole rule was then discarded/ignored alltogether 😬
In my case I wanted to hide 2 things at the same time
- scroll buttons of my CSS slider
- or any nav of JS fallback slider
But only of the background slider when a dialog was opened, so mine looked more like this:
dialog[open] ~ .carousel ::scroll-button(*),
dialog[open] ~ .carousel .nav { .. }