(Disclaimer: I work in the advertising industry which uses Flash for ads.)

Chrome 55 will disable Flash by default this December. Users will be prompted to enable Flash per site. This changes the game for advertising companies and publishers still relying on Flash to serve video.

Here's the blog post:

Flash and Chrome

Today, more than 90% of Flash on the web loads behind the scenes to support things like page analytics. This kind of Flash slows you down, and starting this September, Chrome 53 will begin to block it. HTML5 is much lighter and faster, and publishers are switching over to speed up page loading and save you more battery life. You'll see an improvement in responsiveness and efficiency for many sites.

In December, Chrome 55 will make HTML5 the default experience, except for sites which only support Flash. For those, you'll be prompted to enable Flash when you first visit the site. Aside from that, the only change you'll notice is a safer and more power-efficient browsing experience.

Source: Chrome

Flash is used for advertisements and games, not analytics as far as I know.

Mobile Killed Flash First

Apple killed Flash on iOS in 2010. Steve Jobs published "Thoughts on Flash"—a public letter explaining why Flash would never come to iPhone or iPad. His arguments: battery life, security, touch interfaces that don't work with hover states, and Adobe's closed ecosystem.

That was the real death blow. By 2016, mobile traffic had overtaken desktop. If your platform doesn't work on iOS, you're locked out of half the mobile web. Chrome disabling Flash just finished what Jobs started six years earlier.

Why browser vendors hate Flash

Battery and optimization

Flash was the only consistent way to play videos across platforms and browsers. This hindered browser innovation on video performance.

The issue wasn't Adobe's effort—Adobe worked on hardware acceleration for Flash video. The problem was architectural: Flash Player was a plugin black box that browsers couldn't optimize or control.

When browsers control video through native APIs, they can:

Coordinate with device hardware: Use device-specific video decode chips (common in mobile SoCs) that are far more power-efficient than CPU decoding. Flash couldn't access these because the plugin sandbox prevented deep OS integration.

Manage power states: Pause or throttle playback when tabs are backgrounded. Adjust bitrate based on battery level. Flash kept decoding in the background regardless of tab state.

Adapt to network conditions: Switch video quality based on cellular vs WiFi, signal strength, and data caps. Flash had its own network stack that couldn't see mobile-specific conditions.

Handle thermal throttling: Mobile devices throttle CPU when overheating. Browsers can reduce video quality to prevent thermal issues. Flash had no visibility into thermal state.

This mattered most on mobile devices where battery life, thermal constraints, and variable network conditions are critical. A plugin architecture that worked on desktop PCs with unlimited power became a liability when phones became the dominant platform.

Adobe lock-in and HTML5 video maturity

Flash meant Adobe's ecosystem, and browsers prefer open standards. Flash represented the opposite of that preference.

By 2016, HTML5 video had caught up. The <video> tag gave browsers native playback. Media Source Extensions (MSE) enabled adaptive streaming. Encrypted Media Extensions (EME) solved the DRM problem that kept Netflix on Flash for years.

Flash stuck around so long partly because Mozilla refused to implement DRM. Netflix needed DRM and wouldn't move to HTML5 without it. When Mozilla reversed its anti-DRM stance and implemented EME, the last major reason to keep Flash disappeared.

With native browser APIs handling video, browsers could introduce features Flash never could: tab-based muting, picture-in-picture, background throttling, and OS media controls integration. Flash couldn't do any of this inside the plugin sandbox.

Security vulnerabilities

Flash had constant zero-day exploits requiring emergency patches. I saw this firsthand—our ad ops teams dealt with clients panicking over Flash vulnerabilities that could compromise user systems through banner ads.

Flash runs a complex runtime with its own networking, rendering, and scripting engine. Vulnerabilities could bypass browser security sandboxes entirely. Browser vendors defended against attacks they couldn't control—every Flash vulnerability reflected poorly on the browser even though Adobe was responsible for patching.

Moving to native HTML5 meant browsers could control and harden the entire stack.

Privacy issues

Flash implements its own cookies (Local Shared Objects) that browsers can't clear on user command. I saw ad tracking companies take advantage of this—users cleared browser cookies thinking they'd reset tracking, but Flash cookies persisted.

Browsers can't manage what they don't control. By 2016, browsers had added ways to clear Flash cookies, but the fundamental issue remained: plugin architecture meant giving up privacy control to Adobe.

Who loses as Flash disappears?

Advertisers are key Flash users, and blocking Flash effectively removes ads for end users. Browsers get happy users, while publishers lost monetization.

Designers couldn't figure out how to build advertisements in JavaScript productively. A designer using Animate CC was crippled by the lack of JavaScript export and scripting within Animate CC.

Some advertising companies are losing out too, as transiting inventory away from Flash is far from easy.

Adobe tried to adapt with Animate CC (formerly Flash Professional), but the HTML5 transition was rocky. If you were working with Animate CC during this transition, I wrote about building custom HTML5 components for Animate CC that might help.