Coder Legion - Recent posts tagged chrome

Bridging Model Context Protocol (MCP) to Browser Agents via W3C WebMCP (document.modelContext)

Fri, 23 Oct 2026 16:11:38 +0000

As AI agents move from local developer runtimes (like Claude Desktop and Cursor) into browser environments, developers face a major integration challenge: how to expose structured backend tools to client-side agents securely and without fragile DOM scraping.

At SEOSiri, we solved this by implementing the W3C WebMCP specification (document.modelContext). Our central developer portal dynamically registers our entire autonomous tool catalog on boot, proxying execution requests seamlessly through secure, stateless Cloudflare Edge Gateways.

Key Technical Implementation Highlights:

Dynamic Universal Registry: Automatically loops through master component registers to bind server schemas into browser runtimes.
Edge Proxying & Security: Ensures zero secret exposure by keeping backend encryption keys locked inside Cloudflare Worker environment variables while marshaling public JSON-RPC requests across HTTPS.
Namespace Segregation: Explicitly namespaced tool identifiers prevent collision with browser default diagnostic suites.
Native DevTools Debugging: Streamlines inspection and verification via the Chrome DevTools WebMCP application panel.

Read the Full Engineering Walkthrough:
🔗 https://www.seosiri.com/2026/10/webmcp-chrome-mcp-tools-guide.html

coderlegion #webdev #aiagents #mcp #typescript #architecture #edgecomputing

Shipped: the FSCSS Browser IDE

Tue, 20 Oct 2026 11:57:23 +0000

Multi-file FSCSS in the browser — compile, preview, enable packages, export plain CSS.

No install required. Open fscss.devtem.org/ide and work.

What it is

The FSCSS IDE is a single-page workspace for Figured Shorthand CSS: write .fscss, compile to standard CSS, preview HTML, and pull community modules without leaving the tab.

It targets the same language as the CLI and CDN runtime (fscss@1.2.6+). Prototypes stay in the browser; production still ships compiled CSS.

Layout (quick map)

Area	Role
Top bar	Run, Preview, Auto-compile, Export, Import, theme, settings
Left	Files, Components, Snippets, Tools
Center	Monaco editor + file tabs
Right	Compiled CSS / live Preview
Bottom	Terminal + Problems
Status	Compiler version, errors, cursor

Drag the dividers. On phones the sidebar overlays and panes stack.

Quick start

Open or create main.fscss.
Ctrl+Enter — compile (CSS on the right).
Ctrl+Shift+Enter — compile and open preview.
Export — CSS, minified CSS, HTML, ZIP, or JSON backup.

Autosave uses localStorage (keys under fside:). Export a backup if the browser blocks storage.

Multi-file and `@import`

The workspace is a virtual file system. Local imports resolve against the importing file:

@import((widget-root, widget-card) from "./widgets.fscss")
@import((*) from st-core@v2)
@import((mirror, stagger) from fscss:micros)

Selective names, aliases (as), wildcards, and registry-style names work the same way as in the CLI. Remote URLs need quotes; listed library names usually do not.

Packages: `libck` / `libon` / xfcmd

Open the terminal (Ctrl+`):

libck st-core
yes

Or a full repo:

libck https://github.com/fscss-ttr/overlapui.fscss
yes

The IDE loads package.json, checks fscss_version, downloads file.modules, verifies @define helpers, then runs the pack’s enable script when you confirm. Typical enable flow:

snippets for public helpers
a small demo folder
compile + preview

liboff st-core
xfcmd list

Disable removes snippets; demo files stay unless you delete them. Authoring side: xfcmds guide · modules guide.

What else is built in

Monaco — FSCSS highlighting, folding, snippets
Component search — registry helpers, one-click import
Compiler version — load another fscss@x.y.z from jsDelivr
Auto-compile while typing (toggle)
PWA-style install chrome on supported browsers
Console — window.xfscss for ad-hoc API checks

Docs: IDE guide.

Example: three lines → many classes

@arr classes[ count(1000, 1) ]
*Emails are not allowed*ses[] {
  margin: @arr.classes[]px;
}

Compile in the IDE and scroll the CSS pane — or open a prefilled buffer:

Open in IDE

Example: enable a pack

libck st-core
yes

Then in a new .fscss file (or the generated demo):

@import((*) from st-core@v2)
@st-root()
@arr data[42, 58, 65, 60, 78, 70, 92]
@st-chart-fill(.fill, data)
@st-chart-line(.line, data)
.chart {
  @st-chart-points(data)
  position: relative;
  height: 220px;
}

HTML: a .chart with .fill and .line children. Preview updates after compile. Same contract as the st-core templates: JS only patches --st-pN when data changes.

Ship path

Stage	Tool
Learn / combine modules	IDE + runtime CDN
Real multi-file project	IDE export ZIP or clone + CLI
Production	`fscss in.fscss out.css` — no browser compiler on the live site

npm install -g fscss@1.2.6
fscss src/site.fscss dist/site.css

The IDE is meant to lower the cost of trying FSCSS: multi-file imports, package enable in one terminal prompt, and a clear export to plain CSS. It does not replace the CLI for production builds—it shortens the path until you need one.

Open it, hit Ctrl+Enter, and if a pack has an enable script, libon is enough to see a demo.

Vue.js Web Browser Extension Template

Sun, 04 Oct 2026 18:51:54 +0000

Starting out with browser extensions can often be a pain in the back.

A while back, I was looking for a template I could use to build Epubespiar. Most of the ones I tried had the same problem: I couldn’t get them started and running. Since this was my first time building an extension, that was really frustrating.

The instructions would say something like: clone the project, pnpm install, then pnpm run dev. After that, Chrome would suddenly open and... voilà. A blank tab, staring at you as if asking, "what are you doing, bruv?" And if you didn't have Chrome installed and wanted to check the template UI in Firefox, hell broke loose. :P

So you'd end up back in a 500+ line codebase, trying to figure out what was actually breaking and that can be demoralizing, yeah. Imagine signing up to a social platform and, on first impression... not being able to create posts or publish content the way you would on other apps. Sucks, right?

After a few trials, I decided to build Epubespiar from the ground up with Vue.js. Since then, life has been good.

Recently, that experience stuck with me, so I built a browser extension template to help developers get their extensions up much quicker.

All you need is the repo in your dev environment, then:

pnpm install thereafter, pnpm run dev:all

What you see next should feel familiar, and if you're a web developer, it's even easier, because it follows the same flow you already use day to day. The UI runs on localhost which you can open in any browser, be it Chromium-based or Gecko/Firefox for testing.

Try it here: https://github.com/rezzcode/vuejs-extensions.git and tell me what you think.

Put Chrome Stable on the same calendar as your deploys

Wed, 23 Sep 2026 06:28:19 +0000

When field LCP moves and the app calendar is empty, the missing row is usually Chrome Stable, not a ghost commit.

Field Largest Contentful Paint can move while your application release calendar stays empty. The spreadsheet already lists app deploys, CDN config changes, tag-manager publishes, and RUM or instrumentation bumps. From Chrome 153 Stable on 8 September 2026, Chrome ships a new Stable (and Beta) every two weeks on Desktop, Android, and iOS. Leave Chrome Stable off that same sheet and you will keep blaming ghost commits for shifts that are only population mix.

The ritual fix is dull on purpose: browser Stable and Beta sit next to the changes you already annotate, one named owner writes the date before the graph moves, and the monthly pack stops inventing regressions. CrUX math and sample thresholds live on our Watcher how-to. Ownership of the calendar is the piece that makes those reports honest.

Why Chrome Stable belongs beside deploys

Chrome User Experience Report field data is a rolling blend of real Chrome sessions, not a snapshot of yesterday’s build. When a new Stable major enters that mix, paint timing, decoding, lazy-load heuristics, or interaction scheduling can shift for the same URL while your HTML and bundles stay byte-identical. Faster Stable cadence simply raises how often that mix changes inside one reporting window.

Google’s two-week release announcement is the schedule source. From Chrome 153, Beta and Stable promote every two weeks; Extended Stable keeps its eight-week enterprise cycle. Firefox has been running a similar fortnightly experiment around the same period. Agencies that only annotated application cuts in 2025 now need browser rows in 2026, or every Stable Tuesday becomes an unexplained ticket.

Harry Roberts put the measurement framing cleanly in Web-Perf Wednesday 006: faster browser releases change the RUM population you are averaging. The agency failure mode is narrower than the measurement essay. Teams open a regression hunt because the shared calendar never recorded that Chrome moved.

What belongs on one shared release calendar

One calendar per client portfolio beats five tools that never meet. Useful rows are the changes that can move field percentiles, or look like they did. Share those rows on one sheet and a quiet week has a readable explanation instead of five disconnected notification emails.

Change type	What to record	Why it belongs
Application deploy	Environment, git SHA or release tag, money URLs touched	Origin change you control
CDN / cache / edge	Config version, purge scope, rule ID	Delivery change without an app tag
Tag manager / third-party	Container version, publish time	Main-thread and LCP side effects
RUM / instrumentation	Library version, sampling or route rules	Collection change that looks like a metric shift
Chrome Stable / Beta	Milestone, channel, scheduled date	Browser population entering field windows
Firefox Stable / Beta	Milestone, channel, scheduled date	Same population logic for Firefox-heavy audiences
Extended Stable (if relevant)	Cohort lag vs consumer Stable	Enterprise mix that updates on a different clock

The browser date is an annotation, not a claim that every visitor updated at once. First-party RUM helps here: version share beside that marker shows how fast the cohort actually moved. Dates belong on the sheet the same week you plan app cuts (from Chrome Status, Chromium dashboards, and the Firefox release calendar), not after a client asks why LCP went amber.

Beta still earns a row. Chrome ships a Beta about three weeks before Stable, so there is time to check real journeys, metric completion, soft-navigation detection, and browser-specific dimensions. That is a routine rehearsal, not a late smoke test the day before Stable.

Name an owner before the graph moves

Annotations without an owner die in the same week they are invented. The workable pattern is one named person (or rotating role) who adds Chrome and Firefox Stable and Beta dates before field charts update. In most retainers that is the technical lead who already owns the monthly Core Web Vitals pack, not “whoever notices Slack first.”

A workable weekly habit looks like this. On Monday, skim the next two Stable dates and paste them onto the shared calendar. After any app, CDN, tag, or RUM change, add that row the same day. When field LCP, INP, or CLS moves, the calendar opens before the bug tracker: if a browser milestone sits inside the collection window and the origin rows are quiet, population mix is the first question, not a phantom deploy.

Waiting until the percentile has already moved is too late. With a major every fortnight, “we will annotate when something looks weird” means the annotation arrives after the client argument has started. The calendar is useful when the date was already written the moment someone first noticed the amber band.

When field LCP shifts with no deploy: check population mix first

Run a short triage before you escalate:

Confirm the app, CDN, tag-manager, and instrumentation rows for the collection window are empty (or explain the ones that are not).
Check whether a Chrome or Firefox Stable (or Extended Stable lag) sits inside the same dates.
Look at version share and sample size before trusting a single-major p75 slice.
Keep an unsegmented field series as the executive headline; use browser-major slices as engineer appendix material.
Pair with a scheduled lab run on the same money URLs so you can say the origin critical path did not move this week.

Population mix means the aggregate changed because the audience composition changed: more sessions on a new Stable, fewer on the previous major, or a campaign that shifted which templates dominate. Site regression is narrower. The same browser version and a similar journey got worse after a change you control. Confusing the two burns engineering time and weakens the next real alert.

For the full field-window and sample-threshold treatment, When LCP Moves and Nobody Deployed: Browser Release Cadence and Your 28-Day Field Window owns the CrUX clocks and reporting templates. The job here is smaller. Put Chrome on the sheet before anyone argues about a ghost commit.

Browser release cadence versus CrUX pipeline lag

Two different delays get conflated in client calls. Pipeline lag is when a verified fix (or a real regression) takes time to appear in published CrUX / PageSpeed Insights field sections because collection and processing are not instant. Browser cadence inside the window is different: the rolling 28-day mix already includes more than one Stable major, so the percentile can move with no origin change at all.

“We shipped Friday and field still looks old” points at CrUX pipeline delays and late field data in client reports. “Nobody deployed and LCP still moved” points at the shared calendar and population mix. Lab green beside field amber is a third conversation, so folding all three into one vague “CrUX is slow” answer helps nobody.

Scheduled monitoring still helps. Same-week lab evidence on money URLs, portfolio alerts on your thresholds, and dated annotations clients can read without a statistics lecture make the calendar useful in the monthly pack. Watcher layers onto that workflow. It does not replace the release calendar you already maintain.

FAQ

Does every Chrome Stable need a client email?
No. Most Stable dates are quiet annotations on the internal sheet. Client email makes sense when field bands move and the calendar shows a browser milestone with no origin change, or when sample counts are large enough that a major-specific shift is worth explaining in the monthly pack.

What if we only have CrUX, not first-party RUM?
Stable and Beta still belong on the calendar. Without version share charts you cannot prove mix as tightly, so the honest pack leans on unsegmented field series, lab pairing, and careful wording (“browser release inside the collection window” rather than “Chrome 153 caused this”).

Should we slice every report by Chrome major?
Only when sample counts support it. Thin major slices manufacture weekly false regressions that look decisive in a slide and evaporate under scrutiny. Unsegmented headlines stay safer for leadership; major splits belong in engineering follow-up.

Where do Extended Stable clients fit?
On their own calendar row. They can lag consumer Stable for weeks, so a retail audience and a locked-down corporate audience on the same template can read different field bands with no deploy on either side. That lag is expected; it is not an unexplained regression until the calendar says otherwise.

Put the browser on the sheet this week

The release calendar you already use for deploys is enough. Chrome Stable and Beta for the next month go on it now, Firefox too if that traffic matters, and the owner’s name sits at the top of the tab. Next time field LCP moves on a quiet week, you have a dated answer instead of a fictional commit. After the ritual sticks, the Watcher guides linked above carry the deeper reporting playbook; when the same annotations need to span a multi-client portfolio, start a Watcher trial.

References

Get features faster with Chrome's two-week release cycle (Chrome for Developers)
Web-Perf Wednesday 006 – Faster Browser Releases Change Your RUM Population (CSS Wizardry)
When LCP Moves and Nobody Deployed: Browser Release Cadence and Your 28-Day Field Window (Apogee Watcher)
CrUX pipeline delays and late field data in client reports (Apogee Watcher)
Chrome Status roadmap (Chrome)

Originally published on Hashnode.

Keep Search Clean: Block Search Engine Spam with uBlacklist and Community Rule Sets

Sun, 20 Sep 2026 14:31:02 +0000

If you use Google, DuckDuckGo, or Bing regularly, you have likely run into programmatic search spam: auto-generated "doorway" pages, scraper blogs stealing content, DGA (Domain Generation Algorithm) random domain networks, and affiliate redirects. They waste time, clutter search results, and occasionally host malicious scripts or phishing landers.

While reporting these domains to registrars and search engines helps clean up the web for everyone, you can instantly eliminate them from your personal local browsing experience using uBlacklist.

What Problem Does uBlacklist Solve?

uBlacklist is a lightweight browser extension that filters specified sites from appearing in your search engine results.

Instead of landing on low-quality scraper sites or clickbait doorway networks:

Hides Spam Results: Blacklisted domains are automatically stripped or dimmed out directly in your search results.
Multi-Search Engine Support: Works seamlessly across Google, Bing, DuckDuckGo, Ecosia, Startpage, and more.
Community Rule Subscriptions: Instead of manually blocking sites one by one, you can subscribe to crowdsourced community blocklists that sync automatically in the background.

Step 1: How to Install uBlacklist on Chrome

Installing the extension takes less than a minute:

Open Google Chrome.
Visit the uBlacklist page on the Chrome Web Store.
Click Add to Chrome and confirm by clicking Add extension.
(Optional) Click the puzzle piece icon (Extensions) in your top-right toolbar and pin uBlacklist for easy access.

Step 2: Recommended Community Rule Sets

To get maximum protection without needing to build your own list from scratch, subscribe to curated community rule sets listed on the uBlacklist Rule Sets Directory.

I specifically recommend enabling these three subscriptions to target common web spam patterns:

Spam: Ad and tracking server domain list
- Purpose: Blocks domain networks known for aggressive popups, tracking traps, and ad-heavy doorway pages.
Spam: DGA & Random Subdomain Spam Blocklist
- Purpose: Targets programmatically generated, short-lived domains (e.g., random character strings like lwhiswfnuuiu.gay or ohgssoigkcik.icu) frequently used by automated web spam rings.
Copycat Sites: uBlock-Origin-dev-filter
- Purpose: Shields developers from scraper sites that duplicate StackOverflow, GitHub, and technical documentation with low-quality, ad-stuffed overlays.

Step 3: How to Add Recommended Rule Sets to Your Extension

Before subscribing directly from the community directory, enable subscriptions in your local extension settings:

Enable Subscriptions:
- Click the Extensions icon (puzzle piece) in your Chrome toolbar.
- Find uBlacklist, click the three dots ("..."), and select Options.
- Scroll down to the Subscriptions section and make sure the Enable subscriptions toggle is switched ON (Enabled).
Subscribe from the Community Directory:
- Visit the uBlacklist Rule Sets Directory.
- Locate the recommended rule sets:
  - Spam: Ad and tracking server domain list
  - Spam: DGA & Random Subdomain Spam Blocklist
  - Copycat Sites: uBlock-Origin-dev-filter
- Click the "+" (Subscribe) button next to each rule set.
Confirm:
- uBlacklist will prompt you to confirm—click Subscribe (or Add) to finish adding the list.

Step 4: How to Verify It’s Working

To ensure your rule sets are active and working as expected:

Check Subscription Status:
- Click the Extensions icon (puzzle piece) in your Chrome toolbar.
- Locate uBlacklist in the list, click the three dots ("...") next to it, and select Options.
- Scroll down to the Subscriptions section.
- You should see a status or timestamp showing "Updated [time]" alongside the total count of loaded rules/patterns for each subscribed list.
- You can click Update now to manually trigger an initial sync.
Test in Search Results:
- Perform a search query on Google or DuckDuckGo.
- If a domain matching your blocklists appears in the raw index, uBlacklist will intercept it.
- Look at the bottom or top of your search results page—you will see a subtle indicator stating: "uBlacklist has blocked N site(s)". Click it to view or temporarily unhide blocked results.

By pairing direct reporting with local client-side filtering like uBlacklist, you get an immediate, pristine search experience free from automated spam networks.

From HTML to Legal Automation: Dhardingsea Developer’s Journey of Building Software That Solves Real

Sun, 13 Sep 2026 08:19:22 +0000

A CoderLegion Developer Story featuring Dhardingsea Developer

Interviewed and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion

Some developers follow a straight path.

Others follow problems.

For Dhardingsea Developer, programming started with computers, HTML, and web development. From there, the journey moved through computer repair, malware removal, Chrome extensions, Windows tools, games, production automation, and AI tooling.

Today, that work spans very different kinds of software — from browser games to automation for the legal-process-serving industry.

At first, those projects might seem unrelated.

But there is a common thread:

Finding ways to use computers to mend, improve, and simplify things encountered in real life.

That approach has also shaped a particular engineering philosophy: build locally when possible, respect user privacy, minimize unnecessary permissions, listen to users, and encode knowledge into software so it doesn't disappear when people do.

It Started With Computers

As a child, computers were something Dhardingsea Developer naturally connected with.

They were understandable.

They were something that could be explored.

The first real attraction was HTML and web development.

That eventually expanded into computer repair and malware removal, giving them exposure to computers from a different perspective.

Programming wasn't isolated from the rest of technology.

It was connected to understanding how computers worked, what could go wrong, and how problems could be fixed.

That practical experience became an important foundation for everything that came later.

Turning Real-Life Problems Into Software

One of the defining characteristics of the journey has been finding ways to use computers to improve things encountered in everyday life.

With a background spanning marketing and web development, combined with experience working at a small computer company, Dhardingsea Developer gradually developed a broad understanding of technology.

Instead of focusing on a single category of software, they kept finding different problems that could potentially be solved with computers.

That led to a wide range of projects:

Chrome extensions
Windows desktop tools
Browser games
Production automation
AI tooling
Developer tools

The technologies may be different.

The underlying approach isn't.

Find something that could work better.

Understand the problem.

Build something.

Then learn from what happens.

When Software Has Real-World Consequences

One of the biggest differences between Dhardingsea Developer's personal projects and professional work is the environment in which the software operates.

Their work in the legal-process-serving industry comes with consequences that a game or experimental project simply doesn't have.

A small mistake can have significant financial consequences.

"An error, a small click of a button can send duplication of filing fees and a loss of thousands."

That changes the engineering process.

In a creative project, you can experiment and recover from mistakes relatively easily.

In legal-process software, the consequences of a mistake can affect real documents, filings, fees, and workflows.

As a result, simulation and review become extremely important.

Before launching something, it is necessary to think through what could happen.

And even after launch, there is another challenge:

maintenance.

Software doesn't simply need to work once.

It needs to continue working as the surrounding environment changes.

For Dhardingsea Developer, this is very different from building a game or creative project.

"The purpose is function; the other is function of purpose."

The distinction is important.

One environment demands correctness and reliability.

The other gives more room for experimentation and creative expression.

Both teach valuable lessons.

Encoding Institutional Knowledge Into Software

One of the most interesting ideas in Dhardingsea Developer's profile is the concept of encoding institutional knowledge into software.

What does that actually mean?

It starts with understanding how people solve problems.

Someone who has spent years working in a particular environment develops knowledge that may never be written down.

They know how to untangle a problem.

They know what tends to go wrong.

They know what to check before something breaks.

They know why a particular decision was made.

That knowledge can disappear when the person leaves.

Software can preserve some of it.

For Dhardingsea Developer, comments, telemetry, documentation, and implementation details can capture not only what the software does, but why it does it.

"I find it valuable to put the why for someone to have the opportunity to learn even if it's to change."

That last part is important.

Documentation isn't necessarily about making decisions permanent.

It is about making the reasoning visible so that someone else can understand it, question it, and improve it.

The Chromium Autofiler That Started Something Bigger

One of the projects that taught Dhardingsea Developer the most was Chromium Autofiler.

It was one of their early projects, but its impact went beyond the project itself.

Working on it introduced them to areas such as:

Database storage
Encryption
Browser tooling
Software architecture
Building their own website
Creating games
Working with different tools

The project became a starting point.

Not necessarily because it was the most successful thing they built, but because it opened the door to everything that came afterward.

Sometimes an early project matters because of what it teaches you rather than what it becomes.

Learning the Hard Way With a Chrome Extension

One of the more recent projects was a local-first Dota 2 companion built as a Chrome extension.

Dota 2 provides an API for gathering information, while also having a large social gaming community.

The project forced Dhardingsea Developer to think carefully about something that is easy to overlook:

The user doesn't necessarily understand the technical limitations behind the software.

A user may not know about API rate limits.

They may simply expect the software to work.

That creates an interesting responsibility for developers.

Should software automatically impose restrictions on behalf of users?

Should it assume that users don't understand the consequences?

Or should it allow the system to behave according to the capabilities available?

Dhardingsea Developer describes this tension candidly.

"Imposing a limit on a user's behalf for safety is a weird call, who am I to be so arrogant?"

The experience ultimately reinforced another lesson:

Consider the user's needs before they become problems.

Building a tool isn't only about making the technology work.

It is about understanding how people will actually use it.

Shipping Something Before It's Perfect

Another lesson that has become important to Dhardingsea Developer is knowing when to ship.

Developers can spend months working toward an idea.

During that time, motivation can disappear.

Budgets can change.

Opinions can change.

The original idea itself can change.

And sometimes the only people who can tell you whether the software is useful are the people actually using it.

That changed the way Dhardingsea Developer thinks about incomplete software.

"The user will say, the user will know."

Instead of waiting for every feature to be perfect, shipping something allows users to provide feedback.

That feedback can become part of the development process.

An incomplete product can sometimes teach you more than a perfect product that nobody has seen.

"It's easier to ship something incomplete, you can find so much more feedback from users looking to help play a role."

For Dhardingsea Developer, shipping isn't necessarily the end of development.

It's the beginning of another feedback loop.

Privacy Is a Requirement, Not a Feature

A strong theme across the projects is privacy.

Dhardingsea Developer's approach emphasizes local-first software, minimal permissions, and avoiding unnecessary accounts or telemetry.

The reasoning is simple.

Users are becoming increasingly tired of giving away their data.

They don't necessarily want their history, behavior, or personal information collected simply because they use a piece of software.

And with AI becoming more deeply integrated into technology, that concern becomes even more important.

"It's important to me to hold user security as a priority."

The goal isn't to build a system around advertising or tracking clicks.

It's to build software for people.

That means treating the user as something more important than a source of telemetry.

The Shortcut They Refuse to Take

Every developer has shortcuts they are willing to take.

And every developer has some shortcuts they refuse to take.

For Dhardingsea Developer, one of those is cross-analysis and continuous learning.

Their current workflow involves sending files between different character accounts to review information from different perspectives.

The data can then go through a kind of "levelup" process designed to identify gaps in skills or processes and make improvements.

It consumes time.

It consumes processing power.

It would be much easier to simply accept the current state.

But Dhardingsea Developer considers the process non-negotiable.

"We must learn."

That philosophy fits closely with their broader approach to software.

The system isn't supposed to simply produce an answer.

It should help identify weaknesses and improve over time.

The Lesson They Wish They Learned Earlier

Sometimes the biggest lessons aren't architectural.

Sometimes they're surprisingly small.

For Dhardingsea Developer, one of those lessons is:

Spelling really matters.

A random .

An unexpected capital letter.

A small typo.

Something that looks insignificant can become the reason you spend time debugging something that should have worked.

"Debugging is an endless task at times."

Looking back, they wish they had paid more attention to spelling much earlier.

It's a humorous lesson, but also a very real one.

Computers don't care what you meant.

They care what you actually wrote.

Learning Databases for the Next Stage

Looking ahead, one of the areas Dhardingsea Developer wants to explore more deeply is databases and structured data.

They describe having relatively little experience in this area and increasingly feeling that it is limiting what they can build.

In particular, it becomes important when thinking about MMO-style games.

Games with persistent worlds require more than interfaces and mechanics.

They require systems capable of storing, retrieving, updating, and organizing large amounts of structured information.

For Dhardingsea Developer, learning more about databases is therefore not simply about learning another technology.

It's about removing a limitation on what they can build next.

The Advice: Have Fun

For developers who feel stuck or believe they aren't progressing quickly enough, Dhardingsea Developer doesn't recommend obsessing over speed.

The advice is much simpler:

"Have fun."

Joy is an important part of learning.

If you're struggling, that doesn't necessarily mean you're failing.

It can mean you're already doing something valuable.

You're learning something difficult.

You're pushing against the limits of what you currently understand.

"If you are struggling, that means you are already succeeding."

The important thing is to keep the curiosity alive.

Learn something new.

Try a different approach.

Even if the new approach is simply a different way of doing something as basic as 2 + 2.

The point isn't always immediate productivity.

Sometimes the point is discovering another way to think.

You Can Succeed at Anything — If You Luck Out Hard Enough

There is one line on Dhardingsea Developer's profile that stands out:

"You can succeed at anything, if you just luck out hard enough."

The phrase comes from Futurama.

But for Dhardingsea Developer, it also carries a deeper meaning.

Success isn't entirely controlled by effort.

There is timing.

There is circumstance.

There is being in the right place at the right moment.

There are things outside our control.

But that doesn't mean effort is meaningless.

Instead, the idea is to keep putting yourself in situations where luck has a chance to find you.

As they put it:

"I'm just a guy, but maybe with some effort we can luck out hard enough haha."

It's a surprisingly fitting conclusion to this journey.

Building Through Curiosity

Looking at Dhardingsea Developer's journey, the projects may initially seem scattered.

Chrome extensions.

Games.

Windows tools.

Legal automation.

AI tooling.

Databases.

Browser APIs.

But there is a common thread.

Curiosity.

A problem appears.

Something doesn't work.

There is an opportunity to make it better.

So they build.

The result isn't always perfect.

Sometimes it ships incomplete.

Sometimes the platform has unexpected restrictions.

Sometimes the software creates new problems.

Sometimes a tiny spelling mistake creates hours of debugging.

But every project becomes another source of knowledge.

And that knowledge gets carried into the next thing.

What Comes Next

The next chapter is likely to involve more databases, structured data, automation, AI, and increasingly ambitious software projects.

But the underlying philosophy seems unlikely to change.

Build things that solve real problems.

Listen to users.

Protect their privacy.

Document the reasoning.

Don't be afraid to ship something incomplete.

Keep learning.

And, most importantly, keep enjoying the process.

Because sometimes the best thing a developer can do is simply keep building long enough to luck out hard enough.

About Dhardingsea Developer

Dhardingsea Developer is an independent developer and builder based in Iowa.

Their work spans Manifest V3 Chrome extensions, Windows desktop tools, idle games, production automation, and AI tooling for the legal-process-serving industry.

Their broader development philosophy centers around encoding institutional knowledge into software — turning schemas, workflows, compliance rules, and practical experience into tools that can consistently reproduce that knowledge.

They are particularly interested in local-first software, privacy, minimal permissions, automation, browser extensions, games, AI tooling, and structured data.

You can follow their work on CoderLegion and DHSeaDev.online.

About This Developer Story

Developer: Dhardingsea Developer
Username: @DHSeaDev
Series: CoderLegion Developer Stories
Interview format: Q&A
Interviewed and edited by: Mehadi Hasan, Community & Editorial Team at CoderLegion

This story was created from Dhardingsea Developer's own answers and experiences shared during the CoderLegion Developer Stories Q&A. The article preserves the developer's personal perspective and intentionally keeps the informal character of their responses.

Modern Chrome Extension Development: Manifest V3 Architecture & Best Practices

Sat, 12 Sep 2026 11:27:07 +0000

Hey devs! I put together a practical guide covering the fundamentals of building Chrome extensions with Manifest V3.

Core highlights:

Transitioning from persistent background pages to event-driven service workers

Two-way communication across popups, background workers, and injected content scripts

Safe storage persistence and permission management for smooth store approval

Check out the complete write-up on SunnyWriteUps! Have you migrated your existing extensions to MV3 yet, or are you starting any new extension side projects?
https://sunnyblog.apexmansunny.workers.dev/posts/how-to-create-a-chrome-extension-with-best-practices/

I built a local-first Dota 2 companion as a Chrome extension — and learned what "minimum permissions" actually means

Sat, 05 Sep 2026 15:38:02 +0000

Building a no-account, no-API-key Dota 2 stats extension, and three Chrome/Steam lessons that cost me a Web Store rejection.
https://dhseadev.online/projects/dota-companion/

Most Dota 2 stat sites answer "how did that game go?" I wanted one that answers a harder question: am I actually getting better?

So I built Dota Companion — a Chrome extension that lives in your toolbar. No account, no API key, no signup. Paste a Steam profile URL and it works.

The build taught me three things worth passing on, one of which got the extension flagged by the Chrome Web Store.

The feature I actually cared about: improvement streak

Win streaks measure luck as much as skill. In a five-player team game, you can play well and lose.

So the headline metric isn't wins — it's an improvement streak: consecutive games where your GPM beat your own 20-game baseline. It's a metric you control, and it moves when you improve rather than when your team cooperates.

Same idea drives goals. Pick GPM, KDA, last hits, or win rate; the baseline snapshots your current 20-game average when you set the goal. You compete with past-you.

The rest is the between-games layer: today's W/L, a GPM trend sparkline, recent matches with hero, K/D/A, duration and how long ago, most-played heroes, and private notes and tags on players you run into — stored on your device, never uploaded.

Lesson 1: `chrome.tabs.create()` does not need the `tabs` permission

This one cost me a rejection email.

I had one tabs call — opening a bundled inventory page:

chrome.tabs.create({ url: chrome.runtime.getURL('inventory.html') });

So "tabs" went in the manifest. Reasonable, right?

Wrong. Google flagged it under their minimum-permissions policy:

The following permission(s) need not be requested for the methods/properties implemented by the item: tabs

chrome.tabs.create() has never required the tabs permission. No tab-creation API does. That permission gates exactly one thing: reading sensitive tab metadata — url, pendingUrl, title, favIconUrl — off Tab objects.

I passed a URL in and ignored the returned object. I was declaring a capability I never used.

I verified the fix rather than trusting the docs — loaded the extension with tabs removed and called the API in a real browser:

runtime granted permissions: {"permissions":["storage"],"origins":["https://api.opendota.com/*"]}
chrome.tabs.create -> {"ok":true,"tabId":210614909}
pages before/after: 2 / 3
errors: NONE

Tab opened. Zero errors. The permission was pure liability.

Takeaway: grep your actual call sites before declaring anything. "This API sounds tab-related, so I need tabs" is exactly the reasoning the policy exists to catch. Ask instead: do I read the returned object's sensitive fields? If no, you don't need it.

The extension can estimate your Dota 2 inventory value from Steam Community Market prices. Steam rate-limits those endpoints hard — and critically, the limit applies to the whole IP, not to your extension.

Blow through it and you don't just break your feature. You break the user's normal Steam browsing. That reframes the problem: you're not optimizing your own throughput, you're spending a budget that isn't yours.

So the design is deliberately timid:

Nothing fetches automatically. Every request traces back to a button the user pressed.
A visible request budget, capped well short of the real limit, shown in the UI.
Hard backoff. If Steam pushes back, it stops for hours rather than retrying.
No Steam login cookies are sent. Public data only.

Slower than technically possible, on purpose. A tool that degrades the rest of your browsing isn't a good tool.

Lesson 3: optional permissions are worth the extra state

The inventory feature needs steamcommunity.com access. Most users never open it.

Requesting that host at install time means every user sees a scary permission prompt for a feature they may never touch. So it's an optional host permission, requested at the moment of use:

chrome.permissions.contains({ origins: [ORIGIN] }, cb);  // gate the UI
chrome.permissions.request({ origins: [ORIGIN] }, cb);   // only on click

Cost: a real permission-state machine — gated UI, a grant screen, a declined path. Benefit: the install prompt asks for nothing surprising, and the request arrives with obvious context.

Worth it. Install-time friction is where extensions die.

Extension code resists testing — everything wants chrome.* or the DOM. The fix was a hard boundary: all pure logic (streaks, baselines, formatting, aggregation) sits in modules that touch nothing — no chrome.*, no DOM, no fetch, not even the clock. Current time is passed in as an argument.

Those modules dual-export: a global for the extension, module.exports for Node. The whole stat layer runs headless with zero browser mocks.

That caught a genuinely nasty one. OpenDota returns start_time in epoch seconds. new Date(start_time) expects milliseconds — so every match silently renders as 1970. There's now a regression test asserting exactly that.

Try it

Chrome Web Store: Dota Companion
Project page: dhseadev.online/projects/dota-companion

Data comes from the OpenDota API — you'll need "Expose Public Match Data" enabled in Dota 2 settings for matches to show up. English and Simplified Chinese.

Not affiliated with Valve.

When LCP Moves and Nobody Deployed: Browser Release Cadence and Your 28-Day Field Window

Wed, 02 Sep 2026 22:12:54 +0000

Field Largest Contentful Paint in PageSpeed Insights can move while your release calendar stays empty. Chrome User Experience Report (CrUX) data is always a 28-day rolling average of real Chrome sessions. From Chrome 153 Stable on 8 September 2026, Chrome also moves to a two-week release cycle, so that same window can include more than one browser major with different paint and interaction behaviour. An amber field band after a quiet week is often population mix (who updated Chrome, which channel they use, how fast auto-update spreads), not proof that engineering shipped a regression on Tuesday.

We already separated pipeline lag from rolling-window lag in CrUX pipeline delays and late field data and explained why a verified fix can sit inside a green lab run and an amber field band in why your Core Web Vitals fix is not in CrUX yet. The gap here is the third clock agencies rarely label: browser release cadence inside the field window. When nobody deployed but field LCP drifts, you need release annotations on the same calendar as app, CDN, tag manager, and RUM changes, sample thresholds before you slice by exact Chrome major, and scheduled lab runs as same-week proof that the origin did not change.

Why field LCP can move when nobody deployed

CrUX and PageSpeed Insights field sections describe what real Chrome users experienced over roughly the past 28 days, not what your staging build measured yesterday. If the mix of Chrome versions, devices, networks, and journeys inside that window changes, the published p75 can move even when your HTML, CSS, and JavaScript bundles are byte-identical to last month.

Three non-deploy causes show up often in agency tickets:

Browser updates. A new Stable or Extended Stable channel release changes paint timing, image decoding, lazy-loading heuristics, or interaction scheduling for the same page. Users who auto-update mid-window contribute post-update sessions beside pre-update sessions in one aggregate.
Channel skew. Beta, Dev, and Canary users are a thin slice for most retail sites, but enterprise Extended Stable cohorts can lag Stable by weeks. A retail origin and a locked-down corporate audience can read different field bands on the same URL template.
Traffic mix. Campaign traffic, geography shifts, or seasonality change which templates dominate Chrome sessions. Origin-level field LCP can move when the homepage share of traffic falls while a slower category listing gains share, with no code change on either template.

Lab runs on a fixed URL answer whether your deploy changed the critical path. Field CrUX answers what Chrome users actually experienced across versions and journeys. Treating a field move as a deploy regression without checking browser and traffic mix sends engineering on a hunt for a commit that does not exist.

Chrome release cycle and Core Web Vitals: two-week Stable from Chrome 153

Google announced in March 2026 that Chrome will move from a four-week Stable cadence to a two-week cycle, starting with Chrome 153 Stable on 8 September 2026 (Chrome two-week release blog). Beta and Stable promotions arrive every two weeks on Desktop, Android, and iOS. Extended Stable keeps an eight-week cycle for enterprises that need longer validation windows (Chrome Enterprise Extended Stable).

The schedule compresses milestones quickly. Under the new table in Google's post, Chrome 153 Stable cuts on 25 August 2026 with public Stable on 8 September, while Chrome 154 Stable follows on 22 September. Firefox is running a similar experiment around Firefox 155 from 1 September 2026 (see community coverage linked from CSS Wizardry Web-Perf Wednesday 006). Performance teams that only annotated application releases in 2025 will need browser rows on the same calendar in 2026.

Release	Old four-week Stable (illustrative)	New two-week Stable (from Google table)
Chrome 153	Tue 22 Sep 2026	Tue 8 Sep 2026
Chrome 154	Tue 20 Oct 2026	Tue 22 Sep 2026

Smaller, more frequent browser releases are good for security and platform velocity. For field reporting they mean more opportunities for a 28-day CrUX window to span two majors with different Web Vitals behaviour, without any change on your origin.

How a 28-day CrUX window can span multiple browser majors

CrUX aggregates opted-in Chrome sessions into a rolling 28-day window. At any query, PageSpeed Insights and the CrUX API return a collectionPeriod with firstDate and endDate covering that blend (CrUX API documentation). The window advances daily: oldest day drops, newest day enters. There is no switch that flips the entire population to "only Chrome 153 sessions" on Stable release day.

Under a four-week browser cadence, one 28-day field window often covered one new Stable major plus tail versions. Under a two-week cadence, the same window can include two adjacent majors (for example 152 and 153) while auto-update propagates. Each major can shift LCP, INP, or CLS for the same URL because the browser pipeline changed, not because your LCP element or server timing changed.

Clock	What moves	Typical agency mistake
28-day CrUX window	Rolling average of Chrome sessions	Treating field p75 as "yesterday's score"
Chrome Stable cadence	Browser majors entering the window	Ignoring browser rows on the release calendar
App / CDN deploy	Origin HTML, assets, cache rules	Blaming deploys for browser-driven field drift
Lab schedule	Controlled PageSpeed Insights / Lighthouse runs	Expecting lab to explain field without dates

For metric definitions and why field percentiles behave differently from lab medians, start with our practical Core Web Vitals guide. For why lab and field are different instruments on the same URL, see synthetic versus real user monitoring.

Browser version in RUM: population mix vs a site regression

First-party Real User Monitoring (RUM) and CrUX answer different questions. CrUX is a public, privacy-thresholded view of Chrome traffic Google already collected. RUM is yours: you choose segments, retention, and alert rules. When practitioners search browser version RUM, they usually need to know whether a field shift is segment noise before they open a regression ticket.

Population mix means the aggregate changed because the audience composition changed: more sessions on Chrome 153, fewer on 152, a higher share of mobile on a slower network, or a campaign that sent traffic to a heavier template. Site regression means the same browser version and similar journey on the same URL got worse after your change (or after a third-party or CDN change you control).

Before you slice field data by exact Chrome major, set sample thresholds. Thin segments produce volatile p75 lines that look like regressions every week. Rules we use in client work:

Do not report URL-level p75 for a single Chrome major until you have enough sessions to trust the segment (exact cut-offs depend on traffic; treat very small counts as directional only).
Prefer unsegmented LCP, INP, and CLS as the headline series in retainer reports; use browser-major slices in appendix slides for engineers.
Compare like with like: same form factor, same URL or origin scope, same collection period dates.
Pair every segmented chart with an unsegmented line so leadership sees whether the whole population moved or only one slice.

Harry Roberts framed the risk clearly in Web-Perf Wednesday 006: faster browser releases change the RUM population you are averaging, not just the code on your server. Agencies that report "Chrome 152 LCP" and "Chrome 153 LCP" without sample sizes invite false escalations every Stable Tuesday.

Put Chrome Stable on the same calendar as deploys and CDN changes

Performance regressions are easier to debug when every graph annotation uses the same calendar. Most teams already mark application deploys, CDN cache rule changes, tag manager publishes, and major marketing releases. Browser Stable and Beta dates belong on that same timeline from September 2026 onward.

Checklist we ask account and engineering leads to maintain:

Chrome Stable and Early Stable dates for Desktop and Android (at minimum) through the next two milestones.
Extended Stable notes for clients with locked-down browser policies.
Firefox milestone dates when the site has meaningful non-Chrome share in RUM.
RUM or CrUX instrumentation changes (new snippet, different sampling, new soft-navigation handler).
Named owner who updates the calendar within one business day of a release (not "the platform team" in the abstract).

When field LCP moves in the weekly report, the first question is not "what did we ship?" but "what changed in the window: browser, traffic, CDN, tags, or code?" A single annotated timeline prevents the "nobody deployed" argument from turning into a trust fight. The ops checklist (release owner, browser rows beside deploy rows) is the agency ritual; the sections above carry the CrUX math and monitoring split.

Sample thresholds before you slice field data by Chrome major

Segmentation is useful after thresholds, not before. If Chrome 153 represents 4% of sessions in a 28-day URL-level slice, its p75 is not a client-ready KPI. Use thresholds to decide when a segment earns its own row in the report.

Segment type	When to show in client body	When to keep internal
Unsegmented origin or URL field p75	Always, with `collectionPeriod` dates	n/a
Mobile vs desktop field	When both pass eligibility	Thin desktop slice on mobile-heavy sites
Chrome major (e.g. M152 vs M153)	When each major has stable sample counts	Single-digit session majors
Beta / Dev channel	Rarely	Almost always appendix only

In first-party RUM, configure minimum session counts per segment before alerts fire. In CrUX-only workflows, respect Google's eligibility and popularity rules (CrUX methodology): missing URL-level data is often "not enough Chrome sessions," not a tooling failure. Say that explicitly in the report footnote.

Use scheduled lab runs as same-week proof when field CrUX drifts

Unsegmented field series are the executive headline. They answer "how are our users doing in aggregate?" without opening a statistics debate on Chrome 152.3 versus 153.0. Browser-major slices are diagnostic tools for engineers checking whether a shift correlates with a Stable release line on the calendar.

Scheduled lab runs provide same-week proof that the origin did not change:

Run PageSpeed Insights or Lighthouse on priority URLs on a fixed schedule (how to schedule PageSpeed monitoring across a portfolio).
Store run timestamps beside field collectionPeriod dates in the client-ready Core Web Vitals report outline.
If lab LCP and INP stay inside budget while field p75 drifts, investigate population mix and browser cadence before you roll back a deploy.
If lab and field move together after a deploy, treat it as a site change regardless of browser week.

Spot checks fail this test because Tuesday's paste and Thursday's paste are not a history. PageSpeed Insights versus automated monitoring is where we unpacked why portfolios need schedules, not heroic manual runs. Apogee Watcher holds that lab clock for multi-tenant teams: scheduled tests, budgets, alerts, and CrUX field numbers when Google returns them beside the same URL row. We do not replace first-party RUM segmentation. We keep lab verification repeatable while you interpret field drift.

Browser mix vs fix lag and CrUX pipeline delay: three lag types

Agencies confuse three lag types. Each needs a different sentence in the client deck.

Lag type	Cause	What the client sees	Primary doc
Rolling-window fix lag	Pre-fix sessions still inside 28 days after a deploy	Slow field improvement after a verified lab win	[Why your fix is not in CrUX yet](https://apogeewatcher.com/blog/why-core-web-vitals-fix-not-in-crux-yet-28-day-window)
Pipeline / publication lag	CrUX API, History, or BigQuery publish late	Same field values two days straight; missing weekly point	[CrUX pipeline delays](https://apogeewatcher.com/blog/crux-pipeline-delays-late-field-data-client-reports)
Browser population mix	New Chrome majors enter the window without a site deploy	Field moves while lab flat; shift aligns with Stable calendar	This post

Fix lag is about your sessions aging out. Pipeline lag is about Google's publish schedule. Browser mix is about whose Chrome sits inside an already-published window. A field LCP move with no deploy and flat lab budgets is often the third row, especially from September 2026 when two-week Stable releases overlap the 28-day average more often.

How agencies should monitor and report while browser mix shifts

From August through October 2026, expect more "false regression" tickets. Build the monitoring plan around dated clocks, not vibes.

Weekly field read with firstDate and endDate on every table row. No naked p75 without collection period.
Daily or thrice-weekly lab on money URLs through the Chrome 153 and 154 Stable window.
Release calendar with browser Stable rows visible to SEO and engineering, not only infra.
Executive one-liner in the retainer PDF: "Field CrUX is a 28-day rolling average of real Chrome users; browser Stable releases can move field bands without a site deploy; lab trends below are same-week origin verification."
Escalation rule: open a code regression when lab budgets break or when unsegmented field and lab move together after a deploy; investigate population mix when lab is flat and field drifts across a Stable line.

Portfolio teams scale this with per-client organisations, shared budget templates, and alerts that fire on lab thresholds even when field data lags. That is the layer Apogee Watcher adds on top of Search Console and whatever RUM vendor the client already pays for.

FAQ

Can Core Web Vitals change without a website update?

Yes. CrUX field metrics reflect real Chrome sessions over a rolling 28-day window. Browser updates, traffic mix shifts, and eligibility changes can move field p75 without any deploy on your origin. Lab runs on fixed URLs help prove whether the site changed.

How does Chrome's two-week release cycle affect CrUX data?

More frequent Stable releases mean a 28-day field window can include two browser majors with different performance behaviour. Field LCP or INP can shift as auto-update spreads, even when your code is unchanged. Annotate Chrome Stable dates on your release calendar from Chrome 153 onward.

Should I segment RUM by browser version after Chrome 153?

Segment when sample sizes support it, and keep an unsegmented headline series for clients. Thin Chrome-major slices produce noisy charts. Set minimum session thresholds before alerts or report rows use a single major.

Is a field LCP move a

How to measure LCP and INP in Safari 26.2 (and what still only Chrome reports)

Mon, 17 Aug 2026 12:44:00 +0000

For years, many agency Core Web Vitals programmes had a quiet blind spot. Chrome users filled CrUX, Search Console, and PageSpeed Insights field panels. Safari users on iPhone and Mac still felt slow pages, yet your JavaScript often never saw largest-contentful-paint or Event Timing entries in WebKit. That gap mattered whenever a client’s traffic mix was heavy on iOS, education, or consumer brands with strong Apple share.

Safari 26.2, released 12 December 2025, adds the Largest Contentful Paint API and the Event Timing API in WebKit. You can finally collect Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) from real Safari sessions through the Performance API, your own analytics, or a real user monitoring (RUM) tool. What follows is a practical measurement guide: how to observe the new entries, how to use Google’s web-vitals library, what still only Chrome reports in public Google tools, and where scheduled PageSpeed monitoring still fits beside Safari RUM.

What Safari 26.2 changed for LCP and INP measurement

Apple’s WebKit Features for Safari 26.2 post states that Safari 26.2 adds support for Event Timing and Largest Contentful Paint. Event Timing follows an interaction from input through event handlers and DOM updates until the next paint, which is the raw material for INP. Largest Contentful Paint reports when the largest visible element in the viewport finished painting during load. Web Inspector also shows LCP entries in the Timelines tab, which is useful for verifying a hero image or text block before you trust a production pipeline.

Google’s web.dev note on Baseline marks LCP and INP measurement APIs as Baseline Newly available after Safari 26.2 completed the major-browser set (Chromium already had them; Firefox added the INP pieces earlier). Newly available does not mean every visitor has upgraded. Users on older iOS builds, managed devices, or delayed OS updates still will not emit these entries until they move to a supporting Safari. Plan for mixed support for months, not for a single overnight switch.

Metric definitions have not changed. LCP still describes load feel for the main content. INP still describes responsiveness across interactions on the page. CLS still measures layout stability and remains Chromium-led in many RUM stacks. If you need a refresher before you change reporting templates, start with LCP, INP, and CLS explained and our INP guide.

How to measure LCP in Safari with PerformanceObserver

Once Safari exposes largest-contentful-paint entries, you can observe them the same way you do in Chromium. Register a PerformanceObserver with buffered: true so candidates that fired before your script loaded still appear. Log or beacon each candidate, and treat the last candidate before the page is hidden as the LCP you report for that navigation.

const lcpObserver = new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    // Candidates update as larger elements paint; keep the latest.
    console.log('LCP candidate', entry.startTime, entry.element, entry.url);
  }
});
lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });

Finalise on visibilitychange or pagehide when the document becomes hidden, then disconnect the observer. That pattern matches how production RUM libraries avoid reporting a mid-load candidate as the permanent LCP. Feature-detect with PerformanceObserver.supportedEntryTypes.includes('largest-contentful-paint') so older Safari builds stay quiet instead of throwing.

Use Web Inspector’s Layout and Rendering timeline to confirm the element you think is LCP is the one Safari records. Agencies often discover that a cookie banner, carousels, or a late web font swap changes the LCP element on iOS even when Chrome’s lab run pointed at the hero image. Fix the template once you see the Safari element; do not argue from a single Chrome Lighthouse screenshot alone.

How to measure INP in Safari with the Event Timing API

INP is not a single Event Timing entry. You observe event entries (with interactionId where available), keep the interaction latencies that matter, and apply the INP selection rules across the page lifetime. Safari 26.2’s Event Timing support is what makes that pipeline possible in WebKit. A minimal observer looks like this:

const eventObserver = new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (!entry.interactionId) continue;
    console.log('Interaction', {
      name: entry.name,
      duration: entry.duration,
      startTime: entry.startTime,
      interactionId: entry.interactionId,
    });
  }
});
eventObserver.observe({ type: 'event', buffered: true, durationThreshold: 16 });

Lower durationThreshold (for example 1) if you are debugging and need more events. Production pipelines usually keep a higher threshold and let a library compute INP so you do not re-implement selection logic incorrectly. Finalise INP when the page is hidden, because the metric can improve or worsen as the user keeps interacting.

Treat early Safari INP numbers with care. DebugBear notes that Safari’s INP implementation has had cases of unreasonably high scores while the engine settles. Segment by browser family before you tell a client that “INP exploded on iPhone.” Confirm the Safari version share in your analytics, re-check on a physical device, and compare against Chrome INP for the same URL template.

How to collect Safari LCP and INP with web-vitals.js

For most sites, Google’s web-vitals library is the safer path than hand-rolled observers. It handles buffering, attribution helpers, and finalisation when the page is hidden. After Safari gained the underlying APIs, the same onLCP and onINP callbacks can receive Safari sessions once those users are on 26.2 or later.

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  navigator.sendBeacon('/rum', JSON.stringify(metric));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Ask your RUM vendor whether Safari LCP and INP are already flowing, or whether you need a library upgrade. Shopify’s performance team warned store owners that dashboards can shift once Safari data arrives, and that prior “Safari” LCP or INP rows in some tools were not true Safari field samples. Establish browser-family baselines before you treat a combined p75 as gospel.

Keep CLS in the pipeline where your stack supports it, and label browser coverage in client decks. CLS support is still uneven compared with LCP and INP across engines. A Safari-heavy site can look healthy on LCP while layout shift problems remain visible mainly in Chromium field data.

What still only Chrome reports (CrUX, Search Console, PageSpeed Insights field)

Safari RUM and Google’s public field panels are not the same system. CrUX, the Chrome User Experience Report, remains a Chrome-user sample. Search Console’s Core Web Vitals report and the field block in PageSpeed Insights draw on that CrUX world. Turning on Safari observers does not fill those Google UIs with iPhone percentiles.

Source	What you get after Safari 26.2	Still Chrome-skewed?
First-party RUM / `web-vitals` / vendor RUM	LCP and INP from Safari 26.2+ users when instrumented	No, if you segment by browser
CrUX (origin or URL)	Real-user Chrome percentiles	Yes
Search Console CWV report	Field issues from CrUX	Yes
PageSpeed Insights field section	CrUX slices beside lab	Yes for field; lab is synthetic
Scheduled Lighthouse / PageSpeed Insights lab	Controlled lab run on a listed URL	Lab is not Safari field

That split is why agencies still need both layers. Safari RUM answers “how do our iOS users experience this template?” Chrome field tools answer “what does Google’s Chrome-based field sample say for ranking and Search Console?” Scheduled lab runs answer “did yesterday’s deploy regress the URL we listed?” Confusing any two of those produces the same failure mode as treating a missing CrUX row as proof the page has no CLS. We covered missing field rows in When PageSpeed Insights shows no CLS or INP.

Why Safari and Chrome LCP timings can differ slightly

Even when both browsers expose LCP, the clocks are not identical down to the millisecond. web.dev explains that Chrome has historically included a later presentationTime in LCP, while Firefox and Safari stop at an earlier paintTime. The difference is usually small, but it is enough to create noisy comparisons if you merge browser families into one percentile without labelling the engine. Chrome has been exposing more comparable paint timing for cross-browser work; still segment reports by browser until your tooling documents like-for-like fields.

Expect distribution shifts when Safari volume turns on in RUM. Some teams see slower Safari LCP than Chrome on the same URL; others see the opposite. Image decoding, font loading, and main-thread contention differ by engine and device. Use the new visibility to find Safari-specific issues (lazy-loaded LCP images, large hero assets on cellular, third-party scripts that hurt INP on iOS). Do not panic-rewrite the entire stack because a combined dashboard moved after Safari data landed.

Agency checklist: segment Safari RUM beside Chrome lab and CrUX

Confirm Safari version share in analytics for priority clients (especially education, consumer, and US mobile-heavy brands).
Upgrade or verify RUM so web-vitals or your vendor actually receives Safari LCP and INP.
Baseline by browser family for two to four weeks before rewriting client SLAs.
Keep CrUX and Search Console as the Chrome field story for SEO conversations.
Keep scheduled lab tests on money URLs for deploy regression, independent of Safari RUM noise.
Document the stack in the monthly deck: Safari RUM for iOS experience, CrUX for Google field, lab for release confidence.
Re-test INP outliers on device before escalating Safari INP spikes to engineering as production incidents.

For journey-heavy products (enrolment, lessons, checkout), map which steps matter on iPhone first. Our EdTech performance monitoring guide is a useful pattern even outside education: measure the stages users feel, not only the marketing homepage. The same habit applies to SaaS onboarding and ecommerce checkout when Safari share is material.

Where Apogee Watcher fits after Safari starts reporting LCP and INP

Apogee Watcher runs scheduled PageSpeed Insights tests across multi-tenant portfolios: discovery, mobile and desktop strategies, budgets, alerts, and client-ready trends. Those runs give you lab metrics plus CrUX field slices when Google has enough Chrome sample for the URL or origin. Watcher does not inject a Safari RUM snippet, and it does not claim Safari LCP or INP inside the product UI.

That boundary is deliberate. Safari field collection belongs in your RUM or first-party web-vitals pipeline. Watcher stays on the deploy and portfolio side: catch regressions on listed URLs after theme, tag, or CDN changes, while Safari RUM tells you whether iOS users improved after the fix. Layer the two. Do not rip out Chrome field reporting, and do not pretend a lab score is a Safari percentile.

If you need the wider lab versus field decision tree, see synthetic versus real user monitoring and PageSpeed Insights versus automated monitoring. Soft navigations and SPA route measurement remain a separate Chromium-led topic. Scheduled PageSpeed Insights still measures full document loads of the URLs you list, as we described for Chrome 151 soft navigations.

Start a free trial to schedule PageSpeed tests and budgets across client sites while you instrument Safari RUM for iOS-heavy accounts. Or run a free PageSpeed check on a priority URL before you change reporting templates.

FAQ

Does Safari 26.2 mean CrUX now includes iPhone users?
No. CrUX remains a Chrome user experience sample. Safari 26.2 lets your own RUM or analytics read LCP and INP from Safari sessions. It does not rewrite Search Console or PageSpeed Insights field panels into multi-engine field data.

Is CLS now available in Safari the same way as LCP and INP?
Do not assume parity. This release is about Largest Contentful Paint and Event Timing for INP. Check your RUM vendor’s browser support table for CLS before you promise Safari layout-shift percentiles in a retainer report.

Should we stop using PageSpeed Insights lab scores?
No. Lab scores remain useful for controlled comparisons after deploys. Pair them with Chrome field data where CrUX exists, and with Safari RUM where iOS traffic matters. Each layer answers a different question.

Why did our RUM LCP get worse after Safari data appeared?
Combined percentiles often move when a new browser family joins the sample. Segment by Safari versus Chrome, confirm users are on 26.2+, and inspect the LCP element on a real iPhone before you treat the shift as a pure regression from your last release.

Can Apogee Watcher show Safari LCP and INP today?
No. Watcher stores scheduled PageSpeed Insights lab results and available CrUX field slices for the URLs you monitor. Use RUM or web-vitals for Safari field collection, and Watcher for portfolio lab cadence and alerts.

References

Lighthouse’s New Baseline Features Audit: What Developers Should Do With It

Mon, 03 Aug 2026 08:22:00 +0000

You ship a layout that looks clean in Chrome. A week later Safari users report a broken filter panel, or Firefox drops a CSS feature your design system assumed was safe. The Performance score on PageSpeed Insights still looks fine, because speed and interoperability are different questions. Until recently, Lighthouse did not give you a single Best Practices view of which web platform features your page (and its vendors) actually use, and where those features sit on the Baseline timeline.

Chrome’s Baseline Features audit now sits in Lighthouse’s Best Practices category as a diagnostic. It detects web feature IDs from the web-features package, reports each feature’s Baseline status (Limited availability, Newly available, or Widely available), links to the matching entry on webstatus.dev, and points at one place in the page’s source where that feature showed up. It also covers features used in third-party scripts and active extensions. What follows is a practical read of that report for developers and agencies: what the statuses mean, how to triage Limited features, when Newly available is acceptable, and how scheduled PageSpeed monitoring fits beside a one-off DevTools run.

What the Lighthouse Baseline Features audit reports

The audit is diagnostic. Chrome’s docs describe it as information for developers, not as a single pass/fail gate that behaves like a broken HTTPS check. Treat the output as an inventory with risk labels, not as a new Core Web Vitals threshold. If you only chase the green Performance dial, you can still ship Limited features that fail for a meaningful share of clients on Safari or Firefox.

For each detected feature you typically get three artefacts. The web feature ID (from the web-features package) links through to webstatus.dev so you can read support notes without leaving the report. The Baseline status tells you how far that feature has progressed through the WebDX Baseline model described on web.dev’s Baseline overview. A source location shows one occurrence in the site’s code or in loaded scripts, which is enough to open a ticket even when the same feature appears many times on the page.

Third-party coverage matters as much as first-party CSS. Tag managers, chat widgets, and personalisation scripts often pull newer APIs than your own theme ever would. The same pattern we cover in third-party scripts and performance applies here: the vendor controls when their script updates, and you still answer the support ticket when a checkout filter breaks. Extensions loaded in the browser you used for the audit can also appear, so run a clean profile when you need a list you can show a client.

What Widely available, Newly available, and Limited availability mean for web platform Baseline

Baseline answers a different question from “does Chrome support this?” Limited availability means the feature is not yet interoperable across the core browser set (desktop and mobile engines in the Baseline definition). Newly available means it has become interoperable across those core browsers. Widely available means roughly thirty months have passed since that Newly available date, which web.dev treats as a practical “safe for most sites” line, while still reminding teams that audience data can justify earlier or later adoption.

Use those labels as triage, not as hard law for every project. Widely available is the default green light for marketing sites and agency retainers where support tickets are expensive. Newly available is fine when you control progressive enhancement, have analytics that show the relevant engines are already current, or are shipping an internal tool with a known browser policy. Limited availability needs an explicit decision: polyfill or progressive enhancement, feature-detect and degrade, remove the usage, or accept documented risk with the client. web.dev’s guidance on Baseline and polyfills is clear that polyfills do not move a feature out of Limited in Baseline messaging; native interoperability is what the status tracks.

A practical agency rule of thumb keeps reviews short. Treat Limited on a money URL as a release blocker until someone names the fallback. Treat Newly available as a design-system discussion, not a silent ship in the theme pull request. Treat Widely available as “no special story required,” unless your analytics show a long tail of very old browsers that still matter for that client.

How to triage Lighthouse Baseline Features findings on a live page

Open the Best Practices section after a Lighthouse or PageSpeed Insights run and collect every Limited row first. Ignore Widely available noise until Limited and Newly available are sorted. For each Limited feature, answer three questions in the ticket: first-party or third-party, which URL template, and what the user loses if the feature is missing. Then decide the fix class: remove, replace with a Widely available equivalent, progressive enhancement, or vendor escalation.

First-party CSS and JavaScript

When the source points at your stylesheet or application bundle, ownership is clear. Prefer a Widely available pattern when the visual result is equivalent, even if the newer syntax looks cleaner in Chrome DevTools. If the feature is Newly available and the design needs it, wrap behaviour behind feature detection and keep a usable fallback for engines that lag. Document the choice in the pull request so the next release does not “simplify” the fallback away during a tidy-up.

Third-party scripts and tag managers

When the occurrence sits in a vendor file or a Google Tag Manager-injected script, do not burn a sprint rewriting their minified output. Raise the Limited list with the vendor or the marketing owner of that tag, ask whether a widely supported build exists, and fence the tag behind consent or load rules if it is optional on the URL. If the vendor cannot commit to a timeline, treat the tag like any other performance offender: keep it off checkout and other money paths until the risk is accepted in writing by the account lead.

Extensions and noisy environments

Active extensions can inject features into the page under audit and pollute the inventory. For client reports, use a clean Chromium profile or an automated lab environment without personal extensions. Otherwise you will spend a call explaining why a password-manager API appeared on a retail homepage that never shipped that code.

When is Baseline Newly available acceptable on client sites?

Newly available is not a failure. It means interoperability across the core set has only recently landed, so older minor versions and slow updaters may still miss it. For a consumer ecommerce site with a long mobile Safari tail, wait for Widely available or ship with a tested fallback. For a SaaS app where you already require current Chrome and Firefox, Newly available can be an intentional choice written into the browser support policy.

Decide with audience data, not with a Chrome-only staging machine. If you lack analytics, default to Widely available for public marketing pages and reserve Newly available for progressive enhancement that still works when the feature is missing. Record the decision in the ticket or design-system note so account managers do not treat every Newly available row as a red flag in the monthly review.

Lighthouse Best Practices versus Performance scores and Core Web Vitals

The Baseline Features audit lives under Best Practices. It does not replace Largest Contentful Paint, Interaction to Next Paint, or Cumulative Layout Shift, and it does not redefine how the lab Performance score is weighted. A page can score well on Performance while listing Limited features, or fail Core Web Vitals while using only Widely available APIs. Keep those dashboards separate in client language: speed budgets on one slide, interoperability findings on another.

If your team still pastes a single PageSpeed Insights run into Slack and calls the week done, the Baseline list will go stale the same way scores do. We covered that failure mode in PageSpeed Insights versus automated monitoring. Coding agents can also run Lighthouse for Best Practices in DevTools, which helps for a local fix but not for portfolio history. Pair this audit with the workflow in Automate Lighthouse audits with AI agents when an engineer wants a one-shot pass, then put the URL back on a schedule so the next tag change does not silently reintroduce Limited features.

How to monitor Baseline Features after a deploy with PageSpeed schedules

One DevTools run proves what shipped today, but it does not prove the marketing site still looks the same after the next plugin update. For agencies, fold Baseline triage into the same schedule you already use for Core Web Vitals: priority URLs, mobile and desktop where it matters, and a named owner when Limited rows appear after a release. The Core Web Vitals monitoring checklist for agencies is a useful starting list; add a short Best Practices / Baseline step on money templates after theme, tag, or design-system changes.

Apogee Watcher schedules PageSpeed Insights-backed lab runs across client sites, stores history, and alerts when budgets regress. Best Practices diagnostics, including Baseline Features when the Lighthouse version behind your PageSpeed Insights run includes them, appear in those lab reports as the PageSpeed Insights and Lighthouse versions catch up. Be honest about rollout lag: public PageSpeed Insights and local Lighthouse can ship audits on different clocks. Confirm the Baseline Features section appears on a fresh run before you promise clients a weekly Baseline comparison. Where it does appear, use Watcher for multi-site schedules and regression alerts; use DevTools for deep triage of a single Limited feature. Layer monitoring onto the stack you already have. Do not remove vendor real user monitoring or continuous integration solely to read Baseline statuses.

What to tell clients about web platform Baseline and Lighthouse Best Practices

Keep the retainer wording short so SEO and engineering stay aligned.

Baseline is WebDX’s shared language for how far a web platform feature has progressed across core browsers: Limited, Newly available, Widely available.
Lighthouse’s Baseline Features audit lists features detected on the page (including many third-party scripts), with links to webstatus.dev and a source hint.
Limited on a money URL needs an owner and a fallback plan before go-live. Newly available needs an audience check. Widely available is the usual default for public sites.
Performance scores and Core Web Vitals still answer speed and interaction quality. Baseline answers interoperability risk.
Done means Limited rows on priority URLs are cleared or accepted in writing, and scheduled lab runs still catch regressions after deploys.

Avoid inventing a “Baseline score” Google has not defined as a ranking factor. Report the inventory and the decisions you took on Limited rows. That is enough for most procurement conversations and quarterly client reviews.

FAQ

What is the Lighthouse Baseline Features audit?

It is a Best Practices diagnostic in Lighthouse that lists web platform features detected on the page, each with a Baseline status (Limited availability, Newly available, or Widely available), a link to webstatus.dev, and a source location. Chrome documents it under Baseline Features. It also lists features from third-party scripts and active extensions.

Does Baseline Newly available mean I should not ship the feature?

No. Newly available means the feature is interoperable across the core browser set but has not yet reached the Widely available (about thirty months) line. Ship it when progressive enhancement or your audience data supports it. Prefer Widely available defaults for public marketing sites with unknown long tails.

Will Limited availability features lower my PageSpeed Insights Performance score?

Not automatically. Baseline Features is a Best Practices diagnostic about interoperability, not a Performance metric like Largest Contentful Paint or Total Blocking Time. Fix Limited features for user risk and support cost, not because you expect the Performance dial alone to move.

Do third-party scripts show up in the Baseline Features audit?

Yes. Chrome’s documentation states the audit reports web features used in third-party scripts and extensions. That is often where Limited findings appear even when your own theme is conservative. Expect chat widgets, A/B tools, and tag-manager containers to contribute rows you did not author.

Does Apogee Watcher replace a manual Baseline Features review?

No. Watcher runs scheduled lab tests and keeps portfolio history, budgets, and alerts so regressions after deploys are visible across many sites. Use DevTools or a single PageSpeed Insights report to triage a specific Limited feature, then keep the URL on a schedule so the next tag or theme change cannot quietly reintroduce it. Confirm your lab stack’s Lighthouse version includes the audit before you sell weekly Baseline reporting.

Pick one money URL (homepage, product template, or checkout). Run Lighthouse in a clean Chrome profile, open Best Practices, and export every Limited and Newly available row into a short table: feature ID, status, first-party or third-party, owner, decision. Fix or fence the Limited items that affect that URL, then put the same URL on a Watcher or PageSpeed schedule so the next deploy still gets a lab history. Baseline Features closes an interoperability gap Lighthouse now names for you. Scheduled monitoring still closes the portfolio gap agencies own.

References

Baseline Features (Lighthouse Best Practices) — Chrome for Developers
webstatus.dev — Web Platform Dashboard / feature status
Baseline — web.dev overview
How to think about Baseline and polyfills — web.dev
Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders
PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough
Automate Lighthouse Audits with AI Agents: What Chrome DevTools Means for Agencies
Core Web Vitals Monitoring Checklist for Agencies

Soft Navigations in Chrome 151: How to Prepare and What to Measure

Sun, 02 Aug 2026 20:22:00 +0000

Your React or Vue product site already updates the URL when someone clicks from pricing to checkout. The address bar looks like a new page. Search Console and PageSpeed Insights still treat most of that journey as one long document load, so Largest Contentful Paint (LCP) for the first paint stays on the initial hard navigation while later route changes never get their own Core Web Vitals story. Clients feel those transitions. Field tooling often does not.

Chrome has been working toward a browser-standard definition of those client-side route changes, called soft navigations. In Chrome 151 the soft-navigation and interaction-contentful-paint performance entry types ship for sites without a special flag. Barry Pollard's Measuring soft navigations guide (updated July 2026) states the feature is available for all sites from Chrome 151. What follows is a practical prep and measurement checklist for agencies: what soft navigations are, how Interaction Contentful Paint (ICP) relates to LCP on route changes, how to prepare the app so heuristics fire, what you can observe today, and where Apogee Watcher's scheduled lab runs still stop short.

What soft navigations mean for SPA Core Web Vitals

Chrome's working definition of a soft navigation is short. The navigation starts from a user action. It results in a visible URL change. The interaction results in a visible paint. Sites that miss any of those three conditions may see false negatives (route changes users treat as navigations that never emit soft-navigation entries). Sites that meet them too loosely may see false positives. Feedback still belongs in the soft navigation specification repository, not in invented thresholds.

For Core Web Vitals reporting, the gap has always been architectural. Multi-page apps get a fresh navigation timing origin on each full document load. Single-page apps replace content with JavaScript, push history, and keep the same document. Classic LCP, Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) still run, but they were designed around that document lifecycle. Soft navigations give Chromium a shared way to slice metrics per route-like transition, independent of which framework performed the update. For metric definitions before you argue about SPA timing, start with LCP, INP, and CLS explained and our INP guide.

Soft navigations do not replace hard navigations. Cold loads, deep links, and full reloads still use the usual navigation and LCP entries. Soft navigations sit beside that model for in-app route changes once Chrome detects them.

Chrome 151 adds soft-navigation and interaction-contentful-paint entry types to the Web Performance API timeline. The beta notes describe them as establishing new time origins for route transitions so Core Web Vitals can be measured for soft navigations. You can feature-detect with PerformanceObserver.supportedEntryTypes.includes('soft-navigation') or check for SoftNavigationEntry on window while support is rolling out.

When soft navigations are active, Chrome changes how some timings report. A soft-navigation entry emits after each detected soft navigation. It carries a navigationId, the new URL in name, and an interactionId for the initiating interaction. One or more interaction-contentful-paint entries emit after interactions that cause a contentful paint; each can include a largestContentfulPaint property usable as LCP for that soft navigation when you map entries carefully. Soft-navigation entries also expose paintTime and presentationTime as FCP for that navigation, and getLargestInteractionContentfulPaint() to retrieve the largest ICP entry for that navigation without buffering every paint yourself.

Hard-navigation LCP from largest-contentful-paint still finalises on interaction as before. Soft-navigation LCP comes from ICP entries whose interactionId matches the soft navigation, not from every later interaction on the same document. Timings remain relative to the original hard navigation start time, so you subtract the soft navigation startTime when you report LCP relative to the route change. Chrome's docs recommend reporting TTFB as 0 for soft navigations for now, similar to back/forward cache restores, which is what the web-vitals library does.

DevTools already shows soft navigation and LCP markers in the Performance panel trace view, marked with * to distinguish them from hard navigations. That path is useful for verifying detection on a staging SPA before your RUM pipeline is ready. Walk the money routes once in the trace view so you know whether Chrome sees the same transitions your users feel.

How to prepare your SPA so soft navigations can be detected

You cannot force Chrome to invent a soft navigation for a route change that never updates the URL or never paints. Preparation is about matching the heuristic, not about shipping a private score. If the address bar stays put or nothing paints after the click, no observer will invent a Core Web Vitals slice for that journey.

Keep URL updates visible and history-friendly

Soft navigations require a visible URL change tied to the user action. Use the History API or Navigation API in ways users already understand: push or replace state when the primary content area represents a new destination, keep the back button coherent, and avoid silent content swaps that leave the address bar on the previous path. If marketing and product disagree on whether a filter panel is a "page," decide deliberately. Heuristics will not resolve product ambiguity for you.

Paint after the interaction that starts the transition

The third criterion is a visible paint after the interaction. If your router changes the URL before any paint, or paints before the URL update, Chrome still tries to reconcile ICP and soft-navigation ordering, but delayed paints and deferred URL updates create harder mapping. Prefer a clear sequence: user activates a control, content updates enough to paint, URL reflects the destination. Skeleton screens that paint count; invisible DOM mutations that never reach the screen do not.

Test detection before you promise clients soft-nav field data

Enable soft navigation heuristics in a local Chrome build if you need to verify early (chrome://flags/#soft-navigation-heuristics or SoftNavigationHeuristics features), then re-check on Chrome 151+ where the feature is intended to be on by default. Walk primary SPA flows in DevTools Performance, confirm soft-navigation markers appear on the money routes, and note false positives on overlays that change the hash without a real destination change. Feature-detect before you attach observers in production so older Chromium builds and non-Chromium browsers stay quiet.

How to measure soft navigations and Interaction Contentful Paint

Observe soft-navigation with a PerformanceObserver, including buffered: true if you need earlier entries on the page. On each soft navigation, finalise metrics for the previous URL, then start fresh for the new URL using name and navigationId. Map ICP entries to soft navigations with interactionId, and use getLargestInteractionContentfulPaint() so paints that happened before the soft-navigation entry was emitted still attach correctly.

Reset long-lived metrics the way Chrome's guide describes. When a new soft navigation starts, treat LCP, INP, and CLS as new series for that URL slice. Do not keep the previous route's largest paint or shift score as if the user never left. Subtract soft-navigation startTime from soft-nav LCP timings so reports are relative to the route interaction, not the original document load.

Expect incomplete coverage. Soft-navigation APIs are Chromium-first. Other browsers and older Chrome versions may report classic Core Web Vitals without soft-navigation slices. Many RUM vendors are still aligning to the shipped API shape after origin-trial changes. Plan dual reporting for a while: hard-navigation metrics for cross-browser history, soft-navigation slices where Chromium support exists. That dual view is the same spirit as keeping lab and field clocks separate in synthetic versus real user monitoring.

Content that stays on screen across routes also matters. Soft-nav LCP from ICP only considers new paints tied to the initiating interaction. A persistent banner that was already the hard-nav LCP may not be the soft-nav LCP when only the body text changes. Deep links into the same URL as a hard load can report a different LCP element than an in-app soft navigation to that URL. Document that difference for clients so they do not treat soft-nav LCP as a drop-in twin of cold-load LCP.

Soft navigations versus scheduled PageSpeed Insights monitoring

Scheduled PageSpeed Insights and Lighthouse runs still measure full document loads of the URLs you list. They do not walk your SPA click path and emit soft-navigation entries for every in-app route. That limit is honest product scope, not a bug in Chrome 151. If checkout is only reachable after three client-side transitions from the marketing homepage, a lab run of the checkout deep link still helps. It remains a hard navigation to that URL, not a soft navigation from pricing.

Agencies need both layers. Lab schedules catch regressions on public URLs after deploys: third-party tags, template changes, CDN mistakes. Soft-navigation instrumentation (RUM or first-party PerformanceObserver pipelines) catches whether route transitions themselves stay within agreed LCP and INP bands for Chromium users. Confusing the two produces the same failure mode as treating a single PageSpeed Insights paste as Search Console status. We unpacked when spot checks stop scaling in PageSpeed Insights versus automated monitoring. For SaaS product surfaces that live almost entirely behind soft navigations, pair this with the URL priorities in performance monitoring for SaaS.

Apogee Watcher stays on the scheduled lab and portfolio side: multi-tenant site lists, mobile and desktop strategies, budgets, and alerts when a listed URL regresses. Soft-navigation and ICP observation belong in your RUM or custom instrumentation until field tooling and CrUX-style aggregation catch up to the new entries. Layer Watcher for deploy confidence across many hostnames. Layer soft-nav measurement for SPA route truth on the products that need it. Do not claim Watcher already scores soft navigations as a first-class metric.

Related navigation performance topics will show up later on our calendar, including back/forward cache restores and Speculation Rules prefetch or prerender. Soft navigations solve a different problem. They measure in-document route changes once those changes look like navigations to users and to Chrome.

What to tell clients after Chrome 151 soft navigations ship

Keep the retainer script short. Account managers need one shared wording so engineering and SEO are not arguing past each other in the same thread. Put the bullets below in the monthly review deck, not only in a Slack reply after a client escalates.

Soft navigations are Chrome's way to measure SPA-style route changes that update the URL and paint after a user action.
Chrome 151 exposes soft-navigation and interaction-contentful-paint so teams can report Core Web Vitals per soft navigation in Chromium, with careful URL and interactionId mapping.
Lab PageSpeed Insights schedules still verify listed URLs as full loads. Soft-nav quality needs RUM or custom observers on the SPA itself.
Field reports will lag while RUM vendors and aggregation pipelines adopt the shipped API. Do not promise overnight Search Console parity for soft-nav LCP.
Done means hard-nav lab budgets stay green on public URLs, and soft-nav instrumentation (where you invested) shows stable route LCP and INP for the journeys you named.

Avoid inventing a soft-nav "Good" threshold Chrome has not published as a Core Web Vitals programme change. Use the same discipline you already use for LCP and INP definitions. Label soft-nav slices as Chromium-route metrics until standards and tooling settle, and keep hard-navigation budgets as the client-facing language you already report.

FAQ

What are soft navigations in Chrome 151?

Soft navigations are client-side route changes that start from a user action, change the visible URL, and produce a visible paint. Chrome 151 ships soft-navigation and interaction-contentful-paint performance entries so those transitions can carry their own timing origin for Core Web Vitals-style measurement in Chromium. Older Chrome versions and other browsers may still report only classic document-level metrics.

Is Interaction Contentful Paint the same as LCP?

Not exactly. Interaction Contentful Paint entries describe contentful paints after interactions. For soft navigations, LCP for the route is taken from the largest matching ICP entry (via largestContentfulPaint / getLargestInteractionContentfulPaint()), mapped with interactionId, with times adjusted by the soft navigation startTime. Hard-navigation LCP still uses largest-contentful-paint for the initial load.

Do soft navigations change how PageSpeed Insights scores my SPA homepage?

A standard PageSpeed Insights or Lighthouse navigation still loads the URL you request as a document. Soft-navigation APIs affect what you can observe in the page after Chromium detects in-app transitions. They do not turn a single lab run into a full click-path audit of every SPA route.

Should we wait for CrUX before instrumenting soft navigations?

No. Instrument and verify detection in Chromium now if SPA routes are commercially important. Field aggregation and cross-browser coverage will take longer. Keep scheduled lab monitoring on the public URLs you already sell, and treat soft-nav metrics as an additional Chromium slice until your RUM vendor documents support.

Does Apogee Watcher measure soft navigations today?

Watcher schedules PageSpeed Insights-backed tests on listed URLs and stores history, budgets, and alerts for those loads. Soft-navigation and ICP observation require page-side or RUM instrumentation. Use Watcher for portfolio deploy monitoring; add soft-nav measurement where SPA route quality is the product risk.

Pick one SPA money path (pricing to checkout, search to product, dashboard to settings). On Chrome 151 or a flagged build, record a Performance panel trace while you click through, confirm soft-navigation markers fire, then attach a PerformanceObserver for soft-navigation and interaction-contentful-paint on staging. Write down which URLs get soft-nav LCP and which never meet the three heuristics. Put the public deep-link URLs for those destinations on a Watcher or PageSpeed schedule so hard-navigation regressions still alert after the next theme or tag change. Soft navigations close a measurement gap Chrome owns. Scheduled monitoring still closes the portfolio gap agencies own.

Chrome Cut Android Scroll Jank 48%: What to Check on Your Site

Wed, 29 Jul 2026 08:12:00 +0000

A client scrolls a product page on Android and the page hitches, but they blame the phone, the network, or "Chrome is slow." In July 2026 the Chromium team published how they reduced the frequency of janky scrolls in Chrome on Android by about 48% between 2023 and 2026. That work is real, but it still does not remove the cost of your JavaScript on the main thread, your scroll listeners, or UI that shifts while the finger is moving.

Scroll jank is a missed frame during scroll: the screen shows a stale scroll offset for a refresh cycle (about 16.7 ms on a 60 Hz display). Chrome's post focuses on consistent input-to-frame delivery inside a multi-process browser, but your site owns a different slice of the same problem: work that runs while Chrome is trying to produce the next frame. The sections below are a practical checklist for web teams, not a rehash of Input Vizard or Direct2Thread.

What Chrome fixed on Android scroll jank (and what it did not)

Petr Čermák's Chromium write-up describes instrumentation across the input-to-presentation pipeline, then a series of architectural projects: routing input away from a busy browser main thread, waiting briefly for late input after VSync, predicting scroll when input is delayed, cutting cross-process hops, moving browser-controls sync into Viz, and raising priority on Android input threads. The theme is consistency, so raw peak speed is not enough if one stage occasionally spikes and the frame deadline is missed.

None of that rewrites your page, so Chrome still has to run your scripts, apply your styles, and paint your DOM. If a scroll handler forces layout, if a third-party tag runs a long task mid-gesture, or if a sticky bar and an infinite-scroll feed fight for space, users still feel stutter on the same phone that benefits from Chrome's pipeline work. Treat the 48% figure as a browser-side win, but treat residual jank after a Chrome update as a site audit signal.

What is scroll jank on a website?

Scroll jank on a site shows up as hitching, rubber-banding that feels wrong, or content that jumps while the user is still dragging. It is related to, but not identical to, Core Web Vitals. Interaction to Next Paint (INP) measures responsiveness after interactions; Cumulative Layout Shift (CLS) measures unexpected layout movement. Heavy main-thread work during scroll can worsen both, and long tasks that block scrolling also show up as elevated Total Blocking Time (TBT) in lab runs. For metric definitions, see LCP, INP, and CLS explained and Understanding INP.

When a stakeholder says "scrolling feels bad on mobile," separate three causes before you open a hosting ticket:

Browser frame delivery (Chrome's domain; improving on Android).
Site main-thread and style work during scroll (your domain).
Layout that shifts while scrolling (your domain; often CLS).

Only the second and third belong on your sprint board after a Chrome release note.

How to reduce scroll jank: free the main thread during scroll

Chrome's post is blunt that a busy main thread was a major source of non-deterministic delay on the critical path of a scroll. On the web side, the same idea applies, so keep the main thread free while the user is scrolling, or the browser's smoother pipeline still waits on your work.

Long tasks and scroll handlers

Search the codebase for addEventListener('scroll', onscroll, touchmove, and libraries that attach scroll spies by default (analytics "scroll depth," sticky-header kits, parallax, lazy-load managers). For each listener, ask whether the work must run on every frame. Reading offsetWidth, writing styles, and querying layout in the same turn forces synchronous layout and burns the frame budget. Prefer reading positions in one pass, writing in another, or moving visual follow effects to CSS (position: sticky, transform) so the compositor can keep up.

If you only observe scroll position for analytics or lazy loading, register the listener with { passive: true } so the browser does not wait for your handler before continuing the scroll. If you must call preventDefault, you cannot be passive, so keep that handler tiny and defer expensive work with requestAnimationFrame or a short idle callback.

Long tasks from other sources still hitch scroll even when your scroll listener is clean. Third-party tags, hydration bursts, and theme scripts that parse large JSON on the main thread compete for the same thread Chrome needs for input. Our third-party scripts guide covers how to find the worst offenders; for lab blocking time, see FCP and TBT as supporting metrics.

Compositor-friendly motion

Animations and transitions that change top, left, width, or height on scroll tend to force layout and paint. Prefer transform and opacity for scroll-linked effects when you need motion at all. Many "scroll reveal" patterns are nicer as one-shot Intersection Observer callbacks than as continuous scroll math. If a design requires parallax, gate it behind a reduced-motion preference and test on mid-range Android devices, rather than only on a fast laptop with DevTools device mode.

Mobile scroll performance: sticky UI, infinite scroll, and late injection

Mobile scroll performance fails in patterns that look fine in a quiet desktop lab. Sticky headers that resize on scroll, cookie banners that inject after first paint, chat widgets that open over content, and infinite-scroll lists that insert rows without reserved space all create layout work and CLS while the finger is moving. CLS deep-dive covers sizing and late injection, so the scroll-specific rule is simple: do not change layout geometry in response to scroll if you can help it.

Infinite scroll deserves its own check. Each batch of cards should reserve height (skeletons or aspect-ratio boxes) before images and ads arrive. Intersection Observer is usually enough to trigger fetches; a continuous scroll listener that measures every card on every frame is not. After a theme or tag change, re-test the primary feed URL on a real phone or a throttled mobile lab profile, because desktop CrUX can hide the hitch.

Form factor splits matter for monitoring too. Schedule and report mobile separately from desktop, as in mobile versus desktop Core Web Vitals. Chrome's Android work improves one side of the field; your desktop Safari or Chrome desktop users still see whatever your handlers do.

What to check on your site after Chrome's scroll jank fixes

Use this as a pull-request and release gate, not as a one-off audit PDF.

List every scroll / touchmove / wheel listener on priority templates (homepage, PDP, article, category feed).
Mark each as passive observe, must preventDefault, or removable.
Remove or rewrite handlers that force layout (getBoundingClientRect loops, style writes) on every event.
Move scroll-linked visuals to CSS sticky / transform where possible.
Reserve space for lazy images, embeds, and infinite-scroll rows before they load.
Audit third-party tags for long tasks during the first scroll gesture after load.
Respect prefers-reduced-motion for decorative scroll effects.
Re-run mobile lab (PageSpeed Insights or Lighthouse) on the URLs you changed; store the before/after.
Watch INP and CLS field bands on those URLs for the following weeks; do not expect overnight CrUX flips (why field lags lab).

One green Lighthouse paste after a Chrome update is not proof the portfolio is smooth, because spot checks miss the template you did not open. That gap is why PageSpeed Insights versus automated monitoring exists for multi-site teams.

How to monitor mobile scroll performance across a client portfolio

Agencies cannot feel every client's feed on every phone after every plugin update. Put the money URLs (feeds, PDPs, long articles) on a mobile schedule, set budgets on LCP, INP, and CLS, and alert when a release regresses lab vitals even if scroll "feels" fine in the office. Match frequency to risk using how to schedule PageSpeed monitoring.

Apogee Watcher runs scheduled PageSpeed Insights-backed tests across many sites, keeps mobile and desktop as separate strategies, and stores history so you can show before/after when a sticky header or tag manager change lands. We do not claim a dedicated "scroll jank" metric in-product, but we give you the Core Web Vitals and supporting lab timings that move when main-thread and layout cost during scroll get worse, across the portfolio without pasting PageSpeed Insights links into a spreadsheet. Layer Watcher beside RUM or session replay when you need gesture-level proof on a single flagship site.

FAQ

Did Chrome fix scroll jank so sites no longer need to care?

No. Chrome reduced how often its own pipeline misses frame deadlines on Android, but your scroll handlers, long tasks, and layout shifts during scroll still run on the page. Browser gains and site work stack; they do not replace each other.

Is scroll jank the same as poor INP or CLS?

Not exactly: scroll jank is missed frames during scroll, while INP scores interaction latency and CLS scores unexpected layout shift. The same main-thread and layout habits often drive all three, so fixing scroll handlers and reserved space usually helps the vitals you already report.

How do I find scroll listeners that hurt mobile scroll performance?

Search the bundle and third-party tags for scroll and touch listeners, then profile a mid-range Android device (or a throttled lab profile) while scrolling the money URL and watch for long tasks and forced layout in Performance traces. Start with themes, sticky headers, analytics scroll depth, and infinite-scroll libraries.

Should we re-test after every Chrome release?

Re-test after your own releases first; when Chrome announces scroll or input pipeline changes, spot-check one or two mid-range Android devices on a priority URL, then rely on scheduled mobile monitoring for the rest of the portfolio rather than a manual PageSpeed Insights day.

On Monday, pick one client feed or article URL that drew a "scrolling feels bad" comment. Open the Performance panel, scroll for ten seconds on a mobile profile, and list every long task and layout shift during that gesture. Fix or remove one handler, reserve space for one late-loading block, then store a mobile lab run. If you manage many sites and need that history on a schedule, start a free trial of Apogee Watcher or run a free domain PageSpeed check on the URL that complains most on phones.

Trying Declarative Partial Updates: A Future API for Replacing HTML Later

Sun, 05 Jul 2026 10:54:28 +0000

Hoi hoi!

I'm @nyaomaru, a frontend engineer who was cheering for the World Cup during tropical nights in the Netherlands while nearly melting from heat exhaustion. ⚽ (But yesterday was comfortable 😺)

How do you usually build frontend applications?

Do you build SPAs with React / Vue / Svelte?

Do you use SSR / SSG / ISR frameworks like Next / Remix / Nuxt / Astro?

There are many ways to build frontend applications, but today it is very common to update the DOM on the client side using JavaScript.

Even when using UI libraries and frameworks like React / Vue / Svelte, or SSR frameworks like Next / Remix / Nuxt / Astro, there are still many cases where part of the screen is eventually updated by client-side JavaScript.

But is that really always the best answer?

Are there cases where we are forcing JavaScript on the client to handle work that could naturally be handled on the server?

In response to that kind of question, the Chrome team introduced an experimental API called DPU, or Declarative Partial Updates. 🚀

{% embed https://developer.chrome.com/blog/declarative-partial-updates?hl=en %}

In this article, I want to explore what Declarative Partial Updates are, what problems they try to solve, and why they might matter.

I will focus especially on the out-of-order streaming mechanism that can replace parts of HTML later without writing client-side JavaScript for the replacement itself.

Let's dive in!

🧩 What are Declarative Partial Updates?

Declarative Partial Updates are, roughly speaking

A mechanism where you declare part of your HTML as “this area will be replaced later”, and then update only that part with HTML that arrives later.

For example, imagine you want to return the overall page HTML immediately, but some data is slower to fetch.

The header is instant
The layout is fast
The user profile is also pretty fast
But only the recommendations API is slow

In that case, we often show a loading state on the client, fetch data, and update the DOM with JavaScript. In React, you might reach for something like <Suspense>.

With DPU, the server can first return HTML like this.

<section>
  <h2>Recommendations</h2>

  <?start name="recommendations">
    <p>Loading recommendations...</p>
  <?end>
</section>

The area surrounded by <?start name="recommendations"> and <?end> is a region that can be replaced later.

Then, when the recommendations HTML is ready on the server, it can stream HTML like this later.

<template for="recommendations">
  <ul>
    <li>Advanced CSS Layouts</li>
    <li>Modern HTML APIs</li>
    <li>Web Performance Basics</li>
  </ul>
</template>

At that point, the browser finds the region named recommendations and replaces the loading UI with the contents of this <template>.

Wait, does that feel a bit weird?

Exactly. The wild part is that up to this point, we did not write any JavaScript for the replacement, and no framework is involved.

In other words, you no longer need to write client-side JavaScript like this just to replace that area:

const element = document.querySelector("#recommendations");
element.innerHTML = html;

You stream HTML, and the browser understands where that HTML should go.

That is the interesting part of Declarative Partial Updates.

DPU also has <?marker>, not only <?start> / <?end>.

<?marker> is basically a marker that says, “insert later HTML here.”

<div>
  <?marker name="placeholder">
</div>

<template for="placeholder">
  <p>Here is streamed content!</p>
</template>

In this case, the browser finds the marker named placeholder and inserts the contents of the later <template for="placeholder"> at that position.

On the other hand, the <?start> / <?end> pair used mainly in this article is for showing placeholder content, such as a loading UI, and replacing that entire range later.

So, roughly

<?marker> means “insert here”
<?start> / <?end> means “replace this range”

That mental model should be enough to start.

Note

<?marker> can also be used by leaving the same marker inside streamed content, which lets you append list items one by one. That is pretty interesting too.

In the first half of this article, I focus mainly on replacing loading UI, so I mostly use <?start> / <?end>.

In the later sample, I also try an example that uses <?marker> to append asset links sequentially.

🤔 Why do we need Declarative Partial Updates?

At this point, you might think

Wait, frameworks like React or Astro can already do this, right?

Yes. They can.

With React / Vue / Svelte / Next / Remix / Nuxt / Astro, you can show loading states, receive API results, and update parts of the screen. Many of us do this every day.

But wait a second. A lot of that is implemented by client-side JavaScript updating the DOM, right?

A common flow looks like this:

The server returns HTML
The browser displays the HTML
Client-side JavaScript is loaded
JavaScript calls an API
The API result is put into state
The framework updates the DOM

Of course, this is an extremely common frontend architecture today.

But if part of the screen is “something the server can already produce as HTML”, do we really need to make client-side JavaScript do that work every time?

For example, the recommendations HTML can be generated on the server like this:

<ul>
  <li>Advanced CSS Layouts</li>
  <li>Modern HTML APIs</li>
  <li>Web Performance Basics</li>
</ul>

If all we want to do is send that to the browser, it can feel a bit indirect to do this.

fetch("/api/recommendations")
  .then((res) => res.json())
  .then((items) => {
    setRecommendations(items);
  });

You fetch JSON, convert it to HTML on the client, update state, and then update the DOM.

That is convenient, but it is also a bit roundabout.

What makes DPU interesting is that it points in another direction

If the server can produce HTML, why not stream that HTML directly and let the browser insert it into the right place?

So DPU is not a replacement for React / Vue / Svelte. It is more like a lower-level browser primitive.

It may allow the browser to understand, as part of HTML itself, some of the partial update work that frameworks currently handle.

If that happens, the boundary between client-side responsibility and server-side responsibility becomes even more important.

What can be done with HTML?
What should be done with JavaScript?

By redesigning these boundaries and declaring things in a way that fits the browser, we may be able to unlock browser capabilities that we are not fully using yet.

But we should not misunderstand the client still has responsibilities.

This discussion is not about replacing state management, and interactive features still need JavaScript.

For example, forms, modals, charts, and similar UI should still be managed on the client side, while static text or server-generated HTML based on slower API responses may be a better fit for HTML streaming.

The responsibility split becomes more complex, but the UX may improve a lot. This is definitely something worth watching.

🏠 This may expand what SPAs can do

DPU is not about rejecting SPAs.

Personally, I see it as something that may expand the possibilities of SPAs.

Until now, SPAs have often followed this mental model.

Fetch data as JSON
    ↓
Put it into client-side state
    ↓
Re-render components
    ↓
Update the DOM

But if DPU and the new HTML insertion / streaming APIs become available, another option appears.

The server returns HTML
    ↓
HTML is streamed
    ↓
The browser inserts it into the existing DOM

That means an SPA could potentially choose different update strategies for different parts of the UI:

Fetch JSON and render on the client
Generate HTML on the server and insert it directly
Return only the shell initially, then stream slower parts later
Perform page-transition-like updates with HTML partials

That is really interesting.

SPAs often carry the image of “doing everything with client-side JavaScript”, but they may become more hybrid in the future. The meaning of the word SPA itself may change.

State that belongs on the client stays on the client
HTML that can be produced on the server is produced on the server

And the browser does not merely display that HTML. It also understands where and how to insert it.

If this direction continues, frontend architecture may become even more flexible and deeper than it is today.

🧪 APIs for streaming HTML from JavaScript are also coming

The interesting part of DPU is not only out-of-order streaming with <template for="...">.

The Chrome team is also proposing a new set of APIs for inserting and streaming HTML from JavaScript.

Even today, there are several ways to dynamically insert HTML.

element.innerHTML = html;
element.outerHTML = html;
element.insertAdjacentHTML("beforeend", html);

But they all have slightly different behavior.

For example:

Does it overwrite existing content?
Does it append after the existing content?
Are <script> tags executed?
What happens with sanitization?
How does it interact with Trusted Types?

There are a lot of subtle differences.

Honestly, I do not think many developers can confidently explain all of those differences from memory. I definitely cannot.

The new APIs try to make HTML insertion easier to understand with more consistent names.

For example, static HTML insertion looks like this.

const newHTML = "<p>This is a new paragraph</p>";
const contentElement = document.querySelector("#content-to-update");

contentElement.setHTML(newHTML);

This is not an API that appends to the end, like insertAdjacentHTML("beforeend", html). It replaces the existing contents of contentElement with newHTML.

A useful way to understand the difference is

setHTML() is the safer API that runs through a sanitizer
setHTMLUnsafe() disables the sanitizer by default and lets you handle HTML more directly

Then comes the really interesting part of streaming versions.

const contentElement = document.querySelector("#content-to-update");

const response = await fetch("/api/content.html");

response.body
  .pipeThrough(new TextDecoderStream())
  .pipeTo(contentElement.streamHTMLUnsafe());

This is pretty wild.

It means we may be able to take HTML returned by fetch() and stream it directly into an element without waiting for the entire response to finish downloading.

SPAs have not benefited much from HTML streaming after the initial document load.

The initial document can be streamed from the server, but later screen updates often become JSON fetch + client render.

With APIs like this, SPA updates may also be able to benefit from HTML streaming.

That is why I think this may expand the possibilities of SPAs.

⚠️ “unsafe” does not mean “never use it”

When you see a name like streamHTMLUnsafe(), you might think

Unsafe!? That sounds terrifying.

I thought that too at first.

But this unsafe does not mean “you must never use it.” It is closer to a warning that the sanitizer is disabled by default, so you need to think carefully about whether the input is trusted.

For example, it would be dangerous to stream user-generated HTML directly into the DOM.

But if the HTML is generated by your own trusted server, there may be valid use cases.

Of course, before using this in production, you need to think carefully about sanitizers, Trusted Types, script execution, browser support, and other security concerns.

➕ What happens when DPU and the streaming APIs are combined?

This is the most interesting part.

DPU’s <template for="..."> and the new HTML streaming APIs are separate APIs.

But combining them makes the story even deeper.

For example, imagine placing placeholders in an SPA screen.

<main>
  <?start name="page-title">
    <h1>Loading...</h1>
  <?end>
  
  <?start name="page-content">
    <p>Loading content...</p>
  <?end>
</main>

Then, during a page update, the server streams HTML.

<template for="page-title">
  <h1>Dashboard</h1>
</template>

<template for="page-content">
  <section>
    <p>This is the dashboard content.</p>
  </section>
</template>

Instead of manually targeting the DOM with JavaScript.

document.querySelector("#page-title").innerHTML = titleHTML;
document.querySelector("#page-content").innerHTML = contentHTML;

the browser may be able to understand where page-title and page-content should be applied.

In other words, even in SPA-style page transitions, something like this may become possible.

Fetch a new page's HTML partial
    ↓
Stream the HTML
    ↓
Update only the necessary places via template for

Part of the work that frameworks currently handle with Virtual DOM, compilers, or fine-grained reactivity may be shifted to browser-native HTML streaming / partial updates.

That makes DPU feel like more than just a small HTML API. It feels like something that could expand the design space of frontend architecture.

Of course, this is still experimental. This is not a “let's all use this in production right now” kind of API.

But the old assumption

An SPA fetches JSON and renders on the client

may start to change.

HTML may evolve from “a static document loaded once at the beginning” into “a UI unit that can be streamed, replaced, and updated.”

That is pretty exciting, right?

🚀 Trying it with Node.js DPU samples

So far, we have talked about the concept. I also built a small Node.js sample app to try this out.

{% embed https://github.com/nyaomaru/declarative-partial-updates-sample %}

Note

This is an experimental feature, so you need Chrome Canary (Chrome v148 or later) or a Chrome build that includes this feature, with the experimental flag enabled.

Open the following URL in Chrome’s address bar:

chrome://flags/#enable-experimental-web-platform-features

Enable it, click “Relaunch”, and then run the sample. This article assumes a supported build with this flag enabled.

The demo app has roughly three pages:

/              ... Document streaming
/hybrid-shell  ... Hybrid shell + streamed HTML route updates
/set-apis      ... Static / Streaming HTML APIs

The first page, /, demonstrates DPU out-of-order streaming.

The server first returns an HTML shell, and slower server-rendered fragments are streamed later as <template for="...">.

For example, the initial HTML contains a placeholder.

<article class="panel">
  <h2>Recommendations</h2>

  <?start name="recommendations">
    <p class="loading">Waiting for recommendations...</p>
  <?end>
</article>

At this point, the browser shows the loading UI.

Then, once the recommendations HTML is ready on the server, it streams a chunk.

<template for="recommendations">
  <ul class="list">
    <li>Advanced CSS Layouts</li>
    <li>Modern HTML APIs</li>
    <li>Web Performance Basics</li>
  </ul>
</template>

The browser finds the DPU range named recommendations and replaces the loading UI with the list.

On this page, I stream multiple named regions at different timings, not only recommendations:

hero image
metric
asset strip
team activity
streamed code block

The asset strip also uses <?marker>. The initial HTML has a marker.

<section class="panel asset-panel">
  <h2>Streamed public assets</h2>
  <div class="asset-grid">
    <?marker name="asset-list">
  </div>
</section>

Then the server streams chunks one by one whenever each asset link becomes ready.

<template for="asset-list">
  <!-- streamed asset link -->
  <?marker name="asset-list">
</template>

By leaving the same marker again inside the streamed content, the next asset link can continue to be appended in the same place.

So HTML does not have to wait until everything is complete from top to bottom. Fragments can be streamed in later as soon as they are ready.

That is the really interesting part of DPU.

Note

<template for> has several subtle rules, including constraints related to parent elements.

This demo is a sample for exploring the direction of the API, but if you want to use it in production someday, you should carefully check the applicable range of <template for>, DOM movement during streaming, Trusted Types, sanitizers, and related details.

🌓 Trying a hybrid shell style architecture

Next, /hybrid-shell demonstrates streaming HTML route updates inside a hybrid shell style architecture.

This is not a “pure SPA where everything is rendered on the client”. It is closer to an architecture where the whole document is not reloaded, the URL changes through the History API, and only the route content inside the shell is updated.

The goal is

Keep client-side state alive, while replacing only the route content with server-generated HTML.

For example, this page has a counter:

<div>
  Counter: <strong id="counter">0</strong>
  <button id="increment" class="primary" type="button">Increment</button>
</div>

This counter is managed by client-side JavaScript.

document.querySelector("#increment").addEventListener("click", () => {
  counter.textContent = String(Number(counter.textContent) + 1);
});

So this is clearly a client-side responsibility.

On the other hand, route content is fetched from the server as HTML.

const loadRoute = async (route, { push = false } = {}) => {
  setActiveRoute(route);

  if (push) {
    const nextUrl =
      route === "dashboard"
        ? "/hybrid-shell/dashboard"
        : `/hybrid-shell/${route}`;
    window.history.pushState({ route }, "", nextUrl);
  }

  const response = await fetch(`/partials/hybrid-shell/${route}`);
  view.replaceChildren();

  if ("streamHTMLUnsafe" in Element.prototype && response.body) {
    await response.body
      .pipeThrough(new TextDecoderStream())
      .pipeTo(view.streamHTMLUnsafe());
    return;
  }

  const template = document.createElement("template");
  template.innerHTML = await response.text();
  view.replaceChildren(template.content.cloneNode(true));
};

What this does is not “fetch JSON and render components on the client.” Instead, it streams HTML generated by the server directly into the view.

The counter state remains on the client.

That means we can split responsibilities:

Interactive state such as the counter belongs to the client
Server-generated route body can be streamed as HTML

This feels close to the thinking behind island architecture in frameworks like Astro / Fresh.

Instead of making the client do everything, we separate HTML that can be returned statically or from the server from interactive client state.

Personally, I find this very interesting.

At the very least, a shell with SPA-like navigation does not have to mean “everything is rendered by client-side JavaScript.” It may also expand into a hybrid shape that combines client state with streamed HTML.

Note

This /hybrid-shell sample is not a demo that replaces a range inside the shell using DPU’s <?start> / <template for>.

The Chrome team article also introduces the possibility of SPA-style page loads by combining streamHTMLUnsafe() and <template for>.

However, in my local tests, I could not confirm that streaming <template for="..."> into streamHTMLUnsafe() in this shell architecture updates an existing DPU range.

The SPA-style page load described in the official article seems to point toward an outline page with processing instructions, where the new page’s <template for> elements are streamed toward the end of the HTML and slotted into those instructions.

So in this /hybrid-shell sample, I do not handle DPU range replacement. Instead, I use the HTML streaming insertion API to stream server-generated route partials directly into #hybrid-shell-view.

🎁 Trying Static / Streaming HTML APIs

Finally, /set-apis tries the new HTML insertion / streaming APIs separately from DPU’s out-of-order streaming.

This page first checks whether the browser has the APIs.

support.innerHTML = `
  <ul class="list">
    <li>setHTMLUnsafe: ${"setHTMLUnsafe" in Element.prototype}</li>
    <li>streamHTMLUnsafe: ${"streamHTMLUnsafe" in Element.prototype}</li>
  </ul>
`;

For static insertion, if setHTMLUnsafe() is available, the demo uses it. Otherwise, it falls back to <template> and replaceChildren().

if ("setHTMLUnsafe" in Element.prototype) {
  staticTarget.setHTMLUnsafe(markup);
  return;
}

const template = document.createElement("template");
template.innerHTML = markup;
staticTarget.replaceChildren(template.content.cloneNode(true));

For streaming insertion, it pipes the fetched HTML response directly into streamHTMLUnsafe():

const response = await fetch("/partials/set-apis/stream");

streamTarget.replaceChildren();

if ("streamHTMLUnsafe" in Element.prototype && response.body) {
  await response.body
    .pipeThrough(new TextDecoderStream())
    .pipeTo(streamTarget.streamHTMLUnsafe());
  return;
}

If this works, we can stream chunks into an existing element as they arrive, instead of waiting until the entire HTML response has downloaded and inserting it all at once.

Traditionally, SPAs could benefit from HTML streaming for the initial document, but subsequent screen updates often became JSON fetch + client render.

With APIs like this, SPAs may be able to benefit from HTML streaming even for later updates.

That is the exciting part of DPU and the new HTML streaming APIs.

The static insertion partial is returned from /partials/set-apis/static, and the streaming insertion partial is returned from /partials/set-apis/stream.

🎯 Summary

In this article, I looked at Declarative Partial Updates introduced by the Chrome team.

Declarative Partial Updates are, roughly

A mechanism where you declare part of your HTML as “this area will be replaced later”, and then update only that part with HTML that arrives later.

Of course, DPU does not replace React / Vue / Svelte / Next / Remix / Nuxt / Astro.

Interactive UI, client-side state management, forms, modals, charts, drag and drop, and similar features still need JavaScript.

But on the other hand, there may be more cases where we do not need to handle everything with client-side JavaScript.

HTML that can be generated on the server should be generated on the server
State that should be managed on the client should be managed on the client

And the browser may come to understand not only how to display HTML, but also where streamed HTML should be inserted.

If this responsibility split progresses, frontend architecture may become more hybrid.

Especially for SPAs, there may be another path beyond

Fetch JSON and render on the client

Instead, we may also be able to

Fetch / stream HTML partials and update via browser-native behavior

I do not see this as the end of SPAs. I see it as something that may expand what SPAs can do.

This is still experimental, so it is not an API to use in production right away.

But the direction where HTML changes from “a document loaded once at the beginning” into “a UI unit that can be streamed, replaced, and updated” feels very important for the future of frontend development.

DPU is definitely something to keep an eye on. 😺

References

https://developer.chrome.com/blog/declarative-partial-updates?hl=en

https://github.com/WICG/declarative-partial-updates

https://github.com/GoogleChromeLabs/template-for-polyfill

https://github.com/GoogleChromeLabs/html-setters-polyfill

https://github.com/nyaomaru/declarative-partial-updates-sample

Internet Identity Crisis: GA4 Is Blind, Is Your Web Ready for 1.3 Billion New "AI Citizens"?

Tue, 30 Jun 2026 15:11:35 +0000

In early June 2026, Matthew Prince – CEO and co-founder of Cloudflare – confirmed a historic milestone on X (Twitter): For the first time in internet history, automated bot traffic has officially surpassed human traffic.

According to real-time data from Cloudflare Radar, bots now account for 57.4% - 57.5% of all global HTTP requests, pushing human activity down to just over 42%. This monumental crossover arrived 18 months earlier than Cloudflare’s original forecasts, driven entirely by the explosive growth of LLM Scrapers and Agentic AI.

1.3 Billion "AI Citizens" with No Human Presence

At major tech events like Microsoft Build, Microsoft has consistently highlighted a stark projection: The world is on track to reach 1.3 billion AI Agents working alongside humans by 2028.

This vision is being aggressively pushed by both Microsoft CEO Satya Nadella and Microsoft AI CEO Mustafa Suleyman, with declarations that fundamentally reshape the web:

The Shift to the "Open Agentic Web": The internet will no longer be a place where humans click through individual apps. Instead, it will be an ecosystem where AI Agents interact directly with each other and web databases to execute tasks on behalf of users.
Identity for AI Agents: Satya Nadella stated that since AI Agents can operate autonomously and consume actual budgets, they must be granted their own digital identities (IDs), access rights, and strict monitoring mechanisms—just like a real employee.
The Modern Turing Test: Mustafa Suleyman proposed a modern economic Turing test for agents: Can an AI agent legally plan and turn $100,000 into $1,000,000 in the real economy? He believes this milestone is closer than we think.

As web developers, we are transitioning rapidly from a Human-to-Machine web to a Machine-to-Machine infrastructure.

When Traditional Analytics (GA4) Goes Completely Blind

The old internet business model—relying on human views and clicks to generate ad revenue—is crumbling. When an AI Agent visits your site to extract data, it fires thousands of background HTTP requests in seconds, grabs the exact data it needs, and leaves without ever looking at a single ad banner.

More critically, classic analytical tools like Google Analytics 4 (GA4) are completely blind to these entities. GA4 cannot distinguish between a real human user with true transactional intent and the massive waves of "ghost traffic" constantly scraping your site to train foundation models.

Coming from my own experience operating a web project optimized for bots, I realized a major gap: Webmasters currently have no visual tool to see how their website actually looks through the "eyes" of an AI Agent.

Hands-on: Measuring Your Site's LLM Compatibility (Agent Readiness Score - ARS v1)

To solve this exact pain point, I built and officially published a free extension on the Chrome Web Store (which also works on Chromium-based browsers like Edge): AgentShare Agent Readiness.

The tool allows you to instantly scan any domain to evaluate its AI transparency and bot friendliness based on the ARS v1 specification. It breaks down critical criteria such as:

The existence of next-gen AI discovery configurations like llms.txt or llm.txt.
Crawler policies in robots.txt regarding major AI bots (OpenAI, Google, Anthropic, etc.).
Server overload risks and traffic identification gaps.

Just for fun, I used my own extension to scan our very own coderlegion.com, and the result was 22/100 points (Low readiness) as shown below:

Of course, this is just a playful test since CoderLegion is fundamentally a space built for human-to-human developer connections. But for your SaaS projects, technical documentation sites, or e-commerce platforms—where being indexed properly determines whether an AI Agent will recommend your product to an end-user—a 22 score should be an immediate wake-up call.

Let's Discuss

The internet rules are changing daily. Cloudflare is dropping free bot-blocking tools, Microsoft is building the Agentic Web, but what are you doing to prepare your tech stack? Are you opening your doors to LLM scrapers or shutting them down?

I'd love for you to try out the extension, check your own website's "Agent-readiness," and drop your harshest technical feedback or feature requests right in the comments below!

Try the Extension on Chrome Web Store: AgentShare Agent Readiness

Every Website You Visit Is Profiling You - Here's the Technical Reality (And How to Fight Back)

Wed, 29 Apr 2026 06:35:25 +0000

Open Chrome DevTools on any popular website. Click the Network tab. Reload the page.
Count the third-party requests.
On a typical news site, you'll see 40–80 requests going out - not to the site you're visiting, but to trackers, ad networks, analytics platforms, and data brokers you never agreed to interact with. Google, Facebook, Amazon, and dozens of smaller surveillance companies are watching every click, scroll, and pause.
Most users have no idea. Most developers do - and still underestimate the scale of it.

What's Actually Happening Under the Hood
When you load a page with embedded trackers, here's the flow:

Your browser fetches the HTML from the server
The page includes third-party tags, tracking pixels (1×1 tags), and invisible iframes
These fire requests to tracker domains - passing your IP, User-Agent, referrer, cookies, and often fingerprinting data (screen resolution, installed fonts, WebGL renderer, etc.)
The tracker correlates this with your identity across thousands of other sites using the same embedded scripts
A profile is built - silently, continuously, without your consent

The worst part? Many of these trackers bypass cookie consent banners entirely. Fingerprinting doesn't need cookies. It needs nothing from you except a browser that renders JavaScript.
Here's a quick example of what a fingerprinting script might read:
javascript// Trackers collect this without ever asking permission

const fingerprint = {
  screen: `${screen.width}x${screen.height}`,
  timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
  languages: navigator.languages,
  platform: navigator.platform,
  hardwareConcurrency: navigator.hardwareConcurrency,
  canvas: getCanvasFingerprint(), // unique per device
  webGL: getWebGLFingerprint(),   // unique per GPU
};

This combination is unique enough to identify ~99.5% of browsers - no cookies required.

The Scope of the Problem: Data Breaches
Tracking isn't the only threat. Your data - email, passwords, phone numbers - lives in hundreds of databases you've signed up for over the years. When those databases are breached, your credentials end up on dark web forums.
In 2024 alone:

National Public Data leaked ~2.9 billion records including SSNs
Ticketmaster exposed 560 million customer records
Dell leaked data of 49 million customers

If your email has been around for more than a few years, it's almost certainly in at least one breach database. Most people only find out when their accounts start getting compromised.

Enter Digital Shield: A Technical Overview
Digital Shield is a Chrome extension built to tackle both of these problems - real-time tracker blocking and proactive breach monitoring - in a single, lightweight tool.
Here's what it actually does under the hood:
️ Tracker & Ad Blocking
Digital Shield intercepts outgoing network requests using Chrome's declarativeNetRequest API (the modern, privacy-preserving replacement for webRequest). It matches requests against a regularly updated blocklist of known tracker, ad, and malware domains - and drops them before they ever leave your browser.
The result: pages load faster (fewer requests), less bandwidth is consumed, and trackers never receive your data in the first place.
️ SpyGraph - Visual Tracker Intelligence
This is the feature developers will find most interesting. SpyGraph gives you a real-time visualization of which trackers are present on any page you visit - categorized by type (ad network, analytics, social widget, fingerprinting, etc.) and by company.
It's essentially a live view of what Chrome DevTools Network tab shows, presented in a way that's immediately readable. Great for auditing sites you're building, not just sites you're browsing.
AI-Powered Privacy Policy Summarizer
Privacy policies average 4,000–10,000 words and are deliberately written to obscure what data is actually collected. Digital Shield uses AI to summarize them into plain English - what data is collected, how it's used, and what your rights are - in seconds.
Useful for developers evaluating third-party SDKs or APIs for their own projects: you can quickly understand the data implications before integrating.
Dark Web Breach Monitoring
Enter your email address and Digital Shield continuously monitors breach databases. If your credentials appear in a newly exposed dataset, you get an immediate alert so you can rotate passwords before attackers use them.
Unlike one-off checks on sites like HaveIBeenPwned, this is ongoing monitoring with instant notifications.
Parental Controls (Unique Feature)
This is where Digital Shield differentiates from most tracker blockers. It includes:

Content filtering for adult, gambling, and violent content
Bedtime Scheduler - automatically locks browsing during set hours
Instant Pause - one-click to freeze all browsing
Kids Safe Browsing Mode - restricts to a whitelist of safe sites

For developers who are also parents, this is a practical tool for protecting kids on shared devices without needing a separate parental control app.
Secure Password Generator
Built-in cryptographically secure password generation - useful for quickly generating strong credentials without reaching for a separate tool.

Performance Impact
A common concern with extensions: do they slow down browsing?
Because Digital Shield uses declarativeNetRequest rather than the older webRequest API, blocking happens at the browser engine level - not in the extension's JavaScript runtime. This means:

No added latency from extension processing
Rules are compiled and matched natively by Chrome
In practice, pages often load faster because 30–60% fewer network requests are made

Why This Matters for Developers Specifically
As developers, we're in an interesting position:

We build the web - many of us embed Google Analytics, Facebook Pixel, or third-party SDKs in our projects. Understanding what those tools actually do to users is part of building responsibly.
We're high-value targets - developer accounts (GitHub, npm, AWS, cloud providers) are extremely valuable to attackers. A single compromised credential can expose entire codebases or production infrastructure.
We test on real browsers - SpyGraph and the privacy policy summarizer are genuinely useful QA and due diligence tools, not just consumer features.
We have families - the parental control features are for the same reason anyone needs them.

Install & Try It
Digital Shield is free to install with premium features available.
Chrome Web Store: Install Digital Shield
After installing, try this:

Open SpyGraph on a major news site - the number of trackers will surprise you
Run a breach check on your main email address
Open DevTools Network tab before and after - compare the request count

The difference is immediately visible.

The Bigger Picture
The web's surveillance economy is a structural problem. Ad-funded business models create financial incentives to collect as much data as possible. Users - even technically sophisticated ones - are largely powerless against fingerprinting at the browser level.
Extensions like Digital Shield sit at the only practical intervention point: the browser, where requests can be intercepted before they leave your machine.
This isn't a perfect solution. VPNs, private DNS, and browser hardening all have roles to play. But for most people - including developers who want a single tool that handles the most common threats - it's a meaningful and immediate improvement.
Privacy should be the default, not a premium feature. Tools that move the web in that direction are worth knowing about.

Have questions about how the tracker blocking works technically, or want to discuss the fingerprinting threat model? Drop a comment below.

Chrome 144 Introduces the Element: Declarative Location Access for Modern Web Apps

Mon, 13 Apr 2026 10:42:28 +0000

Chrome 144 Introduces the `<geolocation>` Element: Declarative Location Access for Modern Web Apps

Chrome 144 introduces a new declarative <geolocation> HTML element that changes how web applications request location access. Instead of calling navigator.geolocation.getCurrentPosition() imperatively from JavaScript, developers can now place a browser-controlled element directly in the DOM.

This post is for frontend engineers, platform engineers, and privacy-conscious developers who want to understand how this new model works and whether they should migrate.

By the end of this article, you'll understand:

What the <geolocation> element is
How it works internally
How it compares to the traditional Geolocation API
How to implement it with proper fallback support

Why Chrome Introduced `<geolocation>`

Historically, location access was triggered via JavaScript:

navigator.geolocation.getCurrentPosition(success, error);

This caused several problems:

Permission prompts appearing on page load
Users denying requests due to poor timing
Quiet permission blocking by browsers
Complicated permission state handling in code

The <geolocation> element solves this by:

Requiring explicit user interaction
Providing a visible, browser-controlled UI
Reducing boilerplate permission code
Improving recovery from previously denied states

Chrome origin trials showed measurable improvements in successful permission grants and recovery rates.

What Is the `<geolocation>` Element?

The <geolocation> element is part of the WICG "Permission Elements" proposal. It acts as a declarative wrapper around the existing Geolocation API.

It renders as a browser-controlled button such as:

When clicked:

The browser shows the location permission dialog.
If granted, it dispatches a location event.
The element exposes either:
- position (success)
- error (failure)

Attributes Explained

`autolocate`

Automatically attempts to retrieve location when inserted into the DOM — only if permission was already granted.

<geolocation autolocate></geolocation>

It does not trigger surprise permission prompts.

`watch`

Continuously tracks position updates, similar to watchPosition().

<geolocation watch></geolocation>

Without watch, it behaves like getCurrentPosition().

`accuracymode`

Controls precision level.

<geolocation accuracymode="precise"></geolocation>

Possible values:

"approximate" (default)
"precise"

When set to "precise", the browser may:

Change icon (crosshair instead of pin)
Update label text
Request higher accuracy internally

Basic Implementation

Minimal example:

<geolocation onlocation="handleLocation(event)"></geolocation>

<script>
function handleLocation(event) {
  if (event.target.position) {
    const { latitude, longitude } = event.target.position.coords;
    console.log("Location:", latitude, longitude);
  } else if (event.target.error) {
    console.error("Error:", event.target.error.message);
  }
}
</script>

No permission logic required.

The browser handles:

Permission prompts
Recovery dialogs
Error states

Adding Progressive Enhancement (Fallback)

You must support non-Chrome browsers.

<geolocation id="geo">
  <button id="fallback-btn">
    Use my location
  </button>
</geolocation>

<script>
if ('HTMLGeolocationElement' in window) {
  const geo = document.getElementById('geo');
  geo.addEventListener('location', () => {
    if (geo.position) {
      console.log(geo.position.coords);
    }
  });
} else {
  document.getElementById('fallback-btn')
    .addEventListener('click', () => {
      navigator.geolocation.getCurrentPosition((pos) => {
        console.log(pos.coords);
      });
    });
}
</script>

This ensures compatibility across browsers.

Browser UI Behavior

When clicked, Chrome displays the standard location permission dialog:

If previously denied, Chrome shows a recovery prompt:

This makes permission recovery significantly easier compared to manual browser settings navigation.

Styling Restrictions (Security Guardrails)

To prevent abuse or clickjacking, Chrome enforces:

Minimum size
Opacity must remain 1
No negative margins
No deceptive transforms
Enforced contrast ratio

You can style it, but you cannot make it invisible or misleading.

Example:

geolocation {
  border-radius: 8px;
  padding: 12px;
}

But you cannot:

Hide it
Make it 1px wide
Overlay fake UI elements

`<geolocation>` vs `navigator.geolocation`

Feature	Traditional API	`<geolocation>`
Permission Trigger	Script-based	User-click only
Boilerplate Code	High	Minimal
Recovery Flow	Manual	Built-in
Styling Control	Full	Guard-railed
Privacy Model	Developer-controlled	Browser-mediated

When Should You Use It?

Use <geolocation> if:

You need a simple "Use my location" feature
You want better permission recovery
You want reduced code complexity
You care about user trust and privacy

Stick to the traditional API if:

You need fine-grained timing control
You require silent background tracking
You are building real-time geo-heavy apps (ride-sharing, logistics dashboards)

Production Checklist

Feature-detect HTMLGeolocationElement
Provide a JS fallback
Avoid using autolocate unnecessarily
Test denied → recovery flows
Validate UX on mobile devices

Conclusion

The <geolocation> element is a significant shift toward declarative permission handling on the web. It reduces developer complexity while improving privacy, trust, and user experience.

For simple location-based features, it should become the default pattern in Chrome-supported environments.

However, since it's currently Chrome-specific and incubating, production systems must still include fallback support.

If you're building modern web applications and care about privacy-first UX, this is worth adopting early — but do it responsibly with progressive enhancement.

Top JSON Formatting & Validation Tools (Fast + Developer-Friendly)

Mon, 14 Jul 2025 07:43:29 +0000

Here are some fast, reliable tools for JSON formatting and validation — perfect for developers working with APIs, logs, or large JSON payloads.

1. jsonformatter.org

✅ Format, validate, minify, and view JSON
Has tree view and raw text view
Supports upload + clipboard copy
Also supports XML, YAML, JWT, CSV

Fastest and most comprehensive online tool.

⚡ 2. jsoneditoronline.org

Visual + code editor side-by-side
Detects and highlights syntax issues live
Offers "Transform", "Sort", and "Filter" tools
Supports collaboration with shareable links

Great for working with deeply nested JSON visually.

3. VS Code (Built-in or Plugin)

✨ Use built-in formatting: Right click → Format Document
Extensions:

Prettier (formatting)
JSON Tools (validation, sorting, filtering)
Works offline and with huge files

Ideal if you're already coding in VS Code.

4. quicktype.io

⚙️ Convert JSON → TypeScript, Python, Java, etc.
Also formats + validates input
Instant TypeScript interfaces for Angular/NestJS devs

Best for generating types/interfaces from real API responses.

5. CLI Tools (For local work)

If you want a fast terminal-based option:

✅ `jq` (lightweight and powerful)

jq '.' data.json  # Format
jq type data.json # Validate

Install:

brew install jq   # macOS
sudo apt install jq   # Ubuntu/Debian

Fastest tool for shell scripting and JSON pipelines.

Summary Table

Tool	Format	Validate	Extras
jsonformatter.org	✅	✅	Tree view, minify, export
jsoneditoronline.org	✅	✅	Visual editing, sharing
VS Code	✅	✅	Extensions, huge JSON
quicktype.io	✅	✅	Generate TS/Java classes
`jq` (CLI)	✅	✅	Scriptable, blazing fast

Mastering Browser Developer Tools: A Beginner’s Guide

Sun, 09 Mar 2025 22:07:16 +0000

Table of contents

Introduction
Understanding the Web browser as a developer
Key Components of Chrome Developer Tools
Step-by-Step Guide to Using Developer Tools
Common Challenges and Solutions
Advanced Techniques and Additional Considerations
Conclusion

Have you ever wondered how developers make websites run smoothly or how they troubleshoot issues on web pages? If you're starting out in web development, understanding how to interact with the tools available in your browser is essential. Browsers are not just for viewing websites --- they are also powerful tools for creating, testing, and debugging web pages. In this guide, we'll explore the basics of browser development tools, why browsers are referred to as clients in web development, and how to leverage these tools to enhance your skills.

A browser is a software application used to access and view websites on the internet. Popular browsers include Chrome, Firefox, Safari, and Edge. Browsers act as clients in web development, meaning they are the "consumer" of web content, receiving data from servers (which host websites) and rendering that content for users.

The World Wide Web Consortium (W3C) is an international community that develops web standards to ensure the internet is accessible and consistent. W3C standards guide developers in creating websites that work across different devices and browsers.

Browsers come equipped with developer tools to assist developers in inspecting, debugging, and improving websites. These tools are a must-have for anyone starting out in web development.

Key Components

The developer tools (often accessed by pressing F12) in browsers, particularly in Google Chrome, offer a range of tabs that each focus on a specific area of web development. Let's break down the key components of Chrome Developer Tools:

Elements:

Lets you view the raw HTML and CSS of a webpage.
You can inspect and edit the HTML structure of a page and immediately see changes.

Read more

Console:

Offers access to JavaScript functions.
Developers can view error messages or test JavaScript code directly in the browser.

Read more

Sources:

Navigate the files and folders that make up the webpage.
You can also view and edit JavaScript files, inspect scripts, and debug them.

Read more

Network:

Monitor network activity such as page load times, API requests, and responses.
Helps developers optimize website performance and detect potential issues.

Read more

Performance:

Acts like a dashboard for monitoring real-time performance.
Helps developers track and optimize resource usage (like CPU or memory) during page loads.

Read more

Memory:

Shows memory usage during web page interaction.
Helps developers identify memory leaks and improve efficiency.

Read more

Application:

Provides advanced tools for debugging a web page, including inspecting local storage, session storage, and cookies.

Read more

Privacy and Security:

Debug third-party cookies and HTTP security.
Allows checking the security of a webpage, like SSL/TLS certificates and encryption status.

Read more

Lighthouse:

Provides tools to test and analyze website performance, security, and accessibility.
Offers actionable insights and suggestions for improvements.

Read more

Recorder:

Allows developers to record user interactions on a webpage.
Useful for research purposes and performance testing.

Read more

Step-by-Step Guide

To start using the developer tools in Chrome, follow these simple steps:

Open Google Chrome.
Press F12 on your keyboard or right-click on a webpage and choose "Inspect" to open the Developer Tools.
Explore different tabs, starting with Elements to get familiar with the HTML structure.
Use the Console to experiment with JavaScript code and see the immediate results.
Check Network for any loading issues or delays in resources.
Test the performance of your page using the Performance tab, and make adjustments accordingly.
In the Memory tab, monitor how the page behaves in terms of memory usage.
Check for security issues under the Privacy and Security tab.

Common Challenges and Solutions

As a beginner, you might face some challenges when using developer tools. Here are a few common ones and solutions:

Challenge: Not understanding the raw HTML and CSS in the Elements tab.
Solution: Take time to learn basic HTML and CSS. Experiment by making changes in the Elements tab to see the immediate effects.
Challenge: Getting overwhelmed by the vast amount of data in the Console or Network tabs.
Solution: Filter out unnecessary information to focus on errors or specific issues you're troubleshooting.
Challenge: Difficulty interpreting performance data in the Performance tab.
Solution: Use online resources and tutorials to better understand how to read performance reports, and practice optimizing real pages.

Advanced Techniques

As you gain more experience, you'll want to explore deeper features in the browser developer tools:

Dive into the Sources tab to debug and set breakpoints in your JavaScript code.
Use Lighthouse to run audits for performance, accessibility, and SEO to ensure your website meets best practices.
Experiment with advanced debugging tools in the Application tab for complex web features like Progressive Web Apps (PWAs) and service workers.

For further learning, you can check out additional resources, like the official Chrome Developer Tools documentation or W3C web standards.

Conclusion:

Understanding browser developer tools is an essential skill for web developers, especially beginners. With tools like Elements, Console, and Network, you can efficiently debug and improve your web pages. By using the tips and techniques provided in this guide, you'll be able to start experimenting with real-world development scenarios. Start using these tools today and take your web development skills to the next level!

Have you tried using developer tools? What's your favorite tab? Share your thoughts in the comments below!

Coder Legion - Recent posts tagged chrome

Bridging Model Context Protocol (MCP) to Browser Agents via W3C WebMCP (document.modelContext)

coderlegion #webdev #aiagents #mcp #typescript #architecture #edgecomputing

Shipped: the FSCSS Browser IDE

What it is

Layout (quick map)

Quick start

Multi-file and @import

Packages: libck / libon / xfcmd

What else is built in

Example: three lines → many classes

Example: enable a pack

Ship path

Links

Vue.js Web Browser Extension Template

Put Chrome Stable on the same calendar as your deploys

Why Chrome Stable belongs beside deploys

What belongs on one shared release calendar

Name an owner before the graph moves

When field LCP shifts with no deploy: check population mix first

Browser release cadence versus CrUX pipeline lag

FAQ

Put the browser on the sheet this week

References

Keep Search Clean: Block Search Engine Spam with uBlacklist and Community Rule Sets

What Problem Does uBlacklist Solve?

Step 1: How to Install uBlacklist on Chrome

Step 2: Recommended Community Rule Sets

Step 3: How to Add Recommended Rule Sets to Your Extension

Step 4: How to Verify It’s Working

From HTML to Legal Automation: Dhardingsea Developer’s Journey of Building Software That Solves Real

It Started With Computers

Turning Real-Life Problems Into Software

When Software Has Real-World Consequences

Encoding Institutional Knowledge Into Software

The Chromium Autofiler That Started Something Bigger

Learning the Hard Way With a Chrome Extension

Shipping Something Before It's Perfect

Privacy Is a Requirement, Not a Feature

The Shortcut They Refuse to Take

The Lesson They Wish They Learned Earlier

Learning Databases for the Next Stage

The Advice: Have Fun

You Can Succeed at Anything — If You Luck Out Hard Enough

Building Through Curiosity

What Comes Next

About Dhardingsea Developer

About This Developer Story

Modern Chrome Extension Development: Manifest V3 Architecture & Best Practices

I built a local-first Dota 2 companion as a Chrome extension — and learned what "minimum permissions" actually means

The feature I actually cared about: improvement streak

Lesson 1: chrome.tabs.create() does not need the tabs permission

Lesson 2: rate limits you share with the user are a design constraint, not an error case

Lesson 3: optional permissions are worth the extra state

Testing logic that lives in a popup

Try it

When LCP Moves and Nobody Deployed: Browser Release Cadence and Your 28-Day Field Window

Why field LCP can move when nobody deployed

Chrome release cycle and Core Web Vitals: two-week Stable from Chrome 153

How a 28-day CrUX window can span multiple browser majors

Browser version in RUM: population mix vs a site regression

Put Chrome Stable on the same calendar as deploys and CDN changes

Sample thresholds before you slice field data by Chrome major

Use scheduled lab runs as same-week proof when field CrUX drifts

Browser mix vs fix lag and CrUX pipeline delay: three lag types

How agencies should monitor and report while browser mix shifts

FAQ

How to measure LCP and INP in Safari 26.2 (and what still only Chrome reports)

What Safari 26.2 changed for LCP and INP measurement

How to measure LCP in Safari with PerformanceObserver

How to measure INP in Safari with the Event Timing API

How to collect Safari LCP and INP with web-vitals.js

What still only Chrome reports (CrUX, Search Console, PageSpeed Insights field)

Why Safari and Chrome LCP timings can differ slightly

Agency checklist: segment Safari RUM beside Chrome lab and CrUX

Where Apogee Watcher fits after Safari starts reporting LCP and INP

FAQ

References

Lighthouse’s New Baseline Features Audit: What Developers Should Do With It

What the Lighthouse Baseline Features audit reports

Multi-file and `@import`

Packages: `libck` / `libon` / xfcmd

Lesson 1: `chrome.tabs.create()` does not need the `tabs` permission

Chrome 144 Introduces the `<geolocation>` Element: Declarative Location Access for Modern Web Apps

Why Chrome Introduced `<geolocation>`

What Is the `<geolocation>` Element?

`autolocate`

`watch`

`accuracymode`

`<geolocation>` vs `navigator.geolocation`

✅ `jq` (lightweight and powerful)