Intent to Ship: CPU Performance API

[Chromestatus]

Contact emails

niko...@chromium.org

Explainer

https://github.com/WICG/cpu-performance

Specification

https://wicg.github.io/cpu-performance

Summary

Expose some information about how powerful the user device is. This API targets web applications that will use this information to provide an improved user experience, possibly in combination with the Compute Pressure API, which provides information about the user device’s CPU pressure/utilization and allows applications to react to changes in CPU pressure.

Blink component

Blink>PerformanceAPIs

Web Feature ID

Missing feature

Motivation

At present, some video conferencing applications support advanced functionality by relying on internal/private browser extensions or APIs to classify devices into performance categories. Our proposal allows these applications to support existing functionality without depending on such non-standard features. Applications whose functionality depends on client-side hardware detection often resort to running benchmark workloads, to estimate hardware capabilities. Providing a public CPU Performance API would help prevent a needless waste of resources.

Initial public proposal

https://github.com/WICG/proposals/issues/253

TAG review

https://github.com/w3ctag/design-reviews/issues/1198 The specification is ready for review, so the above is not an "early design" review.

TAG review status

Pending

Origin Trial Name

CPU Performance API

Goals for experimentation

This API provides device-specific information about CPU performance while preserving user privacy. We'd like to see if this information is useful in providing the user experience improvement for the kind of applications that this API targets and if its shape matches developer expectations. We will measure API usage metrics and obtain developer feedback to validate our designs.

Chromium Trial Name

CpuPerformance

Origin Trial documentation link

https://github.com/WICG/cpu-performance

WebFeature UseCounter name

kNavigatorCPUPerformance

Risks

Interoperability and Compatibility

None.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1364)

WebKit: Oppose (https://github.com/WebKit/standards-positions/issues/622)

Web developers: Positive

Other signals: Adobe: https://github.com/WICG/cpu-performance/issues/6 Figma: https://github.com/WICG/proposals/issues/253#issuecomment-3719833708

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None.

Debuggability

Nothing interesting, debuggability review completed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/cpu-performance?label=experimental&label=master&aligned

Flag name on about://flags

No information provided

Finch feature name

CpuPerformance

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

True

Tracking bug

https://issues.chromium.org/449760252

Measurement

https://uma.googleplex.com/p/chrome/timeline_v2/?sid=eb11c4b156c799e994576301d01ff0b5

Availability expectation

Feature is available only in Chromium browsers. It is not clear if/when other browsers will follow.

Adoption expectation

Feature is used by specific partner(s) to provide functionality as of the launch in Chrome. At least one major abstraction will replace their use of an existing feature with this feature as of the launch.

Adoption plan

We are already working with specific partner(s) who will benefit from this feature.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

None.

Estimated milestones

Shipping on desktop	151
Origin trial desktop first	146
Origin trial desktop last	151
Shipping on Android	151
Origin trial Android first	146
Origin trial Android last	151
Shipping on WebView	151
Origin trial WebView first	146
Origin trial WebView last	151

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No such open issues.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5189864286978048?gate=5090091072618496

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMHN%3DHydj6Q7pz6i_y3j1ON20a270NFGx%2BKD11Q3VdfTXvtCDg%40mail.gmail.com
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69aaa531.2b0a0220.c2d7.063a.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Hey Nikolaos,

Exciting to see more information in this space coming through, as we've heard developers asking for similar data. Have you discussed the API shape with our friends at Intel? The Compute Pressure work is motivated by similar issues, and it would be helpful to at least see a sketch in the considered alternatives section of adding this information to either the existing `navigator.hardwareConcurrency` interface or Compute Pressure. At a minimum, I'd expect to see code samples that outline how they would be used together, given that the Explainer discusses it. The Explainer also doesn't outline the sorts of code folks have to write today to understand how to effectively understand the situation, which makes it hard for reviewers (e.g., the TAG) to understand if this is solving an important problem well.

Best,

Alex

[Nikos Papaspyrou]

Hi Alex,

Thank you for your comments and questions. We have discussed the API publicly since last October, when we circulated the explainer, and then followed with a presentation to the Web Performance WG at TPAC 2025. I’m not sure if somebody from Intel was present there. We have not discussed it with the authors of the Compute Pressure API proposal, in particular, although the two proposals are definitely related. I will try to explain their similarities and differences, as I see them.

The Compute Pressure API is dynamic; it “provides a way for websites to react to changes in the CPU pressure of the target device, such that websites can trade off resources for an improved user experience”. On the other hand, the CPU Performance API is static; it “exposes some information about how powerful the user device is. It targets web applications that will use this static information to provide an improved user experience”.

Both aspects of performance are useful and the two APIs are complementary, not antagonistic. I will not repeat the arguments in favour of dynamic information, as they are well known and documented in the Compute Pressure API. The argument in favour of static information is that we wanted the CPU Performance API to be a proxy for the user’s device hardware class — this means, it should be stable and unmoved by transient conditions, like what other applications are running, battery power, etc. If somebody has a powerful device where, at the moment, a lot of applications are running, we don’t want it to appear as a low-tier device to web applications. We want a new application to be able to realize that it is running on a high-tier device; if necessary, it will also have the chance to use dynamic information (the complementary API) to realize that the device is heavily used.

Obtaining dynamic information is something that a web application is generally able to do on its own, by running some JS benchmark. On the other hand, there’s no reliable way for a web application to obtain static information about the user device, that is, by overlooking what else is running. This is what the CPU Performance API is about. Partners have asked us for static information and this API solves the immediate use case; they have not asked for dynamic information, which is more-or-less covered by the Compute Pressure API. In this sense, the CPU Performance API is similar to `navigator.hardwareConcurrency`, which only exposes the possible level of concurrency regardless of how powerful each individual core may be.

The code example contained in the explainer and the proposed specification illustrates exactly this use case: a web application using the performance tier for pre-setting some features controlling user experience. Later on, such a web application may use the Compute Pressure API independently, to adjust these settings according to dynamic information.

Best regards,

Nikos.

Nikolaos Papaspyrou

Software Engineer

niko...@google.com

Google Germany GmbH

Erika-Mann-Straße 33 80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 

     

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Dan Clark]

I saw there were some open comments/questions on the TAG review thread https://github.com/w3ctag/design-reviews/issues/1198 -- it would be great if you could respond there so that review might reach some conclusion.

-- Dan

[Alex Russell]

Thanks for all of this, Nikos.

Look at the Explainer again, I'm not sure how this would be use in conjunction with (or in opposition to) Compute Pressure. Can you show in code there how they compose or compete? What use-cases benefit from the static judgement more than the dynamic one?

Best,

Alex

[Reilly Grant]

Alex,

In my experience speaking with developers, the issue is that even with logic to make a dynamic judgement (by using the Compute Pressure API or other feedback such as dropped frames) the site still needs to decide what to load first. Consider a developer looking to run an ML model on-device: They may have 3 different models requiring progressively higher compute capabilities but offering similar improvements in quality. Since each model takes time to load, ideally you would load the correct one first most of the time. This API can help with that. It's still just an assumption so other dynamic signals are still necessary.

Nikos, if this matches your experience can you add something like my explanation above to the explainer?

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4aafe1d7-6404-4b47-adc4-41a556ef95f5n%40chromium.org.

[Nikos Papaspyrou]

On Wednesday, June 10, 2026 at 5:28:38 PM UTC+2 dan...@microsoft.com wrote:

I saw there were some open comments/questions on the TAG review thread https://github.com/w3ctag/design-reviews/issues/1198 -- it would be great if you could respond there so that review might reach some conclusion.

The comments and questions on the TAG review thread have now been answered.

On Wed, Jun 17, 2026 at 8:59 PM Reilly Grant <rei...@chromium.org> wrote:

Alex,

In my experience speaking with developers, the issue is that even with logic to make a dynamic judgement (by using the Compute Pressure API or other feedback such as dropped frames) the site still needs to decide what to load first. Consider a developer looking to run an ML model on-device: They may have 3 different models requiring progressively higher compute capabilities but offering similar improvements in quality. Since each model takes time to load, ideally you would load the correct one first most of the time. This API can help with that. It's still just an assumption so other dynamic signals are still necessary.

Nikos, if this matches your experience can you add something like my explanation above to the explainer?

On Wed, Jun 17, 2026 at 8:13 AM Alex Russell <sligh...@chromium.org> wrote:

Thanks for all of this, Nikos.

Look at the Explainer again, I'm not sure how this would be use in conjunction with (or in opposition to) Compute Pressure. Can you show in code there how they compose or compete? What use-cases benefit from the static judgement more than the dynamic one?

 

Thank you Alex and Reilly! Reilly's explanation matches indeed the feedback from our partners.

I added a paragraph to the "Motivating use cases" section in the explainer, to make this more prominent.

Until the PR is merged, you can read it here: https://github.com/WICG/cpu-performance/pull/10/changes

I hope that this addresses both Alex's comments and similar comments on the TAG review thread.

Best regards,

Nikolaos Papaspyrou

Software Engineer

niko...@google.com

[Rick Byers]

I am personally convinced of the use case's importance and Nikos's responses to the TAG feedback. In addition to the linked Adobe and Figma support, Josh Comeau's comments on the I2P are notable.

While it's quite dated now, this all aligns with my personal experience working on mobile GMail. We essentially had a database mapping heuristic signals (like precise device model strings in the UserAgent header) to higher level concepts of device capability (similar to what Facebook described around that time). Then, we'd serve our best guess of a bundle of html/js in the initial HTTP response based on these heuristics (with a selection of features enabled which we believed would work well for the user). When people argued that relying on such heuristics was "wrong", we would cringe at their lack of pragmatism and connection to the real-world tradeoffs involved in delivering a top-tier web app which refused to compromise on user experience. Of course that team eventually (very reluctantly) gave up on the web, deciding it was too hard to fight things like this relative to native mobile platforms where they faced no such headwinds.

This proposed API is a HUGE improvement for browser interoperability over the approach we used in GMail, since it was virtually impossible for a browser/device maker to tell what signal we were using on our server to determine the quality of experience we served them. I would expect such heuristics are still relied upon across sophisticated web apps. Developers of such sophisticated web apps have no reason to talk publicly about how they optimize user experience, since such heuristics are generally frowned upon yet also a competitive differentiator for the best of the web. 

My only concern with this intent (especially after reflecting on my handling of the prompt API intent) is whether it meets our bar for establishing "plausible interoperability". If I were working on Firefox and wanted to ensure an Adobe or Figma web app got the same quality level of experience as Chrome thanks to this API, I'm pretty sure I would want to just copy the Chromium algorithm exactly rather than risk doing something different. If we expect that to happen, then I think the burden should be on us to make that easy, e.g. by either:

1) Moving our core algorithm into an open-source repo independent from Chromium, intended to be easy for other browser engines to consume and keep up-to-date, OR

2) Encoding the algorithm we're using directly into the spec (perhaps via a reference implementation as is done for other specs like WASM). Ensuring this stays in sync with Chromium could be a pain, but maybe some declarative data table could be used to drive the algorithm? 

If all other engines oppose this capability in any form, it's probably not worth doing this work now for zero tangible benefit. Instead perhaps we should commit to taking one of the above paths should another implementation come along in the future and request it? WDYT?

Rick

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMHN%3DHy3Cqd%2BMX%3DB%3Dy7%2BWwafkiBFCB0zDXj4iRGKt0qmeWerRg%40mail.gmail.com.

[Helmut Januschka]

In my corporate work, we have implemented device tiering multiple times over

the years, using whatever signals were available at the time: core count,
device memory, battery state, connection type, screen size, OS version, and
sometimes user-agent-derived platform hints. The goal was always practical:
reduce battery usage, pick a reasonable initial bundle/model/feature set, and
avoid starting users on an experience that we then immediately have to degrade,
or that fails along the journey. Having this proposed API would have helped a lot.

Personally, I am not concerned about the privacy aspect of this API at the
proposed granularity. The alternative in practice is often worse.

On the interoperability point, I started a small Rust port of the Chromium
classification algorithm here:

https://github.com/hjanuschka/cpu-performance-tier

Please consider this only a PoC. If this direction is useful, moving it under
a neutral namespace would be mandatory. My hope is that having the algorithm
live in an independent, reviewable repo can help with credibility, make it
easier for other engines to  reuse the exact same logic, and build
user and market trust through an open-source approach.

The PoC is independent of Chromium internals, includes the Chromium test
vectors, and has an optional dependency-free host-info helper feature
(to fetch core count and brandname). I can help with a Chromium migration to
such a shared crate if that direction is useful. If positions from other engines
ever change, I can also help pursue integration CLs there. If Rust is not
practical for a given engine, we could provide a C++ version as well.

Even if other engine positions stay negative/opposed for a while, I think
option 1 would still provide a solid foundation for a possible future change in
those engines.

I am not expecting anything here; I just wanted to raise my hand and say I
would like to help turn option 1 into something real if that becomes useful.

cheers, 

helmut

[Thomas Steiner]

I know that the Web AI community are very interested in finding out if a given device can run an AI model. In the native world, there are tools like llmfit. I recently compared what they can obtain with what is available via Web APIs.

llmfit:

Web APIs:

• Hardware concurrency shows 14 cores, paired with other info like OS, you can pretty accurately tell the CPU.
• Device memory shows a capped value of 32 GB, but I actually have 48, and it doesn't give you the currently free RAM.
• GPU adapter info seems on par, and I think there could be some info you could deduce about available RAM by looking in the max buffer size and additional out-of-bounds knowledge based on the vendor.

Happy to put you in contact with the people at Hugging Face I'm talking to. They are interested in the API for sure.

Cheers,

Tom

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8i6a1a-fz8S7%3DCHCSfU1gB%2B9ij1eU7y9gaKOjjqj%2BNxg%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, toot.cafe/@tomayac)

Google Spain, S.L.U.

Torre Picasso, Pl. Pablo Ruiz Picasso, 1, Tetuán, 28020 Madrid, Spain

CIF: B63272603

Inscrita en el Registro Mercantil de Madrid, sección 8, Hoja M­-435397 Tomo 24227 Folio 25

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.4.8 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck

0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181.

----- END PGP SIGNATURE -----

[Rick Byers]

Thanks everyone for the input and offer of support! Note that Nikos is OOO this week so we should not expect responses from him until next week. I believe the team will likely postpone this feature to M152 to ensure there's adequate time to engage with this debate and make any necessary adjustments. But note the OT ends in 151 so IMHO we should not let this slip past M152 without a very good reason. 

Regarding the interoperability concern, I also built a JS reference implementation derived from the Chromium impl and proposed contributing it to the WICG, along with a little demo page, and possible spec additions. I suggest we give the standards debate a couple weeks to play out in the WICG repo + TAG thread. Then, depending on the outcome, API owners can evaluate whether to ask the team to move their implementation into an independent open source repo. IMHO if the spec ends up reasonably precisely defining the algorithm, there's no reason to request any changes in Chromium's implementation strategy.

Rick

[Barry Pollard]

Look at the Explainer again, I'm not sure how this would be use in conjunction with (or in opposition to) Compute Pressure. Can you show in code there how they compose or compete? What use-cases benefit from the static judgement more than the dynamic one?

I don't have code, but I see them as related but different.

IMHO the Compute Pressure API is about dealing with a system under stress and backing off non-critical work.

This CPU Performance API is about setting an initial baseline of what a system should be able to handle under normal conditions (i.e. don't default assumptions that a system is under-powered and default to the bare minimum and make the user perhaps miss out on providing optional, extra enhancements, but also don't assume it's overpowered and make users turn off features to get a useable experience).

Now it's true that the Compute Pressure API could be used for the same reasons as CPU Performance API. But that basically means ramping up until it hits a pressure point and then backing off. That's effectively just another form of micro-benchmarking and I think we all understand the downsides of that.

I also think this CPU Performance API is a simpler, and more developer egronomic API than computer pressure, along the lines of Network Information API and Device Memory API where sites can use these signals to customize the experience upfront (for example providing a more stripped down experience for lower-powered devices). The Compute Pressure API is more about reacting to continual signals in a real-time fashion, so I'd see it as a more advanced use case for real time systems (video conferencing, video games). I don't think you want to remove features already loaded due to Compute Pressure (for example, you wouldn't switch already-loaded hi-res images to lower resolution images based on CPU pressure), just lower/pause continually processing processes like video or background calculations.

Would sites use both? Maybe. But as I say, I think the Compute Pressure API is a more advanced API.

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/igPwzkxhQtk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY90H6SuPm0JokoOY%2BHBtVUkC3YBSzYK1bS9%3D7%2BVQk%3DtNQ%40mail.gmail.com.

[Rick Byers]

On Fri, Jun 26, 2026 at 9:16 AM Barry Pollard <barryp...@google.com> wrote:

Look at the Explainer again, I'm not sure how this would be use in conjunction with (or in opposition to) Compute Pressure. Can you show in code there how they compose or compete? What use-cases benefit from the static judgement more than the dynamic one?

I don't have code, but I see them as related but different.

IMHO the Compute Pressure API is about dealing with a system under stress and backing off non-critical work.

This CPU Performance API is about setting an initial baseline of what a system should be able to handle under normal conditions (i.e. don't default assumptions that a system is under-powered and default to the bare minimum and make the user perhaps miss out on providing optional, extra enhancements, but also don't assume it's overpowered and make users turn off features to get a useable experience).

Now it's true that the Compute Pressure API could be used for the same reasons as CPU Performance API. But that basically means ramping up until it hits a pressure point and then backing off. That's effectively just another form of micro-benchmarking and I think we all understand the downsides of that.

I also think this CPU Performance API is a simpler, and more developer egronomic API than computer pressure, along the lines of Network Information API and Device Memory API where sites can use these signals to customize the experience upfront (for example providing a more stripped down experience for lower-powered devices). The Compute Pressure API is more about reacting to continual signals in a real-time fashion, so I'd see it as a more advanced use case for real time systems (video conferencing, video games). I don't think you want to remove features already loaded due to Compute Pressure (for example, you wouldn't switch already-loaded hi-res images to lower resolution images based on CPU pressure), just lower/pause continually processing processes like video or background calculations.

Would sites use both? Maybe. But as I say, I think the Compute Pressure API is a more advanced API.

Thanks Bary, this was exactly my thinking too - depending on your use case you'd want either static (eg. UX that is jarring to change) or dynamic (more advanced, good for anything that really needs to adapt over time). I still think we COULD show an example of a dynamic system which bootstrapped itself using the static value, but I'm not personally aware of any developer who wants to do that, so it might be entirely artificial. For problems where the UX is amenable to a dynamic system, wouldn't I want to just always go for the max utilization and back off under pressure, rather than try to set some artificial ceiling? 

Nikos, WDYT? Can you ask any of your known OT users for this API whether they are using it in conjunction with dynamic signals, or whether they have features effectively split into those which are dynamic vs. those that are static? For example, the explainer talks about setting initial video resolution, frame rate and features for a video chat app. Features seems clearly static to me (don't want background blur turning off and on based on CPU load). But what about framerate and video resolution? Would these generally only be changed by user action (manually choosing a higher resolution), by other dynamic signals (like dropped frames), or also by CPU pressure? 

[Sangwhan Moon]

One small thing that came to mind is when there is CPU hotplug is involved (e.g. ChromeOS does this for battery saver).

It seems like as of today there isn't a way for apps to react when the core count changes by the system - has an event or watcher been considered?

Sangwhan Moon

On Jun 26, 2026, at 8:51, Rick Byers <rby...@chromium.org> wrote:



On Fri, Jun 26, 2026 at 9:16 AM Barry Pollard <barryp...@google.com> wrote:

Look at the Explainer again, I'm not sure how this would be use in conjunction with (or in opposition to) Compute Pressure. Can you show in code there how they compose or compete? What use-cases benefit from the static judgement more than the dynamic one?

I don't have code, but I see them as related but different.

IMHO the Compute Pressure API is about dealing with a system under stress and backing off non-critical work.

This CPU Performance API is about setting an initial baseline of what a system should be able to handle under normal conditions (i.e. don't default assumptions that a system is under-powered and default to the bare minimum and make the user perhaps miss out on providing optional, extra enhancements, but also don't assume it's overpowered and make users turn off features to get a useable experience).

Now it's true that the Compute Pressure API could be used for the same reasons as CPU Performance API. But that basically means ramping up until it hits a pressure point and then backing off. That's effectively just another form of micro-benchmarking and I think we all understand the downsides of that.

I also think this CPU Performance API is a simpler, and more developer egronomic API than computer pressure, along the lines of Network Information API and Device Memory API where sites can use these signals to customize the experience upfront (for example providing a more stripped down experience for lower-powered devices). The Compute Pressure API is more about reacting to continual signals in a real-time fashion, so I'd see it as a more advanced use case for real time systems (video conferencing, video games). I don't think you want to remove features already loaded due to Compute Pressure (for example, you wouldn't switch already-loaded hi-res images to lower resolution images based on CPU pressure), just lower/pause continually processing processes like video or background calculations.

Would sites use both? Maybe. But as I say, I think the Compute Pressure API is a more advanced API.

Thanks Bary, this was exactly my thinking too - depending on your use case you'd want either static (eg. UX that is jarring to change) or dynamic (more advanced, good for anything that really needs to adapt over time). I still think we COULD show an example of a dynamic system which bootstrapped itself using the static value, but I'm not personally aware of any developer who wants to do that, so it might be entirely artificial. For problems where the UX is amenable to a dynamic system, wouldn't I want to just always go for the max utilization and back off under pressure, rather than try to set some artificial ceiling? 

Nikos, WDYT? Can you ask any of your known OT users for this API whether they are using it in conjunction with dynamic signals, or whether they have features effectively split into those which are dynamic vs. those that are static? For example, the explainer talks about setting initial video resolution, frame rate and features for a video chat app. Features seems clearly static to me (don't want background blur turning off and on based on CPU load). But what about framerate and video resolution? Would these generally only be changed by user action (manually choosing a higher resolution), by other dynamic signals (like dropped frames), or also by CPU pressure? 

On Mon, 22 Jun 2026 at 16:02, Rick Byers <rby...@chromium.org> wrote:

Thanks everyone for the input and offer of support! Note that Nikos is OOO this week so we should not expect responses from him until next week. I believe the team will likely postpone this feature to M152 to ensure there's adequate time to engage with this debate and make any necessary adjustments. But note the OT ends in 151 so IMHO we should not let this slip past M152 without a very good reason. 

Regarding the interoperability concern, I also built a JS reference implementation derived from the Chromium impl and proposed contributing it to the WICG, along with a little demo page, and possible spec additions. I suggest we give the standards debate a couple weeks to play out in the WICG repo + TAG thread. Then, depending on the outcome, API owners can evaluate whether to ask the team to move their implementation into an independent open source repo. IMHO if the spec ends up reasonably precisely defining the algorithm, there's no reason to request any changes in Chromium's implementation strategy.

Rick

On Mon, Jun 22, 2026 at 5:48 AM Thomas Steiner <to...@google.com> wrote:

I know that the Web AI community are very interested in finding out if a given device can run an AI model. In the native world, there are tools like llmfit. I recently compared what they can obtain with what is available via Web APIs.

llmfit:

<Screenshot 2026-06-12 at 12.31.54.png>

Web APIs:

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-AWVyD5iR3HXSftNrx-HnZBy%2BJwbZb63NOpqnXELyUjA%40mail.gmail.com.