Add a script to benchmark site editor performance

[gcsecsey]

Related issues

• Related to STU-1199

Proposed Changes

Add a Playwright test that benchmarks the performance of some actions within the Site Editor. It measures load times for each step of a typical site editing workflow.

The benchmark measures the time taken for the following steps:

1. wp-admin Load - Time to open /wp-admin with auto-login
2. Site Editor Load - Time to navigate to the site editor and wait for it to fully load
3. Templates View Load - Time to open the Templates view and wait for templates to load
4. Template Open - Time to open a specific template in the editor
5. Block Add - Time to add two blocks (paragraph and heading) to the template
6. Template Save - Time to save the template

We can use the reported timings to compare load times across different environments (studio, playground cli, playground.wordpress.net)

Testing Instructions

Prerequisites

• A running WordPress instance accessible via URL
• The WordPress instance should have the Site Editor enabled
• For local testing, you can use:
  • Studio (local WordPress site)
  • Playground CLI (npx @wp-playground/cli@latest server)
  • Any other WordPress installation

Running the test

Set the BENCHMARK_URL environment variable to point to the WordPress instance:

BENCHMARK_URL=http://localhost:8888 npx playwright test --config=./metrics/playwright.metrics.config.ts site-editor-benchmark

Output

After running the test, results are automatically printed to the console as a table, and also saved to metrics/artifacts/site-editor-benchmark.results.json.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

In general, to avoid incomplete URL substring sanitization, parse the URL and make decisions based on its host (or hostname) rather than searching for substrings in the full URL string. If you need to detect a specific domain (or one of its subdomains), compare the parsed host against an explicit list or check that it matches exactly or ends with a known suffix and a dot boundary.

In this specific file, the problematic logic is the creation of urlIdentifier:

const urlIdentifier = urlKey.includes( 'playground.wordpress.net' )
    ? 'playground-web'
    : urlKey
            .replace( /^https?:\/\//, '' )
            .replace( /\/$/, '' )
            .replace( /[^a-z0-9]/gi, '-' );

We should instead parse urlKey with the standard URL class, extract hostname, and then decide whether the hostname is exactly playground.wordpress.net or a subdomain such as foo.playground.wordpress.net. Then we construct urlIdentifier from the hostname/path as before for all other hosts. To keep behavior similar and avoid assumptions about other code, we’ll:

• Add a small helper function getUrlIdentifier(urlKey: string): string in this test file.
• Inside it, safely parse urlKey using the built-in URL constructor when possible; on parse failure, fall back to the existing string-based transformation.
• Determine whether the parsed hostname equals playground.wordpress.net or ends with .playground.wordpress.net. If so, return 'playground-web'; otherwise, apply the same replace chain as before on the original urlKey.

This change is entirely local to metrics/tests/site-editor-benchmark.test.ts and does not require modifying other files.

In general, to fix this kind of issue you should parse the URL string into a URL object and perform host-based checks on the parsed hostname (and possibly protocol), rather than doing substring checks on the full URL text. That ensures that you only match the actual host, not occurrences in the path, query, or a different host name (e.g., example.com.evil.com).

For this specific file, the best fix is to replace wpAdminUrl.includes('playground.wordpress.net') with a check on the parsed hostname of wpAdminUrl. Since this is Node/TypeScript test code, we can safely use the built-in URL class (new URL(...)). The logic should remain functionally equivalent for valid URLs that actually point to Playground, but avoid accidental matches. A robust, minimal-change fix is:

• Ensure wpAdminUrl is a fully qualified URL (already done: it adds http:// if missing).
• Wrap it in new URL(wpAdminUrl) to parse.
• Compare url.hostname to 'playground.wordpress.net' (and optionally accept the bare hostname without protocol or with trailing slash, but in this case we already normalized).

Concretely:

• In metrics/tests/site-editor-benchmark.test.ts, around line 88–90, change:

// Check if this is playground.wordpress.net (runs in iframe)
const isPlaygroundWeb = wpAdminUrl.includes( 'playground.wordpress.net' );

to:

// Check if this is playground.wordpress.net (runs in iframe) using hostname, not substring
let isPlaygroundWeb = false;
try {
    const parsedUrl = new URL( wpAdminUrl );
    isPlaygroundWeb = parsedUrl.hostname === 'playground.wordpress.net';
} catch {
    isPlaygroundWeb = false;
}

This keeps existing behavior for proper Playground URLs, avoids substring pitfalls, and gracefully handles malformed URLs by treating them as non-Playground. No new imports are necessary because URL is globally available in modern Node, and we are not changing any other behavior or public API.