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

#webdev #webperf #seo

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.