Chrome Starts Shipping Every Two Weeks in September. Your Licence Says Nothing About Who Fixes the Break.

Chrome moves to a two-week release cycle on 8 September 2026. A licensed HTML5 game catalogue is a shelf of frozen builds, and no clause says who fixes a break. That gap is about to get tested twice as often, and the first test is already running.

🗓️ The Cadence Doubles on 8 September

Google announced in March 2026 that Chrome moves from a four-week release cycle to a two-week one, starting with Chrome 153 on 8 September 2026. That takes the browser from roughly 13 stable releases a year to roughly 26. The Chrome team's framing is that each release carries less scope, so stability holds. For a site you wrote yourself, that's probably true.

Two details from the same announcement matter more to a catalogue operator than the headline:

• Beta ships three weeks before stable. Under a two-week cadence that means two betas are in flight at once. Your validation window doesn't shrink, but it stops being a tidy sequence.
• Extended Stable stays on eight weeks. That channel exists for enterprise administrators and Chromium embedders. If your distribution includes managed devices, kiosks or an embedded webview, you are now shipping into two populations whose browser versions drift four times as far apart as they used to.

None of this is a crisis. It is a change in the rate at which the platform underneath your catalogue moves, and a licensed catalogue is unusually badly placed to absorb it, for a reason that has nothing to do with Chrome.

⏳ On 25 August, 80% of Chrome Stops Firing unload

Chrome is removing the unload event, and the way it is doing it is the clearest illustration of the problem. From Chrome's own deprecation page, the second phase of the rollout is a published percentage ramp across all origins:

• Milestone 146, 10 March 2026 — 1% of Chrome page loads
• Milestone 147, 7 April 2026 — 5%
• Milestone 148, 5 May 2026 — 10%
• Milestone 149, 2 June 2026 — 20%
• Milestone 150, 30 June 2026 — 40%
• Milestone 151, 28 July 2026 — 60%
• Milestone 152, 25 August 2026 — 80%
• Milestone 154, 22 September 2026 — 100%

An earlier phase ran through 2025 against the top 50 sites, one at a time. Chrome's stated reason is that unload was never reliable on mobile in the first place, and that keeping it blocks back/forward cache. Both are fair. Chrome also says it plans to keep the Permissions-Policy opt-out available for the considerable future, so there is an escape hatch.

Look at the shape of that ramp rather than the feature. A game that saved progress in an unload handler did not stop working on a date. It started working for a shrinking share of players, machine by machine, with no error, no console entry the player would ever see, and no support ticket that reads like a browser change. It reads like "it lost my score sometimes." Support closes it as unreproducible, because on the tester's machine it reproduces one time in five.

This is the failure mode that percentage rollouts produce, and it is the one a catalogue operator is least equipped to catch. You are running 1,000 builds you did not compile. Nobody on your team has a mental model of which of them touches unload.

🧊 A Licence Buys a Build, Not a Maintenance Contract

Here is the part that is genuinely a licensing question rather than an engineering one. Ask what your agreement actually obliges the licensor to do when a browser change breaks a title eighteen months after delivery. In most catalogue deals the honest answer is: nothing.

The three common shapes, and what each leaves you holding:

One-off / perpetual build licence

You paid once for a finished build. There is usually a warranty period measured in weeks that covers defects present at delivery. A browser removing an API two years later is not a defect present at delivery. You own a broken game and no route to a fix.

Term catalogue licence

Better, because the relationship is live and the licensor has a renewal to protect. But "updates" in the clause often means new titles added to the catalogue, not repairs to existing ones. Read which one yours says. They are one word apart and worth very different money.

Source-code licence

The only shape that guarantees you can fix it yourself, and the reason source-code deals price above build-only deals. It comes with the obligation to actually staff the fixing. A source licence you have no engineer for is a build licence with extra paperwork.

The practical test before signing: name the person who ships the patch when Chrome removes something in fourteen months. If you cannot name a party in the contract, the answer is you, and you should price the deal accordingly.

🔍 Chrome's Warning System Assumes You Wrote the Code

Chrome does give notice. Its documented process runs deprecation warnings through the DevTools Issues panel, publishes timelines on Chrome Platform Status, posts Intent threads to the blink-dev mailing list, and writes them up on Chrome for Developers. That is a genuinely good pipeline, and every channel in it points at the author of the code.

You are not the author. Your catalogue arrived as minified bundles. A DevTools warning naming a deprecated call inside game.min.js tells you a title is affected and nothing about how to repair it. The blink-dev thread is six months old by the time it matters to you and was written for the engine vendor, not the portal.

One channel does work from your side of the fence: the Reporting API. Chrome documents using it with a read-only Permissions Policy specifically to detect unload usage from real user traffic. That inverts the problem usefully — instead of auditing 1,000 builds you cannot read, you collect reports from players actually hitting the deprecated path and get back a list of the titles that matter. The bfcache notRestoredReasons API does something similar, returning unload-listener as a reason a page was not restored.

Set that up once and it keeps paying, because the next deprecation gets the same treatment.

🧨 What Has Already Been Removed Under Old Builds

The unload ramp is not the first one to run under a licensed catalogue, and the earlier ones are worth knowing because they tell you what era of build is fragile.

• Web SQL — removed in Chromium 119, with a deprecation trial available from Chromium 117 through 123. Any game that stored saves in openDatabase lost them. That is a lot of 2012–2016 HTML5 titles, which is exactly the vintage that shows up cheap in bulk catalogue offers.
• Mutation Events — removed in Chrome 127, stable on 23 July 2024. Old DOM-heavy UI layers used them.
• Privacy Sandbox APIs — announced for retirement on 17 October 2025, deprecated in Chrome 144 and removed in Chrome 150. Less likely to touch gameplay, very likely to touch whatever ad stack you wrapped around it.
• XSLT — deprecated now, with removal scheduled for Chrome 158 on 17 November 2026.

Notice the last one. The date is published, in advance, in public. Chrome is not ambushing anyone. The question is only whether a person on your side of the deal is reading the calendar, and at most portals nobody is, because catalogue operations gets staffed as a merchandising job rather than a maintenance one.

📏 Baseline Gives You an Acceptance Criterion You Can Put in a Contract

"Works in modern browsers" is not a testable acceptance condition. Baseline is, and it is the most useful contract language available to a catalogue buyer right now.

Baseline, maintained by the WebDX Community Group and documented on web.dev, classifies a web feature in stages. Newly available means it is supported across the core browser set — Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS. Widely available means 30 months have passed since that interoperability date, at which point most sites can use it without worrying.

Which gives you a clause worth writing: delivered builds shall depend only on features that are Baseline Widely Available as at the delivery date, and shall not depend on any feature with a published Chrome removal milestone. Two sentences. Both objectively checkable against a public dataset rather than against a vendor's opinion of its own build quality.

The 30-month figure also sets expectations honestly in the other direction. If a licensor pitches you a title built on something that only just reached Newly Available, that is not automatically bad — but it is a build whose floor may move, and you should know that before, not after.

🧪 The Test Pass That Actually Catches This

A realistic maintenance routine for a portal running a licensed catalogue, sized for the team most operators actually have:

1. Run one browser on Beta. One machine, or one CI container, pinned to Chrome Beta. Under the new cadence, beta lands three weeks before stable, so this is your only structural early warning.
2. Pick a smoke set, not the whole catalogue. Twenty to forty titles chosen for engine diversity and age, not for popularity. Your top twenty games are all recent builds from two engines and will tell you nothing.
3. Test the three things browsers actually break: save persistence across a session, audio starting after first input, and full-screen or orientation handling. Rendering rarely breaks. State and permissions break constantly.
4. Instrument the shell, not the game. You cannot read errors out of a cross-origin iframe. What you can log is the signal you own — session length by title, plays that end in under five seconds, and a sudden change in either. A title that quietly broke shows up as a cliff in average session length before anyone files anything.
5. Subscribe someone to the deprecation feed. Chrome Platform Status and the Chrome release notes, read once a month by a named person. Thirty minutes.

Point four is the one operators skip and the one that pays. Every portal already has the play-event data. Almost nobody alerts on it per title.

🚫 Five Ways Operators Get This Wrong

• Treating launch as the finish line. The catalogue was the capital expense; keeping it playable is the operating one, and it never appears in the launch budget.
• Testing on the newest device in the office. Percentage rollouts mean the same Chrome version behaves differently on different machines. One tester proves nothing.
• Assuming the licensor is watching. A licensor with 1,000 titles across 40 licensees has the same maintenance problem you do, multiplied. Absent a clause, they are not monitoring Chrome milestones on your behalf.
• Buying old catalogues on price per title. A 2014-era bundle is cheap because the risk of platform rot has been priced in by the seller and not by you.
• Reading support tickets as player error. "Lost my progress" filed three times in a week against three different games is a platform change, not three coincidences.

✍️ What to Settle Before Your Next Renewal

Four clauses, in rough order of how much money they are worth:

• Compatibility maintenance. Who repairs a title broken by a browser change, and inside what window. If the answer is the licensor, define what triggers the obligation — a reproducible failure in a current stable release of any core browser is a workable trigger.
• Baseline delivery standard. As above, tied to the delivery date so it stays objective.
• Escrow or source on discontinuation. If the licensor stops supporting a title you are still licensed to run, you get the source. This is cheap to agree at signature and impossible to get later.
• Notification. The licensor tells you when it patches a title, and you get the updated build. Sounds obvious. Is frequently absent, which is how portals end up serving a version the licensor already fixed.

🌲 Where a Licensed Catalogue Fits

Forestry Games has licensed a catalogue of 1,049 titles since 2017, across HTML5 and Android, and develops HTML5 games in-house. The relevant point for this topic is not catalogue size. It is that a licensor who also builds knows which of its titles rest on which platform features, and can act on a deprecation notice rather than forward it. When you are evaluating any supplier, including this one, that is the capability to test for: ask what they did about the unload ramp this year. The answer tells you what kind of relationship you are buying, and the same question is worth asking of anyone quoting you a white-label portal.

🧭 What to Do This Week

Chrome hits 80% on the unload ramp on 25 August and 100% on 22 September, and the cadence doubles in between. Three things, in order:

1. Open the Chrome release cadence announcement and put Chrome 153 in your calendar, then put a recurring monthly slot next to it for reading release notes.
2. Pull last month's play data and sort titles by change in median session length. Anything that fell off a cliff since June is your first candidate list, and it costs you nothing to produce.
3. Find your largest catalogue agreement and search it for the word "maintenance." Whatever you find — a clause, or nothing — that is the number you should be renegotiating at renewal, before the next removal lands rather than after.

The browser is going to keep moving. The only question a licensee gets to answer is whether the contract moved with it.