What's Shipping in Chrome 149 Stable on June 2 for Webflow Sites?

Chrome 149 entered the beta channel on May 6, 2026, with stable scheduled for June 2, 2026, just 14 days from today. Chrome 150 is already in the Dev channel at build 150.0.7838. The Chrome 149 stable release includes BFCache support for pages with open WebSocket connections, programmatic scroll Promises via Element.scrollTo, and a long tail of CSS feature additions covered in earlier batches. Chrome 150 in Dev defaults the Always Use Secure Connections setting to public-sites-only mode, which has implications for B2B SaaS marketing sites that still serve any HTTP content. At Phoenix Studio in Bengaluru, I run Canary, Beta, and stable Chrome simultaneously on a single Mac for QA, and the Chrome 149 beta build has been on the daily-driver since May 7. In this piece I walk through what Webflow Partners should test before June 2 and what to watch for in Chrome 150.

When does Chrome 149 stable ship?

Chrome 149 stable ships on June 2, 2026, following Google's standard 4-week stable channel cadence. The beta channel opened on May 6, 2026, giving the development community four weeks of beta testing before stable release. Chrome 150 is currently in the Dev channel at build 150.0.7838 and will move to beta around June 3, with stable scheduled for late June or early July 2026.

For Webflow Partners shipping B2B SaaS marketing sites between May 19 and June 2, the practical implication is that the live audience auto-updates to Chrome 149 stable on the release day. Builds completed in the next two weeks need to validate against Chrome 149 beta behavior, not against Chrome 148 behavior, because Chrome 149 stable will reach the production audience before any client signoff window closes.

What's new in Chrome 149 for Webflow sites?

Chrome 149 adds several developer-facing features relevant to Webflow B2B SaaS marketing sites. The two most consequential are BFCache support for pages with open WebSocket connections (which previously prevented BFCache caching) and programmatic scroll Promises via Element.scrollTo (which lets JavaScript code await scroll completion). The release also includes the CSS feature surface covered in earlier batches.

For Phoenix Studio's standard Webflow build patterns, the BFCache WebSocket change matters most because it changes performance behavior for sites with real-time pricing widgets, chat embeds, or dashboards that maintain a WebSocket connection. The piece on CSS Gap Decorations in Chrome 149 covered the CSS-side feature surface, and the piece on CSS path() and shape-outside() in Chrome 149 covered the path-shape rendering changes.

Does Chrome 149's BFCache WebSocket disconnect affect SaaS dashboards?

Chrome 149's BFCache change affects SaaS dashboards in a positive way: pages with open WebSocket connections can now be cached in BFCache, enabling instant back/forward navigation. Before Chrome 149, an open WebSocket disqualified a page from BFCache, which produced slower navigation experience for users moving between pages on a dashboard or marketing site that maintained a WebSocket.

For Webflow B2B SaaS marketing sites that embed real-time pricing widgets, chat support, or live data displays through WebSocket connections, the change improves perceived navigation speed measurably. The Phoenix Studio QA test for Chrome 149 specifically validates that a real-time-data section on a client's pricing page remains responsive after BFCache restore. The test is a small addition to the standard QA pass and produces a meaningful user-facing improvement.

How do programmatic scroll Promises change Webflow Interactions?

Chrome 149's programmatic scroll Promises change how JavaScript code interacts with scroll behavior by letting Element.scrollTo and related methods return a Promise that resolves when the scroll animation completes. Before Chrome 149, JavaScript code that triggered a smooth scroll could not reliably await completion without setTimeout hacks or scroll-event polling. The Promise-based API replaces both patterns with a clean async/await flow.

For Webflow Interactions that chain animations or behaviors after a scroll completes (for example, a CTA that scrolls to a form and then focuses the first input), the new Promise API simplifies the implementation. The Designer Interactions panel does not yet expose the Promise pattern directly, but custom-code Interactions can use it. Phoenix Studio's pattern for scroll-then-focus flows on B2B SaaS contact pages will adopt the Promise API as the default once Chrome 149 reaches stable.

What's Chrome 150 going to default to for HTTPS?

Chrome 150 will default the Always Use Secure Connections setting to public-sites-only mode, meaning Chrome will attempt to upgrade HTTP connections to HTTPS automatically for public-facing sites while leaving internal-network connections in their original state. The change is documented in the Chrome Enterprise release notes and represents the next step in Chrome's incremental HTTPS-First rollout that started with the opt-in mode in earlier versions.

For Webflow B2B SaaS marketing sites, which are universally served over HTTPS by default on Webflow hosting, the Chrome 150 change has minimal direct impact. The indirect impact is on any external resource the site loads (CDN-hosted scripts, third-party widget embeds, analytics endpoints) that might still be served over HTTP. Phoenix Studio's pre-Chrome-150 audit includes a check for any HTTP-referenced resources in client Webflow projects, which is small but worth running.

What should a Webflow Partner test before June 2, 2026?

A Webflow Partner should test five categories of behavior on Chrome 149 beta before June 2, 2026. First, BFCache restore behavior on pages with WebSocket connections. Second, programmatic scroll Promise behavior on any custom-code Interactions that depend on scroll completion. Third, the CSS feature surface covered in earlier Chrome 149 pieces. Fourth, any third-party widget embeds that previously broke on Chrome beta. Fifth, performance regression checks against Chrome 148 baseline.

The Phoenix Studio QA pattern is to run the five-test pass on each active client site between May 19 and June 1, then validate again on Chrome 149 stable for any site that fails any test. The total time investment is roughly 90 minutes across the typical retainer client roster, which is small relative to the value of catching issues before the audience auto-updates. The piece on Chrome 148 Prompt API covered the previous-version test patterns that this update extends.

Will Chrome 149 break any Webflow embeds?

Chrome 149 is not expected to break Webflow embeds based on the Chrome beta testing window. The major changes (BFCache WebSocket support, scroll Promises) are additive rather than breaking. The CSS feature additions covered in earlier pieces are also additive. The Chrome release pattern for 4-week stable cadence emphasizes backward compatibility, and Chrome 149 follows that pattern.

The category of embed that warrants extra QA attention is third-party widgets that maintain WebSocket connections (real-time chat, live pricing, presence indicators) because the BFCache change affects their lifecycle behavior. Most well-maintained third-party widgets already handle BFCache restore correctly because Firefox has supported this pattern for several releases. The Phoenix Studio QA pass adds a specific test for these embeds on Chrome 149 beta, which usually surfaces zero issues but is cheap to run.

How does Chrome's 4-week cadence change Partner QA workflow?

Chrome's 4-week stable channel cadence requires Webflow Partners to validate against the current Chrome stable plus the upcoming Chrome beta on every active client build. The pattern at Phoenix Studio is to keep Chrome stable as the primary browser, Chrome beta as a secondary daily-driver for forward-looking testing, and Chrome Canary as a tertiary build for early-signal testing. The three-channel setup uses one Mac and one set of profiles.

The practical workflow addition compared to a single-channel setup is roughly 15 minutes per active client per beta cycle, which is small. The benefit is that the practice does not get surprised by Chrome stable releases that change behavior on production. The pattern compounds across the client roster and reduces emergency fixes by surfacing issues during the beta window, which is when there is time to address them properly.

Should B2B SaaS sites support Chrome Extended Stable?

B2B SaaS sites should support Chrome Extended Stable for enterprise customer audiences that mandate it through IT policy. Chrome Extended Stable runs on an 8-week cadence rather than the standard 4-week cadence, so the active Extended Stable version at any time is one version behind the current stable. For Webflow marketing sites, the practical implication is to validate that builds work on both the current stable and the one-version-behind Extended Stable.

For most Phoenix Studio B2B SaaS clients, the Extended Stable audience is small enough that the validation pattern is to spot-check rather than run a full QA pass. The exception is clients whose primary audience is large enterprises with strict IT policies (financial services, healthcare, government), where Extended Stable coverage matters more. The Phoenix Studio decision tree is to ask about audience IT policy during onboarding and adjust the QA pattern per client.

What's the watch-list for Chrome 150 and Chrome 151?

The Phoenix Studio watch-list for Chrome 150 and Chrome 151 covers three items. First, the Always Use Secure Connections default change in Chrome 150 (relevant for sites loading any HTTP-referenced external resources). Second, additional CSS feature additions covered in Chrome 150 release notes when they publish. Third, any Web Platform Status changes for features currently in origin trial that may reach stable in Chrome 150 or 151.

The watch-list is intentionally short because most Chrome features in any given release do not affect Webflow B2B SaaS marketing sites directly. The pattern at Phoenix Studio is to skim release notes weekly, queue any consequential change for a deeper read, and ignore the rest. The discipline keeps the practice current without drowning in browser release noise, which is a real risk for a solo operator who reads everything.

If you run a B2B SaaS marketing site on Webflow and want to talk through which Chrome 149 changes to test before June 2 for your specific site, drop me a line and tell me what your current Chrome version coverage looks like in analytics. I will share the Phoenix Studio QA test sequence I am running on retainer client sites this week. Let's chat.