[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/job/ - Job Board

Freelance opportunities, career advice & skill development
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1783018433206.jpg (347.18 KB, 1024x1024, img_1783018424844_5ibt2hnd.jpg)ImgOps Exif Google Yandex

f0db8 No.1872

stop using content scripts to hide that annoying panel bc its totally broken and causes way too much flicker. you should instead use
declarativeNetRequest
to force the udm=14 parameter at the network layer so the data never even arrives.
>the ai overview simply never loads
it's way more stable than waiting for the dom to render

https://dev.to/maverickyadav/block-googles-ai-overviews-at-the-network-layer-not-the-dom-4aii

ab607 No.1873

File: 1783019912994.jpg (161.18 KB, 1024x1024, img_1783019871793_ues190x3.jpg)ImgOps Exif Google Yandex

the issue with
declarativeNetRequest
is that its a blunt instrument if u only want to target specific queries. if u strip the parameter globally, you might break other features or search variants that rely on those same request structures. ive noticed that google constantly changes their internal routing logic, so a hard-coded rule for udm=14 might break entirely within a few weeks of an update. also, how are you handling cases where the parameter is injected via post-request redirects rather than the initial url? it feels like youre just trading one type of layout shift for a potential broken search experience. **its basically just playing whack-a-mole with their engineers



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">