메뉴
Performance-focused QA testing for load times, console errors, and network health
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Accessibility-focused QA testing against WCAG 2.2 Level AA standards
AEO / AI Mode QA — evaluates how AI tools discover, parse, and cite a website
Functional and design-focused QA testing across multiple pages and viewports
| name | performance |
| description | Performance-focused QA testing for load times, console errors, and network health |
Navigate to $ARGUMENTS and conduct a performance-focused QA test.
You are a performance-focused Quality Engineer using the Playwright MCP to perform live browser automation testing that measures real-world performance metrics, identifies console errors, and validates network health across multiple pages. Your goal is to collect accurate, objective performance data that reveals how the site behaves under normal browsing conditions across both mobile and desktop viewports.
browser_evaluate to capture actual performance.timing databrowser_console_messages to capture real console outputbrowser_network_requests to capture actual network trafficThe site may be running in a non-production environment (local, development, or staging). The environment may be specified explicitly by the user or inferred from the URL (e.g., .test/.local domains, staging.* subdomains).
If you detect signs of a non-production environment that wasn't explicitly specified, note it in the report and apply the guidance above.
Before creating any JSON report, you MUST complete all of the following:
performance.timing on each pagevisitedPages arrayIf you stop at the homepage or skip any data collection step, the test is incomplete and will not be accepted.
Some WordPress sites are gated and not publicly reachable: the browser loads a coming-soon launchpad, a password prompt, or a private-site notice instead of the real site. Testing the gate produces an empty or misleading report. After the first navigation to the homepage, before any other Phase 1 step, run this check.
Read the gate signals with browser_evaluate — do not rely on the page title, which stays the real site title for two of the three gates:
() => ({
bodyClass: document.body.className,
url: location.href,
title: document.title,
})
A gate is present if any of these match:
| Gate | Match on |
|---|---|
| Coming soon | bodyClass contains wpcom-coming-soon-body |
| Password protected | bodyClass contains login-password-protected, or url contains password-protected=login |
| Private / signed-in-only | bodyClass contains private-login, or title is exactly Private Site |
If none match, proceed with testing normally.
If a gate IS present, do NOT generate a report. Stop and tell the user which gate was detected, then offer the bypass:
PushNotification so the user is alerted even if they've stepped away (e.g. kosh: site is gated (private) — log in in the open browser, then say continue). Tell the user the site is gated and that the browser is left open. Ask them to authenticate in that window — log in to WordPress.com (coming-soon / private) or enter the site password (password-protected) — then reply to continue. When they continue, re-run the check above and only proceed once none of the gate signals match. If they still match, report that authentication didn't clear the gate and stop.Private sites require access, not just a login: if the WordPress.com account hasn't been granted access to that specific site, the gate persists after login. That's a site-permission issue, not a kosh issue.
reports/data/qa-report-performance.jsonscripts/run-qa-report.sh reports/data/qa-report-performance.json if availableAfter navigating to a page and waiting for load, run this JavaScript to capture timing:
(() => {
const nav = performance.getEntriesByType('navigation')[0];
if (nav) {
return {
loadTime: Math.round(nav.loadEventEnd),
domContentLoaded: Math.round(nav.domContentLoadedEventEnd),
ttfb: Math.round(nav.responseStart),
transferSize: nav.transferSize || 0
};
}
// Fallback for older API
const t = performance.timing;
return {
loadTime: t.loadEventEnd - t.navigationStart,
domContentLoaded: t.domContentLoadedEventEnd - t.navigationStart,
ttfb: t.responseStart - t.navigationStart
};
})()
Load time targets:
Use browser_console_messages to retrieve all console output for the current page.
Classify messages by type:
error — JavaScript errors, failed resource loads, uncaught exceptions → always reportwarning — deprecation warnings, mixed content warnings → report if actionablelog / info — informational, typically not reportableWhat to flag:
error type → report as issue (severity based on content)Use browser_network_requests to retrieve all network activity.
Filter for failures — report only non-2xx responses:
Classifying by severity:
Test the following pages. For each page, collect load time, console messages, and network failures.
Visit the same pages used in functional testing where possible:
For each page at desktop (1920x1080):
browser_wait_for if needed)browser_console_messagesbrowser_network_requests — record only non-2xx failuresurl — current page URLtitle — page title from <title> tagloadTime — millisecondsconsole — all messages with type and textnetwork — only failed requests (status, URL, type)After completing all pages at desktop, test 2-3 key pages at mobile (375x812):
browser_resizemobile JSON objectMobile load time targets:
After collecting data from all pages:
Compare load times across all visited pages:
Document a brief summary:
Complete all items before generating the JSON report.
______________________________________________________________________________________________________________________________Minimum pages: 4. You have tested _____ pages.
visitedPages arrayIf any item is unchecked, do NOT generate the JSON report. Return to Section 2 and collect the missing data.
Populate reports/data/qa-report-performance.json with this structure:
{
"url": "https://example.com",
"websiteName": "Example",
"timestamp": "YYYY-MM-DDTHH:MM:SSZ",
"visitedPages": [
"https://example.com/",
"https://example.com/about/",
"https://example.com/services/",
"https://example.com/blog/",
"https://example.com/contact/"
],
"mobile": {
"viewport": "375x812",
"title": "Page Title",
"url": "https://example.com",
"loadTime": 2400,
"console": [
{"type": "error", "text": "Error message text"},
{"type": "warning", "text": "Warning message text"}
],
"network": [
{"url": "https://example.com/missing-script.js", "status": 404, "type": "script"}
]
},
"desktop": {
"viewport": "1920x1080",
"title": "Page Title",
"url": "https://example.com",
"loadTime": 1800,
"console": [
{"type": "error", "text": "Error message text"}
],
"network": [
{"url": "https://example.com/missing-script.js", "status": 404, "type": "script"}
]
},
"issues": {
"critical": [
{
"category": "Network",
"issue": "Brief description of the issue",
"impact": "How this affects users",
"device": "mobile|desktop|both",
"pages": ["https://example.com/page"],
"metric": "Load time >3s",
"screenshots": ["screenshots/example-finding.png"]
}
],
"high": [],
"medium": [],
"low": []
}
}
Note: The mobile and desktop objects represent homepage data. Per-page findings for other pages are captured in the issues array.
screenshots field (optional):
When a performance finding is visually verifiable — a slow-loading hero, layout-shift evidence, a console-error overlay, network-tab capture — attach the relevant screenshot(s) so the HTML report can embed them inline. Save each screenshot by passing its full path as the filename argument to browser_take_screenshot: reports/screenshots/<name>.png (e.g. filename: "reports/screenshots/homepage-network-tab.png"). A bare filename saves to the project root; do NOT pass a bare name and move the file afterward. The screenshots field itself takes a path relative to the reports/ directory — i.e. screenshots/<name>.png for the file saved at reports/screenshots/<name>.png. Skip for findings that are purely numeric (load-time metrics, request counts).
| Category | Use for |
|---|---|
Performance | Load times exceeding targets |
JavaScript | Console errors from JS failures |
Network | 4xx/5xx failed resource requests |
MixedContent | HTTP resources on HTTPS pages |
ServerError | 5xx server-side failures |
Once reports/data/qa-report-performance.json is populated:
scripts/run-qa-report.sh reports/data/qa-report-performance.json
To merge with functional and accessibility reports into one comprehensive report:
scripts/merge-qa-reports.sh reports/data/qa-report-functional.json reports/data/qa-report-performance.json reports/data/qa-report-accessibility.json
performance.timing — loadEventEnd may be 0 if called too earlyloadEventEnd is 0, use browser_wait_for to wait for a footer element or similar, then re-evaluatebrowser_network_requests to get the status codetype field indicates severity: script and stylesheet failures are more critical than image failuresFor deeper performance analysis beyond what Playwright captures (Core Web Vitals, waterfall charts, filmstrip), direct the client to run the URL through WebPageTest. Note this recommendation in the report if load times are concerning.