flutter test --platform=chrome per-suite load time regressed ~40% after --no-js-strongly-connected-components

After #193485 ("Set --no-js-strongly-connected-components for DDC compiles by default") landed, flutter test --platform=chrome takes noticeably longer to load each test suite. DDC now emits one JS file per library, and each test suite gets its own iframe that loads the full set of scripts, so every suite pays the larger script count again.

In flutter/packages CI, the per-suite load time for packages/material_ui went from ~3.2 s to ~4.5–5 s on the master channel at the roll that brought in #193485. The number of scripts each suite loads went from 1053 to 1537. Stable doesn't include #193485 yet and stayed flat at ~2.2 s over the same period.

Note: I'm not sure why stable was already ~1 s faster than master. That requires further investigation.

That PR's description says overall load time improves for large apps. For the web test runner the trade-off goes the other way: a package with N test files loads the app N times.

Impact

packages/material_ui has ~214 test files in test/ and ~279 in example/.
On master CI, loading suites accounts for roughly 35 of the ~43 minutes
of its web unit test step.
Stable will pick up the same slowdown when Set --no-js-strongly-connected-components for DDC compiles by default #193485 reaches a stable release.

Evidence

Step change lines up with the roll that includes #193485

flutter/packages postsubmit, builder Linux_web web_dart_unit_test_shard_N master, package packages/material_ui. The "load time" column is the mean number of seconds between a loading <file> progress line and the next progress line, averaged over every suite in the package.

Date (UTC)	packages commit	Flutter master pinned	Load time per suite	Scripts per suite	Build
2026-09-26	`15e15cc9ed`	`55b8f88e855f`	3.27 s	—	8669642115610387905
2026-09-30 09:04	`46c82808de`	`55b8f88e855f`	3.22 s	1053	8669246716962923297
—	`913650f58d`	Roll `55b8f88e855f` → `d649d2bfebfe` (flutter/packages#13080), includes `b2977965ce` (#193485)
2026-09-30 21:06	`6f110204ca`	`d649d2bfebfe`	4.65 s	1537	8669201311584671601
2026-10-01	`d5ec6dbaf1`		4.29 s	—	8669187090472438001
2026-10-14	`975717a8bb`		5.19 s	—	8667954581964520465
2026-10-28	`13d38e0d97`		4.76 s	1564	8666728765165495921

The script counts come from DDC's own console output in the test logs:

[BROWSER CONSOLE] [info]: DDC is about to load 1053/1053 scripts with pool size = 100   # before
[BROWSER CONSOLE] [info]: DDC is about to load 1537/1537 scripts with pool size = 100   # after

From July to September, ~20 sampled master builds were steady at 2.8–3.5 s (occasionally 3.9 s), then jumped at this roll. Of the 27 framework commits in the roll, #193485 is the only one that changes DDC compilation or module output.

Ruled out: Chrome version

Master went from Chrome 125 to 145 on 2026-08-19 (Fix chrome 145 web tests packages#12486).
The load time didn't change: 3.10 s on Aug 13, 2.76 s on Aug 20.
Stable went from Chrome 125 to 137 on 2026-09-04 (Update Chrome for stable tests packages#12747).
The load time didn't change: ~2.2 s throughout.

Reproduction (suggested)

git clone https://github.com/flutter/packages && cd packages/packages/material_ui
# With a Flutter checkout at b2977965ce^ and then at b2977965ce:
flutter test --platform=chrome test/

Compare the time between consecutive loading ... lines, or the total wall time.

Note: The above analysis performed by a CI analysis SKILL I am working on productionizing. For now, you can find it here.

This has pushed the time to run all the material_ui web tests in flutter/packages over the 90-minute timeout. The timeouts are blocking the flutter/flutter → flutter/packages roller. I've opened flutter/packages#13537 to temporarily disable the tests while we find a longterm solution.

@Markzipan

Some offline discussion notes with @Markzipan and @nshahan :

flutter/flutter and flutter/packages both use --platform=chrome to run web tests. This is a custom test runner in Flutter tool that only exists to test flutter/flutter and flutter/packages, and should not be used outside of these repos. Web tests using --platform=chromewere set up influtter/packages` as part of [ci] Add a web version of Dart unit tests packages#4352

There is a comment saying it "may be removed entirely in the future"

flutter/packages/flutter_tools/lib/src/commands/test.dart

Lines 269 to 286 in 5253d01

    
           // --platform is not supported to be used by Flutter developers. It only 
        
           // exists to test the Flutter framework itself and may be removed entirely 
        
           // in the future. Developers should either use plain `flutter test`, or 
        
           // `package:integration_test` instead. 
        
           static const _platform = DefaultedStringOptionDescriptor( 
        
             name: 'platform', 
        
             allowed: <String>['tester', 'chrome'], 
        
             verboseOnly: true, 
        
             defaultsTo: 'tester', 
        
             help: 'Selects the test backend.', 
        
             allowedHelp: <String, String>{ 
        
               'tester': 'Run tests using the VM-based test environment.', 
        
               'chrome': 
        
                   '(deprecated) Run tests using the Google Chrome web browser. ' 
        
                   'This value is intended for testing the Flutter framework ' 
        
                   'itself and may be removed at any time.', 
        
             }, 
        
           );

- we should get clarity on whether or not this is supported.

as a workaround, we could disable --no-js-strongly-connected-components for --platform=chrome tests.

[material_ui] Temporarily exclude material_ui from non-Wasm web unit …

@Markzipan

@Markzipan @nshahan is this expected?

@Markzipan

It makes sense with the change @Markzipan landed to improve the compile times of apps with large library cycles. Now all libraries are compiled into separate files and this does cause more load requests at runtime in the browser. In environments like CI where the resources are low this can increase the time of the initial page load.

A short term fix could be to revert that change for this setting only. The flutter test --platform=chrome is documented as unsupported and only exists for the flutter framework tests so the impact should be low. @mdebbar have you noticed a regression on the flutter framework tests around the same time?

A long term fix would be to compile all libraries into separate JavaScript files for quick compile time and then the web server could concatenate them into a smaller number of larger JavaScript files when serving. The server would also need to update the sourcemap files to reflect the locations in the new files that gets loaded in the browser.

@elliette

@mdebbar have you noticed a regression on the flutter framework tests around the same time?

Yes, the framework CanvasKit shards regressed by ~10–25% (+83–151s per shard) right at b297796. On Linux web_canvaskit_tests_0, DDC script count per suite went from 818 (build 27454) to 1181 (build 27453), increasing total suite load time across the 112 suites from 401s to 536s (+33.7%).

About --platform=chrome: packages/flutter_tools/lib/src/commands/test.dart does mark it (deprecated) and framework-only in flutter test -h -v, though our own docs (docs/ecosystem/testing/Plugin-Tests.md and docs.flutter.dev) still tell developers to use it for *_web packages and Wasm testing. Either way, we rely on it heavily in both flutter/flutter and flutter/packages.

On the fix side, I have #196414 open to add Cache-Control headers for immutable web test assets (flutter.js, dart_sdk.js, *.dart.lib.js, etc.), which Chrome was re-fetching for every suite iframe. On Linux web_canvaskit_tests_6, that cut suite load time by 72.8% (438.8s → 119.4s).

@elliette Could you hold off on merging flutter/packages#13536 until #196414 lands and rolls into flutter/packages? It might speed up material_ui enough on its own that we won't need the tag-filtering workaround.

[flutter_tools] Add `Cache-Control` headers for web test assets (flut…

There were 4 flutter roll attempts so far (that failed for unrelated reasons), and their test durations are very promising:

These numbers may not be apples-to-apples (presubmit vs postsubmit) so I'll wait until a roll lands and we have some postsubmit numbers.

Navigation Menu

Repository navigation

`flutter test --platform=chrome` per-suite load time regressed ~40% after `--no-js-strongly-connected-components` #195700

Impact

Evidence

Step change lines up with the roll that includes #193485

Ruled out: Chrome version

Reproduction (suggested)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// --platform is not supported to be used by Flutter developers. It only
	// exists to test the Flutter framework itself and may be removed entirely
	// in the future. Developers should either use plain `flutter test`, or
	// `package:integration_test` instead.
	static const _platform = DefaultedStringOptionDescriptor(
	name: 'platform',
	allowed: <String>['tester', 'chrome'],
	verboseOnly: true,
	defaultsTo: 'tester',
	help: 'Selects the test backend.',
	allowedHelp: <String, String>{
	'tester': 'Run tests using the VM-based test environment.',
	'chrome':
	'(deprecated) Run tests using the Google Chrome web browser. '
	'This value is intended for testing the Flutter framework '
	'itself and may be removed at any time.',
	},
	);

flutter test --platform=chrome per-suite load time regressed ~40% after --no-js-strongly-connected-components #195700

Description

Impact

Evidence

Step change lines up with the roll that includes #193485

Ruled out: Chrome version

Reproduction (suggested)

Activity

elliette commented on Nov 2, 2026

elliette commented on Nov 2, 2026

mdebbar commented on Nov 11, 2026

nshahan commented on Nov 11, 2026

mdebbar commented on Nov 12, 2026

mdebbar commented on Nov 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`flutter test --platform=chrome` per-suite load time regressed ~40% after `--no-js-strongly-connected-components` #195700