chrome-devtools-mcp 1.3.0 → 1.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +37 -2
- package/build/src/bin/check-latest-version.js +1 -0
- package/build/src/bin/chrome-devtools-mcp-cli-options.js +2 -2
- package/build/src/formatters/NetworkFormatter.js +3 -1
- package/build/src/third_party/THIRD_PARTY_NOTICES +3 -3
- package/build/src/third_party/bundled-packages.json +3 -3
- package/build/src/third_party/devtools-heap-snapshot-worker.js +13 -0
- package/build/src/third_party/index.js +1522 -230
- package/build/src/utils/check-for-updates.js +1 -0
- package/build/src/version.js +1 -1
- package/package.json +7 -6
- package/skills/a11y-debugging/SKILL.md +89 -0
- package/skills/a11y-debugging/references/a11y-snippets.md +92 -0
- package/skills/chrome-devtools/SKILL.md +72 -0
- package/skills/chrome-devtools-cli/SKILL.md +153 -0
- package/skills/chrome-devtools-cli/references/installation.md +14 -0
- package/skills/debug-optimize-lcp/SKILL.md +121 -0
- package/skills/debug-optimize-lcp/references/elements-and-size.md +27 -0
- package/skills/debug-optimize-lcp/references/lcp-breakdown.md +23 -0
- package/skills/debug-optimize-lcp/references/lcp-snippets.md +79 -0
- package/skills/debug-optimize-lcp/references/optimization-strategies.md +38 -0
- package/skills/memory-leak-debugging/SKILL.md +50 -0
- package/skills/memory-leak-debugging/references/common-leaks.md +33 -0
- package/skills/memory-leak-debugging/references/compare_snapshots.js +109 -0
- package/skills/memory-leak-debugging/references/memlab.md +29 -0
- package/skills/troubleshooting/SKILL.md +98 -0
package/build/src/version.js
CHANGED
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "chrome-devtools-mcp",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.4.0",
|
|
4
4
|
"description": "MCP server for Chrome DevTools",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -35,6 +35,7 @@
|
|
|
35
35
|
"files": [
|
|
36
36
|
"build/src",
|
|
37
37
|
"LICENSE",
|
|
38
|
+
"skills",
|
|
38
39
|
"!*.tsbuildinfo",
|
|
39
40
|
"!*.js.map"
|
|
40
41
|
],
|
|
@@ -57,23 +58,23 @@
|
|
|
57
58
|
"@toon-format/toon": "^2.2.0",
|
|
58
59
|
"@types/debug": "^4.1.12",
|
|
59
60
|
"@types/filesystem": "^0.0.36",
|
|
60
|
-
"@types/node": "^
|
|
61
|
+
"@types/node": "^26.0.0",
|
|
61
62
|
"@types/semver": "^7.7.1",
|
|
62
63
|
"@types/sinon": "^21.0.0",
|
|
63
64
|
"@types/yargs": "^17.0.33",
|
|
64
65
|
"@typescript-eslint/eslint-plugin": "^8.43.0",
|
|
65
66
|
"@typescript-eslint/parser": "^8.43.0",
|
|
66
|
-
"chrome-devtools-frontend": "1.0.
|
|
67
|
+
"chrome-devtools-frontend": "1.0.1650035",
|
|
67
68
|
"core-js": "3.49.0",
|
|
68
69
|
"debug": "4.4.3",
|
|
69
70
|
"eslint": "^9.35.0",
|
|
70
71
|
"eslint-import-resolver-typescript": "^4.4.4",
|
|
71
72
|
"eslint-plugin-import": "^2.32.0",
|
|
72
73
|
"globals": "^17.0.0",
|
|
73
|
-
"lighthouse": "13.
|
|
74
|
+
"lighthouse": "13.4.0",
|
|
74
75
|
"prettier": "^3.6.2",
|
|
75
|
-
"puppeteer": "25.
|
|
76
|
-
"rollup": "4.
|
|
76
|
+
"puppeteer": "25.2.0",
|
|
77
|
+
"rollup": "4.62.2",
|
|
77
78
|
"rollup-plugin-cleanup": "^3.2.1",
|
|
78
79
|
"rollup-plugin-license": "^3.6.0",
|
|
79
80
|
"semver": "^7.7.4",
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: a11y-debugging
|
|
3
|
+
description: Uses Chrome DevTools MCP for accessibility (a11y) debugging and auditing based on web.dev guidelines. Use when testing semantic HTML, ARIA labels, focus states, keyboard navigation, tap targets, and color contrast.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Core Concepts
|
|
7
|
+
|
|
8
|
+
**Accessibility Tree vs DOM**: Visually hiding an element (e.g., `CSS opacity: 0`) behaves differently for screen readers than `display: none` or `aria-hidden="true"`. The `take_snapshot` tool returns the accessibility tree of the page, which represents what assistive technologies "see", making it the most reliable source of truth for semantic structure.
|
|
9
|
+
|
|
10
|
+
**Reading web.dev documentation**: If you need to research specific accessibility guidelines (like `https://web.dev/articles/accessible-tap-targets`), you can append `.md.txt` to the URL (e.g., `https://web.dev/articles/accessible-tap-targets.md.txt`) to fetch the clean, raw markdown version. This is much easier to read!
|
|
11
|
+
|
|
12
|
+
## Workflow Patterns
|
|
13
|
+
|
|
14
|
+
### 1. Automated Audit (Lighthouse)
|
|
15
|
+
|
|
16
|
+
Start by running a Lighthouse accessibility audit to get a comprehensive baseline. This tool provides a high-level score and lists specific failing elements with remediation advice.
|
|
17
|
+
|
|
18
|
+
1. Run the audit:
|
|
19
|
+
- Set `mode` to `"navigation"` to refresh the page and capture load issues.
|
|
20
|
+
- Set `outputDirPath` (e.g., `/tmp/lh-report`) to save the full JSON report.
|
|
21
|
+
2. **Analyze the Summary**:
|
|
22
|
+
- Check `scores` (0-1 scale). A score < 1 indicates violations.
|
|
23
|
+
- Review `audits.failed` count.
|
|
24
|
+
3. **Review the Report (CRITICAL)**:
|
|
25
|
+
- **Parsing**: Do not read the entire file line-by-line. Use a CLI tool like `jq` or a Node.js one-liner to filter for failures:
|
|
26
|
+
```bash
|
|
27
|
+
# Extract failing audits with their details
|
|
28
|
+
node -e "const r=require('./report.json'); Object.values(r.audits).filter(a=>a.score!==null && a.score<1).forEach(a=>console.log(JSON.stringify({id:a.id, title:a.title, items:a.details?.items})))"
|
|
29
|
+
```
|
|
30
|
+
- This efficiently extracts the `selector` and `snippet` of failing elements without loading the full report into context.
|
|
31
|
+
|
|
32
|
+
### 2. Browser Issues & Audits
|
|
33
|
+
|
|
34
|
+
Chrome automatically checks for common accessibility problems. Use `list_console_messages` to check for these native audits:
|
|
35
|
+
|
|
36
|
+
- `types`: `["issue"]`
|
|
37
|
+
- `includePreservedMessages`: `true` (to catch issues that occurred during page load)
|
|
38
|
+
|
|
39
|
+
This often reveals missing labels, invalid ARIA attributes, and other critical errors without manual investigation.
|
|
40
|
+
|
|
41
|
+
### 3. Semantics & Structure
|
|
42
|
+
|
|
43
|
+
The accessibility tree exposes the heading hierarchy and semantic landmarks.
|
|
44
|
+
|
|
45
|
+
1. Navigate to the page.
|
|
46
|
+
2. Use `take_snapshot` to capture the accessibility tree.
|
|
47
|
+
3. **Check Heading Levels**: Ensure heading levels (`h1`, `h2`, `h3`, etc.) are logical and do not skip levels. The snapshot will include heading roles.
|
|
48
|
+
4. **Content Reordering**: Verify that the DOM order (which drives the accessibility tree) matches the visual reading order. Use `take_screenshot` to inspect the visual layout and compare it against the snapshot structure to catch CSS floats or absolute positioning that jumbles the logical flow.
|
|
49
|
+
|
|
50
|
+
### 4. Labels, Forms & Text Alternatives
|
|
51
|
+
|
|
52
|
+
1. Locate buttons, inputs, and images in the `take_snapshot` output.
|
|
53
|
+
2. Ensure interactive elements have an accessible name (e.g., a button should not just say `""` if it only contains an icon).
|
|
54
|
+
3. **Orphaned Inputs**: Verify that all form inputs have associated labels. Use `evaluate_script` with the **"Find Orphaned Form Inputs" snippet** found in [references/a11y-snippets.md](references/a11y-snippets.md).
|
|
55
|
+
4. Check images for `alt` text.
|
|
56
|
+
|
|
57
|
+
### 5. Focus & Keyboard Navigation
|
|
58
|
+
|
|
59
|
+
Testing "keyboard traps" and proper focus management without visual feedback relies on tracking the focused element.
|
|
60
|
+
|
|
61
|
+
1. Use the `press_key` tool with `"Tab"` or `"Shift+Tab"` to move focus.
|
|
62
|
+
2. Use `take_snapshot` to capture the updated accessibility tree.
|
|
63
|
+
3. Locate the element marked as focused in the snapshot to verify focus moved to the expected interactive element.
|
|
64
|
+
4. If a modal opens, focus must move into the modal and "trap" within it until closed.
|
|
65
|
+
|
|
66
|
+
### 6. Tap Targets and Visuals
|
|
67
|
+
|
|
68
|
+
According to web.dev, tap targets should be at least 48x48 pixels with sufficient spacing. Since the accessibility tree doesn't show sizes, use `evaluate_script` with the **"Measure Tap Target Size" snippet** found in [references/a11y-snippets.md](references/a11y-snippets.md).
|
|
69
|
+
|
|
70
|
+
_Pass the element's `uid` from the snapshot as an argument to `evaluate_script`._
|
|
71
|
+
|
|
72
|
+
### 7. Color Contrast
|
|
73
|
+
|
|
74
|
+
To verify color contrast ratios, start by checking for native accessibility issues:
|
|
75
|
+
|
|
76
|
+
1. Call `list_console_messages` with `types: ["issue"]`.
|
|
77
|
+
2. Look for "Low Contrast" issues in the output.
|
|
78
|
+
|
|
79
|
+
If native audits do not report issues (which may happen in some headless environments) or if you need to check a specific element manually, use `evaluate_script` with the **"Check Color Contrast" snippet** found in [references/a11y-snippets.md](references/a11y-snippets.md).
|
|
80
|
+
|
|
81
|
+
### 8. Global Page Checks
|
|
82
|
+
|
|
83
|
+
Verify document-level accessibility settings often missed in component testing using the **"Global Page Checks" snippet** found in [references/a11y-snippets.md](references/a11y-snippets.md).
|
|
84
|
+
|
|
85
|
+
## Troubleshooting
|
|
86
|
+
|
|
87
|
+
If standard a11y queries fail or the `evaluate_script` snippets return unexpected results:
|
|
88
|
+
|
|
89
|
+
- **Visual Inspection**: If automated scripts cannot determine contrast (e.g., text over gradient images or complex backgrounds), use `take_screenshot` to capture the element. While models cannot measure exact contrast ratios from images, they can visually assess legibility and identify obvious issues.
|
|
@@ -0,0 +1,92 @@
|
|
|
1
|
+
# Accessibility Debugging Snippets
|
|
2
|
+
|
|
3
|
+
Use these JavaScript snippets with the `evaluate_script` tool.
|
|
4
|
+
|
|
5
|
+
## 1. Find Orphaned Form Inputs
|
|
6
|
+
|
|
7
|
+
Finds form inputs that lack an associated label (no `label[for]`, `aria-label`, `aria-labelledby`, or wrapping `<label>`).
|
|
8
|
+
|
|
9
|
+
```js
|
|
10
|
+
() =>
|
|
11
|
+
Array.from(document.querySelectorAll('input, select, textarea'))
|
|
12
|
+
.filter(i => {
|
|
13
|
+
const hasId = i.id && document.querySelector(`label[for="${i.id}"]`);
|
|
14
|
+
const hasAria =
|
|
15
|
+
i.getAttribute('aria-label') || i.getAttribute('aria-labelledby');
|
|
16
|
+
return !hasId && !hasAria && !i.closest('label');
|
|
17
|
+
})
|
|
18
|
+
.map(i => ({
|
|
19
|
+
tag: i.tagName,
|
|
20
|
+
id: i.id,
|
|
21
|
+
name: i.name,
|
|
22
|
+
placeholder: i.placeholder,
|
|
23
|
+
}));
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
## 2. Measure Tap Target Size
|
|
27
|
+
|
|
28
|
+
Returns the bounding box dimensions of an element. Pass the element's `uid` from the snapshot as an argument to `evaluate_script`.
|
|
29
|
+
|
|
30
|
+
```js
|
|
31
|
+
el => {
|
|
32
|
+
const rect = el.getBoundingClientRect();
|
|
33
|
+
return {width: rect.width, height: rect.height};
|
|
34
|
+
};
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## 3. Check Color Contrast
|
|
38
|
+
|
|
39
|
+
Approximates the contrast ratio between an element's text color and background color. Pass the element's `uid` to test against WCAG AA (4.5:1 for normal text, 3:1 for large text).
|
|
40
|
+
|
|
41
|
+
**Note**: This uses a simplified algorithm and may not account for transparency, gradients, or background images. For production-grade auditing, consider injecting `axe-core`.
|
|
42
|
+
|
|
43
|
+
```js
|
|
44
|
+
el => {
|
|
45
|
+
function getRGB(colorStr) {
|
|
46
|
+
const match = colorStr.match(/rgba?\((\d+),\s*(\d+),\s*(\d+)/);
|
|
47
|
+
return match
|
|
48
|
+
? [parseInt(match[1]), parseInt(match[2]), parseInt(match[3])]
|
|
49
|
+
: [255, 255, 255];
|
|
50
|
+
}
|
|
51
|
+
function luminance(r, g, b) {
|
|
52
|
+
const a = [r, g, b].map(function (v) {
|
|
53
|
+
v /= 255;
|
|
54
|
+
return v <= 0.03928 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
|
|
55
|
+
});
|
|
56
|
+
return a[0] * 0.2126 + a[1] * 0.7152 + a[2] * 0.0722;
|
|
57
|
+
}
|
|
58
|
+
|
|
59
|
+
const style = window.getComputedStyle(el);
|
|
60
|
+
const fg = getRGB(style.color);
|
|
61
|
+
let bg = getRGB(style.backgroundColor);
|
|
62
|
+
|
|
63
|
+
const l1 = luminance(fg[0], fg[1], fg[2]);
|
|
64
|
+
const l2 = luminance(bg[0], bg[1], bg[2]);
|
|
65
|
+
const ratio = (Math.max(l1, l2) + 0.05) / (Math.min(l1, l2) + 0.05);
|
|
66
|
+
|
|
67
|
+
return {
|
|
68
|
+
color: style.color,
|
|
69
|
+
bg: style.backgroundColor,
|
|
70
|
+
contrastRatio: ratio.toFixed(2),
|
|
71
|
+
};
|
|
72
|
+
};
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
## 4. Global Page Checks
|
|
76
|
+
|
|
77
|
+
Checks document-level accessibility settings often missed in component testing.
|
|
78
|
+
|
|
79
|
+
```js
|
|
80
|
+
() => ({
|
|
81
|
+
lang:
|
|
82
|
+
document.documentElement.lang ||
|
|
83
|
+
'MISSING - Screen readers need this for pronunciation',
|
|
84
|
+
title: document.title || 'MISSING - Required for context',
|
|
85
|
+
viewport:
|
|
86
|
+
document.querySelector('meta[name="viewport"]')?.content ||
|
|
87
|
+
'MISSING - Check for user-scalable=no (bad practice)',
|
|
88
|
+
reducedMotion: window.matchMedia('(prefers-reduced-motion: reduce)').matches
|
|
89
|
+
? 'Enabled'
|
|
90
|
+
: 'Disabled',
|
|
91
|
+
});
|
|
92
|
+
```
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: chrome-devtools
|
|
3
|
+
description: Uses Chrome DevTools via MCP for efficient debugging, troubleshooting and browser automation. Use when debugging web pages, automating browser interactions, analyzing performance, or inspecting network requests. This skill does not apply to `--slim` mode (MCP configuration).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Core Concepts
|
|
7
|
+
|
|
8
|
+
**Browser lifecycle**: Browser starts automatically on first tool call using a persistent Chrome profile. Configure via CLI args in the MCP server configuration: `npx chrome-devtools-mcp@latest --help`.
|
|
9
|
+
Addional tooling can be enabled by providing the following flags:
|
|
10
|
+
|
|
11
|
+
- For extension tooling, use the `--categoryExtensions` flag.
|
|
12
|
+
- For memory tooling, use the `--memoryDebugging` flag.
|
|
13
|
+
|
|
14
|
+
**Page selection**: Tools operate on the currently selected page. Use `list_pages` to see available pages, then `select_page` to switch context.
|
|
15
|
+
**Element interaction**: Use `take_snapshot` to get page structure with element `uid`s. Each element has a unique `uid` for interaction. If an element isn't found, take a fresh snapshot - the element may have been removed or the page changed.
|
|
16
|
+
|
|
17
|
+
## Workflow Patterns
|
|
18
|
+
|
|
19
|
+
### Before interacting with a page
|
|
20
|
+
|
|
21
|
+
1. Navigate: `navigate_page` or `new_page`
|
|
22
|
+
2. Wait: `wait_for` to ensure content is loaded if you know what you look for.
|
|
23
|
+
3. Snapshot: `take_snapshot` to understand page structure
|
|
24
|
+
4. Interact: Use element `uid`s from snapshot for `click`, `fill`, etc.
|
|
25
|
+
|
|
26
|
+
### Efficient data retrieval
|
|
27
|
+
|
|
28
|
+
- Use `filePath` parameter for large outputs (screenshots, snapshots, traces)
|
|
29
|
+
- Use pagination (`pageIdx`, `pageSize`) and filtering (`types`) to minimize data
|
|
30
|
+
- Set `includeSnapshot: false` on input actions unless you need updated page state
|
|
31
|
+
|
|
32
|
+
### Tool selection
|
|
33
|
+
|
|
34
|
+
- **Automation/interaction**: `take_snapshot` (text-based, faster, better for automation)
|
|
35
|
+
- **Visual inspection**: `take_screenshot` (when user needs to see visual state)
|
|
36
|
+
- **Additional details**: `evaluate_script` for data not in accessibility tree
|
|
37
|
+
|
|
38
|
+
### Parallel execution
|
|
39
|
+
|
|
40
|
+
You can send multiple tool calls in parallel, but maintain correct order: navigate → wait → snapshot → interact.
|
|
41
|
+
|
|
42
|
+
### Testing an extension
|
|
43
|
+
|
|
44
|
+
> **Before proceeding**: Extension tools (`install_extension`, `list_extensions`, etc.) are only available when the MCP server is started with the `--categoryExtensions` flag. If these tools are not in your tool list, stop and ask the user to update their MCP server configuration:
|
|
45
|
+
>
|
|
46
|
+
> ```json
|
|
47
|
+
> {
|
|
48
|
+
> "mcpServers": {
|
|
49
|
+
> "chrome-devtools": {
|
|
50
|
+
> "command": "npx",
|
|
51
|
+
> "args": ["chrome-devtools-mcp@latest", "--categoryExtensions"]
|
|
52
|
+
> }
|
|
53
|
+
> }
|
|
54
|
+
> }
|
|
55
|
+
> ```
|
|
56
|
+
>
|
|
57
|
+
> After updating, the user must restart the MCP server (or their AI client) for the change to take effect.
|
|
58
|
+
|
|
59
|
+
1. **Install**: Use `install_extension` with the path to the unpacked extension.
|
|
60
|
+
2. **Identify**: Get the extension ID from the response or by calling `list_extensions`.
|
|
61
|
+
3. **Trigger Action**: Use `trigger_extension_action` to open the popup or side panel if applicable.
|
|
62
|
+
4. **Verify Service Worker**: Use `evaluate_script` with `serviceWorkerId` to check extension state or trigger background actions.
|
|
63
|
+
5. **Verify Page Behavior**: Navigate to a page where the extension operates and use `take_snapshot` to check if content scripts injected elements or modified the page correctly.
|
|
64
|
+
|
|
65
|
+
## Troubleshooting
|
|
66
|
+
|
|
67
|
+
If `chrome-devtools-mcp` is insufficient, guide users to use Chrome DevTools UI:
|
|
68
|
+
|
|
69
|
+
- https://developer.chrome.com/docs/devtools
|
|
70
|
+
- https://developer.chrome.com/docs/devtools/ai-assistance
|
|
71
|
+
|
|
72
|
+
If there are errors launching `chrome-devtools-mcp` or Chrome, refer to https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/troubleshooting.md.
|
|
@@ -0,0 +1,153 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: chrome-devtools-cli
|
|
3
|
+
description: Use this skill to write shell scripts or run shell commands to automate tasks in the browser or otherwise use Chrome DevTools via CLI.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
The `chrome-devtools-mcp` CLI lets you interact with the browser from your terminal.
|
|
7
|
+
|
|
8
|
+
## Setup
|
|
9
|
+
|
|
10
|
+
_Note: If this is your very first time using the CLI, see [references/installation.md](references/installation.md) for setup. Installation is a one-time prerequisite and is **not** part of the regular AI workflow._
|
|
11
|
+
|
|
12
|
+
## AI Workflow
|
|
13
|
+
|
|
14
|
+
1. **Execute**: Run tools directly (e.g., `chrome-devtools list_pages`). The background server starts implicitly; **do not** run `start`/`status`/`stop` before each use.
|
|
15
|
+
2. **Inspect**: Use `take_snapshot` to get an element `<uid>`.
|
|
16
|
+
3. **Act**: Use `click`, `fill`, etc. State persists across commands.
|
|
17
|
+
|
|
18
|
+
Snapshot example:
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
uid=1_0 RootWebArea "Example Domain" url="https://example.com/"
|
|
22
|
+
uid=1_1 heading "Example Domain" level="1"
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
## Command Usage
|
|
26
|
+
|
|
27
|
+
```sh
|
|
28
|
+
chrome-devtools <tool> [arguments] [flags]
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
Use `--help` on any command. Output defaults to Markdown, use `--output-format=json` for JSON.
|
|
32
|
+
|
|
33
|
+
## Input Automation (<uid> from snapshot)
|
|
34
|
+
|
|
35
|
+
```bash
|
|
36
|
+
chrome-devtools take_snapshot --help # Help message for commands, works for any command.
|
|
37
|
+
chrome-devtools take_snapshot # Take a text snapshot of the page to get UIDs for elements
|
|
38
|
+
chrome-devtools click "id" # Clicks on the provided element
|
|
39
|
+
chrome-devtools click "id" --dblClick true --includeSnapshot true # Double clicks and returns a snapshot
|
|
40
|
+
chrome-devtools drag "src" "dst" # Drag an element onto another element
|
|
41
|
+
chrome-devtools drag "src" "dst" --includeSnapshot true # Drag an element and return a snapshot
|
|
42
|
+
chrome-devtools fill "id" "text" # Type text into an input or select an option
|
|
43
|
+
chrome-devtools fill "id" "text" --includeSnapshot true # Fill an element and return a snapshot
|
|
44
|
+
chrome-devtools handle_dialog accept # Handle a browser dialog
|
|
45
|
+
chrome-devtools handle_dialog dismiss --promptText "hi" # Dismiss a dialog with prompt text
|
|
46
|
+
chrome-devtools hover "id" # Hover over the provided element
|
|
47
|
+
chrome-devtools hover "id" --includeSnapshot true # Hover over an element and return a snapshot
|
|
48
|
+
chrome-devtools press_key "Enter" # Press a key or key combination
|
|
49
|
+
chrome-devtools press_key "Control+A" --includeSnapshot true # Press a key and return a snapshot
|
|
50
|
+
chrome-devtools type_text "hello" # Type text using keyboard into a focused input
|
|
51
|
+
chrome-devtools type_text "hello" --submitKey "Enter" # Type text and press a submit key
|
|
52
|
+
chrome-devtools upload_file "id" "file.txt" # Upload a file through a provided element
|
|
53
|
+
chrome-devtools upload_file "id" "file.txt" --includeSnapshot true # Upload a file and return a snapshot
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## Navigation
|
|
57
|
+
|
|
58
|
+
```bash
|
|
59
|
+
chrome-devtools close_page 1 # Closes the page by its index
|
|
60
|
+
chrome-devtools list_pages # Get a list of pages open in the browser
|
|
61
|
+
chrome-devtools navigate_page --url "https://example.com" # Navigates the currently selected page to a URL
|
|
62
|
+
chrome-devtools navigate_page --type "reload" --ignoreCache true # Reload page ignoring cache
|
|
63
|
+
chrome-devtools navigate_page --url "https://example.com" --timeout 5000 # Navigate with a timeout
|
|
64
|
+
chrome-devtools navigate_page --handleBeforeUnload "accept" # Handle before unload dialog
|
|
65
|
+
chrome-devtools navigate_page --type "back" --initScript "foo()" # Navigate back and run an init script
|
|
66
|
+
chrome-devtools new_page "https://example.com" # Creates a new page
|
|
67
|
+
chrome-devtools new_page "https://example.com" --background true --timeout 5000 # Create new page in background
|
|
68
|
+
chrome-devtools new_page "https://example.com" --isolatedContext "ctx" # Create new page with isolated context
|
|
69
|
+
chrome-devtools select_page 1 # Select a page as a context for future tool calls
|
|
70
|
+
chrome-devtools select_page 1 --bringToFront true # Select a page and bring it to front
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
## Emulation
|
|
74
|
+
|
|
75
|
+
```bash
|
|
76
|
+
chrome-devtools emulate --networkConditions "Offline" # Emulate network conditions
|
|
77
|
+
chrome-devtools emulate --cpuThrottlingRate 4 --geolocation "0x0" # Emulate CPU throttling and geolocation
|
|
78
|
+
chrome-devtools emulate --colorScheme "dark" --viewport "1920x1080" # Emulate color scheme and viewport
|
|
79
|
+
chrome-devtools emulate --userAgent "Mozilla/5.0..." # Emulate user agent
|
|
80
|
+
chrome-devtools resize_page 1920 1080 # Resizes the selected page's window
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## Performance
|
|
84
|
+
|
|
85
|
+
```bash
|
|
86
|
+
chrome-devtools performance_analyze_insight "1" "LCPBreakdown" # Get more details on a specific Performance Insight
|
|
87
|
+
chrome-devtools performance_start_trace true false # Starts a performance trace recording
|
|
88
|
+
chrome-devtools performance_start_trace true true --filePath t.gz # Start trace and save to a file
|
|
89
|
+
chrome-devtools performance_stop_trace # Stops the active performance trace
|
|
90
|
+
chrome-devtools performance_stop_trace --filePath "t.json" # Stop trace and save to a file
|
|
91
|
+
chrome-devtools take_memory_snapshot "./snap.heapsnapshot" # Capture a memory heapsnapshot
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
## Network
|
|
95
|
+
|
|
96
|
+
```bash
|
|
97
|
+
chrome-devtools get_network_request # Get the currently selected network request
|
|
98
|
+
chrome-devtools get_network_request --reqid 1 --requestFilePath req.md # Get request by id and save to file
|
|
99
|
+
chrome-devtools get_network_request --responseFilePath res.md # Save response body to file
|
|
100
|
+
chrome-devtools list_network_requests # List all network requests
|
|
101
|
+
chrome-devtools list_network_requests --pageSize 50 --pageIdx 0 # List network requests with pagination
|
|
102
|
+
chrome-devtools list_network_requests --resourceTypes Fetch # Filter requests by resource type
|
|
103
|
+
chrome-devtools list_network_requests --includePreservedRequests true # Include preserved requests
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
## Debugging & Inspection
|
|
107
|
+
|
|
108
|
+
```bash
|
|
109
|
+
chrome-devtools evaluate_script "() => document.title" # Evaluate a JavaScript function on the page
|
|
110
|
+
chrome-devtools evaluate_script "(a) => a.innerText" --args 1_4 # Evaluate JS with UID arguments
|
|
111
|
+
chrome-devtools get_console_message 1 # Gets a console message by its ID
|
|
112
|
+
chrome-devtools lighthouse_audit --mode "navigation" # Run Lighthouse audit for navigation
|
|
113
|
+
chrome-devtools lighthouse_audit --mode "snapshot" --device "mobile" # Run Lighthouse audit for a snapshot on mobile
|
|
114
|
+
chrome-devtools lighthouse_audit --outputDirPath ./out # Run Lighthouse audit and save reports
|
|
115
|
+
chrome-devtools list_console_messages # List all console messages
|
|
116
|
+
chrome-devtools list_console_messages --pageSize 20 --pageIdx 1 # List console messages with pagination
|
|
117
|
+
chrome-devtools list_console_messages --types error --types info # Filter console messages by type
|
|
118
|
+
chrome-devtools list_console_messages --includePreservedMessages true # Include preserved messages
|
|
119
|
+
chrome-devtools take_screenshot # Take a screenshot of the page viewport
|
|
120
|
+
chrome-devtools take_screenshot --fullPage true --format "jpeg" --quality 80 # Take a full page screenshot as JPEG with quality
|
|
121
|
+
chrome-devtools take_screenshot --uid "id" --filePath "s.png" # Take a screenshot of an element
|
|
122
|
+
chrome-devtools take_snapshot # Take a text snapshot of the page from the a11y tree
|
|
123
|
+
chrome-devtools take_snapshot --verbose true --filePath "s.txt" # Take a verbose snapshot and save to file
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
## Extensions
|
|
127
|
+
|
|
128
|
+
```bash
|
|
129
|
+
chrome-devtools list_extensions # Lists all the Chrome extensions installed in the browser
|
|
130
|
+
chrome-devtools install_extension "/path/to/extension" # Installs a Chrome extension from the given path
|
|
131
|
+
chrome-devtools uninstall_extension "extension_id" # Uninstalls a Chrome extension by its ID
|
|
132
|
+
chrome-devtools reload_extension "extension_id" # Reloads an unpacked Chrome extension by its ID
|
|
133
|
+
chrome-devtools trigger_extension_action "extension_id" # Triggers the default action of an extension by its ID
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
## Experimental Features
|
|
137
|
+
|
|
138
|
+
Experimental tools are disabled by default. Enable them with the corresponding flag during `start`.
|
|
139
|
+
|
|
140
|
+
```bash
|
|
141
|
+
chrome-devtools click_at 100 200 # Clicks at the provided coordinates (requires --experimentalVision=true)
|
|
142
|
+
chrome-devtools screencast_start # Starts a screencast recording (requires --experimentalScreencast=true and ffmpeg)
|
|
143
|
+
chrome-devtools screencast_stop # Stops the active screencast
|
|
144
|
+
chrome-devtools list_webmcp_tools # List all WebMCP tools (requires --categoryExperimentalWebmcp=true)
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
## Service Management
|
|
148
|
+
|
|
149
|
+
```bash
|
|
150
|
+
chrome-devtools start # Start or restart chrome-devtools-mcp
|
|
151
|
+
chrome-devtools status # Checks if chrome-devtools-mcp is running
|
|
152
|
+
chrome-devtools stop # Stop chrome-devtools-mcp if any
|
|
153
|
+
```
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
# Installation
|
|
2
|
+
|
|
3
|
+
Install the package globally to make the `chrome-devtools` command available. You only need to do this the first time you use it.
|
|
4
|
+
|
|
5
|
+
```sh
|
|
6
|
+
npm i chrome-devtools-mcp@latest -g
|
|
7
|
+
chrome-devtools status # check if install worked.
|
|
8
|
+
```
|
|
9
|
+
|
|
10
|
+
## Troubleshooting
|
|
11
|
+
|
|
12
|
+
- **Command not found:** If `chrome-devtools` is not recognized, ensure your global npm `bin` directory is in your system's `PATH`. Restart your terminal or source your shell configuration file (e.g., `.bashrc`, `.zshrc`).
|
|
13
|
+
- **Permission errors:** If you encounter `EACCES` or permission errors during installation, avoid using `sudo`. Instead, use a node version manager like `nvm`, or configure npm to use a different global directory.
|
|
14
|
+
- **Old version running:** Run `chrome-devtools stop && npm uninstall -g chrome-devtools-mcp` before reinstalling, or ensure the latest version is being picked up by your path.
|
|
@@ -0,0 +1,121 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: debug-optimize-lcp
|
|
3
|
+
description: Guides debugging and optimizing Largest Contentful Paint (LCP) using Chrome DevTools MCP tools. Use this skill whenever the user asks about LCP performance, slow page loads, Core Web Vitals optimization, or wants to understand why their page's main content takes too long to appear. Also use when the user mentions "largest contentful paint", "page load speed", "CWV", or wants to improve how fast their hero image or main content renders.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## What is LCP and why it matters
|
|
7
|
+
|
|
8
|
+
Largest Contentful Paint (LCP) measures how quickly a page's main content becomes visible. It's the time from navigation start until the largest image or text block renders in the viewport.
|
|
9
|
+
|
|
10
|
+
- **Good**: 2.5 seconds or less
|
|
11
|
+
- **Needs improvement**: 2.5–4.0 seconds
|
|
12
|
+
- **Poor**: greater than 4.0 seconds
|
|
13
|
+
|
|
14
|
+
LCP is a Core Web Vital that directly affects user experience and search ranking. On 73% of mobile pages, the LCP element is an image.
|
|
15
|
+
|
|
16
|
+
## LCP Subparts Breakdown
|
|
17
|
+
|
|
18
|
+
Every page's LCP breaks down into four sequential subparts with no gaps or overlaps. Understanding which subpart is the bottleneck is the key to effective optimization.
|
|
19
|
+
|
|
20
|
+
| Subpart | Ideal % of LCP | What it measures |
|
|
21
|
+
| ----------------------------- | -------------- | ---------------------------------------------- |
|
|
22
|
+
| **Time to First Byte (TTFB)** | ~40% | Navigation start → first byte of HTML received |
|
|
23
|
+
| **Resource load delay** | <10% | TTFB → browser starts loading the LCP resource |
|
|
24
|
+
| **Resource load duration** | ~40% | Time to download the LCP resource |
|
|
25
|
+
| **Element render delay** | <10% | LCP resource downloaded → LCP element rendered |
|
|
26
|
+
|
|
27
|
+
The "delay" subparts should be as close to zero as possible. If either delay subpart is large relative to the total LCP, that's the first place to optimize.
|
|
28
|
+
|
|
29
|
+
**Common Pitfall**: Optimizing one subpart (like compressing an image to reduce load duration) without checking others. If render delay is the real bottleneck, a smaller image won't help — the saved time just shifts to render delay.
|
|
30
|
+
|
|
31
|
+
## Debugging Workflow
|
|
32
|
+
|
|
33
|
+
Follow these steps in order. Each step builds on the previous one.
|
|
34
|
+
|
|
35
|
+
### Step 1: Record a Performance Trace
|
|
36
|
+
|
|
37
|
+
Navigate to the page, then record a trace with reload to capture the full page load including LCP:
|
|
38
|
+
|
|
39
|
+
1. `navigate_page` to the target URL.
|
|
40
|
+
2. `performance_start_trace` with `reload: true` and `autoStop: true`.
|
|
41
|
+
|
|
42
|
+
The trace results will include LCP timing and available insight sets. Note the insight set IDs from the output — you'll need them in the next step.
|
|
43
|
+
|
|
44
|
+
### Step 2: Analyze LCP Insights
|
|
45
|
+
|
|
46
|
+
Use `performance_analyze_insight` to drill into LCP-specific insights. Look for these insight names in the trace results:
|
|
47
|
+
|
|
48
|
+
- **LCPBreakdown** — Shows the four LCP subparts with timing for each.
|
|
49
|
+
- **DocumentLatency** — Server response time issues affecting TTFB.
|
|
50
|
+
- **RenderBlocking** — Resources blocking the LCP element from rendering.
|
|
51
|
+
- **LCPDiscovery** — Whether the LCP resource was discoverable early.
|
|
52
|
+
|
|
53
|
+
Call `performance_analyze_insight` with the insight set ID and the insight name from the trace results.
|
|
54
|
+
|
|
55
|
+
### Step 3: Identify the LCP Element
|
|
56
|
+
|
|
57
|
+
Use `evaluate_script` with the **"Identify LCP Element" snippet** found in [references/lcp-snippets.md](references/lcp-snippets.md) to reveal the LCP element's tag, resource URL, and raw timing data.
|
|
58
|
+
|
|
59
|
+
The `url` field tells you what resource to look for in the network waterfall. If `url` is empty, the LCP element is text-based (no resource to load).
|
|
60
|
+
|
|
61
|
+
### Step 4: Check the Network Waterfall
|
|
62
|
+
|
|
63
|
+
Use `list_network_requests` to see when the LCP resource loaded relative to other resources:
|
|
64
|
+
|
|
65
|
+
- Call `list_network_requests` filtered by `resourceTypes: ["Image", "Font"]` (adjust based on Step 3).
|
|
66
|
+
- Then use `get_network_request` with the LCP resource's request ID for full details.
|
|
67
|
+
|
|
68
|
+
**Key Checks:**
|
|
69
|
+
|
|
70
|
+
- **Start Time**: Compare against the HTML document and the first resource. If the LCP resource starts much later than the first resource, there's resource load delay to eliminate.
|
|
71
|
+
- **Duration**: A large resource load duration suggests the file is too big or the server is slow.
|
|
72
|
+
|
|
73
|
+
### Step 5: Inspect HTML for Common Issues
|
|
74
|
+
|
|
75
|
+
Use `evaluate_script` with the **"Audit Common Issues" snippet** found in [references/lcp-snippets.md](references/lcp-snippets.md) to check for lazy-loaded images in the viewport, missing fetchpriority, and render-blocking scripts.
|
|
76
|
+
|
|
77
|
+
## Optimization Strategies
|
|
78
|
+
|
|
79
|
+
After identifying the bottleneck subpart, apply these prioritized fixes.
|
|
80
|
+
|
|
81
|
+
### 1. Eliminate Resource Load Delay (target: <10%)
|
|
82
|
+
|
|
83
|
+
The most common bottleneck. The LCP resource should start loading immediately.
|
|
84
|
+
|
|
85
|
+
- **Root Cause**: LCP image loaded via JS/CSS, `data-src` usage, or `loading="lazy"`.
|
|
86
|
+
- **Fix**: Use standard `<img>` with `src`. **Never** lazy-load the LCP image.
|
|
87
|
+
- **Fix**: Add `<link rel="preload" fetchpriority="high">` if the image isn't discoverable in HTML.
|
|
88
|
+
- **Fix**: Add `fetchpriority="high"` to the LCP `<img>` tag.
|
|
89
|
+
|
|
90
|
+
### 2. Eliminate Element Render Delay (target: <10%)
|
|
91
|
+
|
|
92
|
+
The element should render immediately after loading.
|
|
93
|
+
|
|
94
|
+
- **Root Cause**: Large stylesheets, synchronous scripts in `<head>`, or main thread blocking.
|
|
95
|
+
- **Fix**: Inline critical CSS, defer non-critical CSS/JS.
|
|
96
|
+
- **Fix**: Break up long tasks blocking the main thread.
|
|
97
|
+
- **Fix**: Use Server-Side Rendering (SSR) so the element exists in initial HTML.
|
|
98
|
+
|
|
99
|
+
### 3. Reduce Resource Load Duration (target: ~40%)
|
|
100
|
+
|
|
101
|
+
Make the resource smaller or faster to deliver.
|
|
102
|
+
|
|
103
|
+
- **Fix**: Use modern formats (WebP, AVIF) and responsive images (`srcset`).
|
|
104
|
+
- **Fix**: Serve from a CDN.
|
|
105
|
+
- **Fix**: Set `Cache-Control` headers.
|
|
106
|
+
- **Fix**: Use `font-display: swap` if LCP is text blocked by a web font.
|
|
107
|
+
|
|
108
|
+
### 4. Reduce TTFB (target: ~40%)
|
|
109
|
+
|
|
110
|
+
The HTML document itself takes too long to arrive.
|
|
111
|
+
|
|
112
|
+
- **Fix**: Minimize redirects and optimize server response time.
|
|
113
|
+
- **Fix**: Cache HTML at the edge (CDN).
|
|
114
|
+
- **Fix**: Ensure pages are eligible for back/forward cache (bfcache).
|
|
115
|
+
|
|
116
|
+
## Verifying Fixes & Emulation
|
|
117
|
+
|
|
118
|
+
- **Verification**: Re-run the trace (`performance_start_trace` with `reload: true`) and compare the new subpart breakdown. The bottleneck should shrink.
|
|
119
|
+
- **Emulation**: Lab measurements differ from real-world experience. Use `emulate` to test under constraints:
|
|
120
|
+
- `emulate` with `networkConditions: "Fast 3G"` and `cpuThrottlingRate: 4`.
|
|
121
|
+
- This surfaces issues visible only on slower connections/devices.
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# Elements and Size for LCP
|
|
2
|
+
|
|
3
|
+
## What Elements are Considered?
|
|
4
|
+
|
|
5
|
+
The types of elements considered for Largest Contentful Paint (LCP) are:
|
|
6
|
+
|
|
7
|
+
- **`<img>` elements**: The first frame presentation time is used for animated content like GIFs.
|
|
8
|
+
- **`<image>` elements** inside an `<svg>` element.
|
|
9
|
+
- **`<video>` elements**: The poster image load time or first frame presentation time, whichever is earlier.
|
|
10
|
+
- **Background images**: Elements with a background image loaded using `url()`.
|
|
11
|
+
- **Block-level elements**: Containing text nodes or other inline-level text element children.
|
|
12
|
+
|
|
13
|
+
## Heuristics to Exclude Non-Contentful Elements
|
|
14
|
+
|
|
15
|
+
Chromium-based browsers use heuristics to exclude:
|
|
16
|
+
|
|
17
|
+
- Elements with **opacity of 0**.
|
|
18
|
+
- Elements that **cover the full viewport** (likely background).
|
|
19
|
+
- **Placeholder images** or low-entropy images.
|
|
20
|
+
|
|
21
|
+
## How is an Element's Size Determined?
|
|
22
|
+
|
|
23
|
+
- **Visible Area**: Typically the size visible within the viewport. Extending outside, clipped, or overflow portions don't count.
|
|
24
|
+
- **Image Elements**: Either the visible size or the intrinsic size, whichever is smaller.
|
|
25
|
+
- **Text Elements**: The smallest rectangle containing all text nodes.
|
|
26
|
+
- **Exclusions**: Margin, padding, and borders are not considered toward the size.
|
|
27
|
+
- **Containment**: Every text node belongs to its closest block-level ancestor element.
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Largest Contentful Paint (LCP) Breakdown
|
|
2
|
+
|
|
3
|
+
LCP measures the time from when the user initiates loading the page until the largest image or text block is rendered within the viewport. To provide a good user experience, sites should strive to have an LCP of 2.5 seconds or less for at least 75% of page visits.
|
|
4
|
+
|
|
5
|
+
## The Four Subparts of LCP
|
|
6
|
+
|
|
7
|
+
Every page's LCP consists of these four subcategories. There's no gap or overlap between them, and they add up to the full LCP time.
|
|
8
|
+
|
|
9
|
+
| LCP subpart | % of LCP (Optimal) | Description |
|
|
10
|
+
| ----------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
|
11
|
+
| **Time to First Byte (TTFB)** | ~40% | The time from when the user initiates loading the page until the browser receives the first byte of the HTML document response. |
|
|
12
|
+
| **Resource load delay** | <10% | The time between TTFB and when the browser starts loading the LCP resource. If the LCP element doesn't require a resource load (e.g., system font text), this time is 0. |
|
|
13
|
+
| **Resource load duration** | ~40% | The duration of time it takes to load the LCP resource itself. If the LCP element doesn't require a resource load, this time is 0. |
|
|
14
|
+
| **Element render delay** | <10% | The time between when the LCP resource finishes loading and the LCP element rendering fully. |
|
|
15
|
+
|
|
16
|
+
## Why the Breakdown Matters
|
|
17
|
+
|
|
18
|
+
Optimizing for LCP requires identifying which of these subparts is the bottleneck:
|
|
19
|
+
|
|
20
|
+
- **Large delta between TTFB and FCP**: Indicates the browser needs to download a lot of render-blocking assets or complete a lot of work (e.g., client-side rendering).
|
|
21
|
+
- **Large delta between FCP and LCP**: Indicates the LCP resource is not immediately available for the browser to prioritize or the browser is completing other work before it can display the LCP content.
|
|
22
|
+
- **Large resource load delay**: Indicates the resource is not discoverable early or is deprioritized.
|
|
23
|
+
- **Large element render delay**: Indicates rendering is blocked by stylesheets, scripts, or long tasks.
|