Summary

Homeboy traces show a promising Studio-owned path to materially speed up new bundled site creation: place a preinstalled SQLite database in the site before Playground starts, so the existing Playground boot path detects an installed WordPress site and skips the first-run install work.

This is not product-ready yet, but the diagnostic evidence is strong enough to track upstream.

Problem

Creating a new bundled Studio site currently spends a meaningful amount of critical-path time doing first-run WordPress install work after the site files and SQLite integration are already present.

The measured boot segment includes expensive spans for:

• install.request
• install.verify
• install.permalink
• database.validate

The install-related spans are large enough that avoiding them changes the user-visible create-site path, not just internal micro-timing.

Diagnostic experiment

A diagnostic Studio trace hook copied a previously installed SQLite database to:

wp-content/database/.ht.sqlite

before launching Playground for a new bundled site.

With that DB present, existing Playground behavior detected the site as already installed and skipped the install request, verify, and permalink setup spans.

No Playground changes were required for this diagnostic path.

Results

Measured with Homeboy trace on the Studio create-site scenario.

Full create-site path

baseline median: 8733ms
seeded median:   6497ms
delta:          -2236ms (-25.6%)

WordPress boot segment

baseline median: 2596ms
seeded median:   1113ms
delta:          -1483ms (-57.1%)

Boot-step repeat sample

baseline boot median: 2734ms
seeded boot median:   1124ms
delta:               -1610ms (-58.9%)

Removed spans in seeded path

The seeded path no longer emitted these install spans:

• phase.install_request_start_to_install_request_ready
• phase.install_verify_start_to_install_verify_ready
• phase.install_permalink_start_to_install_permalink_ready

Basic surface checks

A follow-up smoke added HTTP surface checks after Studio reported the site as running:

• frontend / returned 200
• REST API /wp-json/ returned 200
• wp-admin /wp-admin/ was reachable and redirected to login with 200

Caveats

The current seed DB is diagnostic only. It was captured from a concrete completed trace site and still contains site-specific state such as:

• siteurl
• home
• blogname
• admin user/email state
• any other install-time assumptions persisted by WordPress

A product implementation should not copy that DB directly.

Proposed product direction

Implement a Studio-owned fresh-site SQLite template path for new bundled sites:

1. Generate or package a known-good fresh-site SQLite template DB for the bundled WordPress build.
2. Specialize the DB per new site before first boot:
   • site URL
   • home URL
   • site title
   • admin user/email/password state as needed
   • permalink/options expected by Studio
3. Validate the specialized DB before using it.
4. Fall back to the current install path if validation fails.
5. Add e2e/trace guardrails proving:
   • Studio reaches running state
   • frontend loads
   • REST loads
   • wp-admin is reachable
   • restart still works
   • site title/admin/permalinks are correct

Scope recommendation

Keep the first PR focused on the preinstalled SQLite template path only.

Other investigated candidates were smaller or riskier:

• disabling mail during install was weak/noisy
• forcing fresh install mode was a small standalone win
• skipping install verification/permalink/database validation is useful evidence, but too risky as a product shortcut
• app/daemon/runtime prewarming remains promising, but is a larger architecture track

The template path is the strongest measured candidate and is large enough to justify its own focused PR.

Possible follow-up

If this lands cleanly in Studio, consider a later Playground issue/PR for a first-class generic contract around preinstalled site templates. The diagnostic evidence suggests the first product experiment can be Studio-first, but a formal Playground contract may be cleaner long-term.

Related prior work

A quick search did not find an existing Studio or Playground issue for this exact optimization: generating a fresh-site SQLite template for Studio new-site creation and specializing it before first boot.

Relevant nearby Playground work:

• Boot protocol WordPress/wordpress-playground#1398 — Boot protocol. This is the closest architectural prior art. It describes bootWordPress as the central boot path, explicitly includes database setup from wp-content or /internal/shared/.ht.sqlite, and says the boot flow should check is_blog_installed() and skip installation when WordPress is already installed. It also notes that playground.wordpress.net should still ship a pre-installed .ht.sqlite database.
• Full-site Export / Import Format WordPress/wordpress-playground#1563 — Full-site Export / Import Format. This proposes including a SQLite database dump in exported site bundles specifically to enable fast loading in Playground, which supports the same broad idea: SQLite state can be a fast boot/import primitive when generated safely.
• Allow configuring the SQLite integration plugin path so hosts can manage it on disk WordPress/wordpress-playground#3522 — Allow configuring the SQLite integration plugin path so hosts can manage it on disk. This is not about preinstalled DB templates, but it is directly related to Studio/Playground ownership boundaries around SQLite site materialization.
• Database: make it clear where sqlite file resides WordPress/wordpress-playground#912 — Database: make it clear where sqlite file resides. Documents the canonical Playground SQLite DB location at /wp-content/database/.ht.sqlite, which is the path used by the diagnostic experiment.

Interpretation: the proposed Studio path is consistent with the Playground boot protocol direction, but this issue adds new Studio-specific trace evidence and a narrower product candidate: use a generated/specialized SQLite template to speed up Studio's bundled new-site creation without requiring an immediate Playground API change.