Default throttling to Lighthouse Slow 4G (realistic, PSI-aligned)

[sashakhar1]

The default Lighthouse throttle was inflated - 700 Kbps / 300 ms RTT / cpu 20x, about 2.3x harsher on network and 5x on CPU than real "Slow 4G" - so reported timings ran ~2.4x too slow.

This switches DEFAULT_LH_CONFIG to the canonical Slow 4G profile (rttMs 150, throughputKbps 1638.4, cpu 4 - the constants PSI uses); method stays simulate.

• Relative A/B comparisons are unaffected; only absolute numbers move.
• Per-project lighthouseConfig still overrides everything (integration snapshots unchanged).
• CPU multiplier: 4 by default, 6 on CI, or SHAKAPERF_CPU_MULTIPLIER for a one-off (invalid values warn).

Old default scored a real site 60/100 (LCP 6.5s); Slow 4G lands it in the PSI range (which itself swings 74-92).

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 53f6923e-c016-42e0-bcde-42c712f1b063

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch sasha/realistic-cpu-throttle-default

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR replaces the inflated default Lighthouse throttling profile (700 Kbps / 300 ms RTT / cpu×20) with the canonical Slow 4G preset that PageSpeed Insights uses (1638.4 Kbps / 150 ms RTT / cpu×4), and adds a SHAKAPERF_CPU_MULTIPLIER env-var escape hatch so one-off overrides don't require a config change.

• DEFAULT_LH_CONFIG throttling values are updated to the PSI Slow 4G constants; all derived values (requestLatencyMs = rttMs × 3.75, downloadThroughputKbps = throughputKbps × 0.9) are internally consistent.
• getMobileSettings now resolves the CPU multiplier through a three-tier precedence: SHAKAPERF_CPU_MULTIPLIER env var → CI constant (6) → default from DEFAULT_LH_CONFIG (4), with a console.warn for invalid env values.
• Absolute scores will shift for any project that relied on the old default; relative A/B comparisons and per-project lighthouseConfig overrides are unaffected.

Confidence Score: 4/5

Safe to merge; the throttling values match the canonical PSI Slow 4G preset and the CPU-multiplier selection logic is correct across all three precedence tiers.

The default CPU multiplier for local non-CI runs drops from 20 to 4, and the implicit coupling between the exported DEFAULT_LH_CONFIG constant and the runtime default in getMobileSettings means a future change to the constant would silently change runtime behavior without touching the worker. Neither issue affects correctness today, but the second one is worth hardening.

packages/shaka-perf/src/bench/core/lighthouse-worker.ts — the CPU-multiplier resolution logic; no issues in lighthouse-config.ts.

Important Files Changed

Filename	Overview
packages/shaka-perf/src/bench/core/lighthouse-config.ts	Throttling defaults updated to canonical Lighthouse Slow 4G / PSI profile (rttMs 150, throughputKbps 1638.4, cpuSlowdownMultiplier 4); values and derivations are internally consistent.
packages/shaka-perf/src/bench/core/lighthouse-worker.ts	CPU-multiplier selection refactored to support SHAKAPERF_CPU_MULTIPLIER env var, CI override (6), and the new default (4); logic is correct, but a non-CI local run silently drops from cpu×20 to cpu×4 without any runtime notice.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[getMobileSettings called] --> B{SHAKAPERF_CPU_MULTIPLIER set?}
    B -- "yes, non-empty string" --> C{Is it a finite positive number?}
    C -- yes --> D[cpuOverride = envCpuMultiplier]
    C -- no --> E[warn: ignoring env var\ncpuOverride = CI check]
    B -- "no / empty" --> E
    E --> F{process.env.CI truthy?}
    F -- yes --> G[cpuOverride = 6]
    F -- no --> H[cpuOverride = undefined]
    D --> I[throttling = DEFAULT_LH_CONFIG.throttling\n+ cpuSlowdownMultiplier override]
    G --> I
    H --> J[throttling = DEFAULT_LH_CONFIG.throttling\ncpuSlowdownMultiplier stays at 4]
    I --> K[Return merged LH settings]
    J --> K
    K --> L[sample: spread msg.options.lhConfig on top\nper-project config wins everything]

Loading

_{Reviews (1): Last reviewed commit: "default throttling to Lighthouse Slow 4G..." | Re-trigger Greptile}

[greptile-apps]

When cpuOverride is undefined the spread adds nothing, so cpuSlowdownMultiplier is whatever DEFAULT_LH_CONFIG.throttling carries (currently 4). That coupling is correct today, but it means a future edit to the exported constant silently changes the runtime default without touching this function. Explicitly defaulting here makes the intent self-documenting and defensive against config drift.

Suggested change

	const cpuOverride = hasEnvCpuMultiplier ? envCpuMultiplier : (process.env.CI ? 6 : undefined);
	return {
	...defaultConfig?.settings,
	...DEFAULT_LH_CONFIG,
	throttling: {
	...DEFAULT_LH_CONFIG.throttling as object,
	cpuSlowdownMultiplier: process.env.CI ? 6 : 20,
	...(cpuOverride !== undefined ? { cpuSlowdownMultiplier: cpuOverride } : {}),
	},
	const cpuOverride = hasEnvCpuMultiplier
	? envCpuMultiplier
	: process.env.CI
	? 6
	: DEFAULT_LH_CONFIG.throttling!.cpuSlowdownMultiplier ?? 4;
	return {
	...defaultConfig?.settings,
	...DEFAULT_LH_CONFIG,
	throttling: {
	...DEFAULT_LH_CONFIG.throttling as object,
	cpuSlowdownMultiplier: cpuOverride,
	},

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!