Performance

Lighthouse and PageSpeed

Runs and reads Lighthouse 13 for performance, accessibility, best practices and SEO - locally, in Chrome DevTools, PageSpeed Insights and CI with Lighthouse CI - and turns the report into fixes without chasing the score. Use when asked to run Lighthouse or PageSpeed, set up performance budgets or a CI gate, explain a score or an insight, or "get the page to green".

fe-lighthouseevery web project6 rules82 tokens always loaded, 820 tokens when used, 1485 tokens in references on demand.

Install

init installs this skill when the project uses every web project. Pick your agent to see where its files land.

npx github:dawidolko/frontend-skills init

Not tested yet with this runner. npx and pnpm dlx are tested; if this one fails, use one of them.

Without --agents, init finds the agents from what the project already has, and asks when it finds none:

How init finds each of the 17 agents

Agent	Found by
Claude Code	`CLAUDE.md` `.claude` `CLAUDE.local.md`
OpenAI Codex	`.codex` `AGENTS.override.md`
Cursor	`.cursor` `.cursorrules`
GitHub Copilot	`.github/copilot-instructions.md` `.github/instructions` `.github/skills` `.github/prompts`
Gemini CLI	`GEMINI.md` `.gemini`
Antigravity CLI	`.agents/rules` `.agent/rules`
Devin / Windsurf	`.devin` `.windsurf` `.windsurfrules`
OpenCode	`opencode.json` `opencode.jsonc` `.opencode`
Cline	`.clinerules` `.cline`
Zed	`.rules` `.zed`
JetBrains Junie	`.junie`
Kiro	`.kiro`
Augment	`.augment` `.augment-guidelines`
Trae	`.trae`
Continue	`.continue`
Amazon Q Developer	`.amazonq`
Aider	`.aider.conf.yml` `CONVENTIONS.md`

Where fe-lighthouse lands for Claude Code

.claude/skills/fe-lighthouse/SKILL.mdskill
.claude/skills/fe-lighthouse/references/lighthouse.mdskill
.claude/rules/fe-lighthouse.mdrule file
CLAUDE.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.claude/rules/fe-lighthouse.md

---
paths:
  - "**/lighthouserc*"
  - "**/.lighthouserc*"
  - "**/*.html"
---

# Lighthouse and PageSpeed (frontend-skills)

Runs and reads Lighthouse 13 for performance, accessibility, best practices and SEO - locally, in Chrome DevTools, PageSpeed Insights and CI with Lighthouse CI - and turns the report into fixes without chasing the score. Use when asked to run Lighthouse or PageSpeed, set up performance budgets or a CI gate, explain a score or an insight, or "get the page to green".

- The performance score weights TBT 30, LCP 25, CLS 25, FCP 10, Speed Index 10; fix the heaviest failing metric first.
- Run the mobile preset (the default) and `--preset=desktop` separately; report which one.
- Run at least three times and use the median; never gate CI on one run or on 100 (perf/lighthouse-ci).
- A lab score is not a Core Web Vitals result; vitals come from field data at p75 (perf/field-data-p75).
- Lighthouse 13 shows insights (LCP discovery, layout shift culprits, render blocking, third parties) instead of the old opportunities; read them for causes (perf/lcp-image, perf/layout-shift, perf/code-split).
- Accessibility 100 means no automated audit failed, not that the page is accessible; do the manual checks.
- Keep the console free of errors and deprecated APIs (tooling/console-clean).
- Test production builds on a quiet machine in a clean profile (no extensions), not the dev server.
- Never optimise for the score by hiding content from Lighthouse or detecting its user agent.

Before larger changes, read the full skill: `.claude/skills/fe-lighthouse/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-lighthouse lands for OpenAI Codex

.agents/skills/fe-lighthouse/SKILL.mdskill
.agents/skills/fe-lighthouse/references/lighthouse.mdskill
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

OpenAI Codex has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

AGENTS.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-lighthouse lands for Cursor

.agents/skills/fe-lighthouse/SKILL.mdskill
.agents/skills/fe-lighthouse/references/lighthouse.mdskill
.cursor/rules/fe-lighthouse.mdcrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.cursor/rules/fe-lighthouse.mdc

---
description: Runs and reads Lighthouse 13 for performance, accessibility, best practices and SEO - locally, in Chrome DevTools, PageSpeed Insights and CI with Lighthouse CI - and turns the report into fixes without chasing the score. Use when asked to run Lighthouse or PageSpeed, set up performance budgets or a CI gate, explain a score or an insight, or "get the page to green".
globs: **/lighthouserc*, **/.lighthouserc*, **/*.html
alwaysApply: false
---

# Lighthouse and PageSpeed (frontend-skills)

- The performance score weights TBT 30, LCP 25, CLS 25, FCP 10, Speed Index 10; fix the heaviest failing metric first.
- Run the mobile preset (the default) and `--preset=desktop` separately; report which one.
- Run at least three times and use the median; never gate CI on one run or on 100 (perf/lighthouse-ci).
- A lab score is not a Core Web Vitals result; vitals come from field data at p75 (perf/field-data-p75).
- Lighthouse 13 shows insights (LCP discovery, layout shift culprits, render blocking, third parties) instead of the old opportunities; read them for causes (perf/lcp-image, perf/layout-shift, perf/code-split).
- Accessibility 100 means no automated audit failed, not that the page is accessible; do the manual checks.
- Keep the console free of errors and deprecated APIs (tooling/console-clean).
- Test production builds on a quiet machine in a clean profile (no extensions), not the dev server.
- Never optimise for the score by hiding content from Lighthouse or detecting its user agent.

Before larger changes, read the full skill: `.agents/skills/fe-lighthouse/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-lighthouse lands for GitHub Copilot

.agents/skills/fe-lighthouse/SKILL.mdskill
.agents/skills/fe-lighthouse/references/lighthouse.mdskill
.github/instructions/fe-lighthouse.instructions.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.github/instructions/fe-lighthouse.instructions.md

---
applyTo: "**/lighthouserc*,**/.lighthouserc*,**/*.html"
description: "Runs and reads Lighthouse 13 for performance, accessibility, best practices and SEO - locally, in Chrome DevTools, PageSpeed Insights and CI with Lighthouse CI - and turns the report into fixes without chasing the score. Use when asked to run Lighthouse or PageSpeed, set up performance budgets or a CI gate, explain a score or an insight, or \"get the page to green\"."
---

# Lighthouse and PageSpeed (frontend-skills)

- The performance score weights TBT 30, LCP 25, CLS 25, FCP 10, Speed Index 10; fix the heaviest failing metric first.
- Run the mobile preset (the default) and `--preset=desktop` separately; report which one.
- Run at least three times and use the median; never gate CI on one run or on 100 (perf/lighthouse-ci).
- A lab score is not a Core Web Vitals result; vitals come from field data at p75 (perf/field-data-p75).
- Lighthouse 13 shows insights (LCP discovery, layout shift culprits, render blocking, third parties) instead of the old opportunities; read them for causes (perf/lcp-image, perf/layout-shift, perf/code-split).
- Accessibility 100 means no automated audit failed, not that the page is accessible; do the manual checks.
- Keep the console free of errors and deprecated APIs (tooling/console-clean).
- Test production builds on a quiet machine in a clean profile (no extensions), not the dev server.
- Never optimise for the score by hiding content from Lighthouse or detecting its user agent.

Before larger changes, read the full skill: `.agents/skills/fe-lighthouse/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-lighthouse lands for Gemini CLI

.agents/skills/fe-lighthouse/SKILL.mdskill
.agents/skills/fe-lighthouse/references/lighthouse.mdskill
GEMINI.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Gemini CLI: Gemini CLI was replaced by Antigravity CLI for unpaid tiers on 2026-06-18; choose "antigravity" too if you use it.

Gemini CLI has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

GEMINI.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-lighthouse lands for Antigravity CLI

.agents/skills/fe-lighthouse/SKILL.mdskill
.agents/skills/fe-lighthouse/references/lighthouse.mdskill
.agents/rules/fe-lighthouse.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.agents/rules/fe-lighthouse.md

---
trigger: glob
globs: "**/lighthouserc*, **/.lighthouserc*, **/*.html"
description: "Runs and reads Lighthouse 13 for performance, accessibility, best practices and SEO - locally, in Chrome DevTools, PageSpeed Insights and CI with Lighthouse CI - and turns the report into fixes without chasing the score. Use when asked to run Lighthouse or PageSpeed, set up performance budgets or a CI gate, explain a score or an insight, or \"get the page to green\"."
---

# Lighthouse and PageSpeed (frontend-skills)

- The performance score weights TBT 30, LCP 25, CLS 25, FCP 10, Speed Index 10; fix the heaviest failing metric first.
- Run the mobile preset (the default) and `--preset=desktop` separately; report which one.
- Run at least three times and use the median; never gate CI on one run or on 100 (perf/lighthouse-ci).
- A lab score is not a Core Web Vitals result; vitals come from field data at p75 (perf/field-data-p75).
- Lighthouse 13 shows insights (LCP discovery, layout shift culprits, render blocking, third parties) instead of the old opportunities; read them for causes (perf/lcp-image, perf/layout-shift, perf/code-split).
- Accessibility 100 means no automated audit failed, not that the page is accessible; do the manual checks.
- Keep the console free of errors and deprecated APIs (tooling/console-clean).
- Test production builds on a quiet machine in a clean profile (no extensions), not the dev server.
- Never optimise for the score by hiding content from Lighthouse or detecting its user agent.

Before larger changes, read the full skill: `.agents/skills/fe-lighthouse/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-lighthouse lands for Devin / Windsurf

.agents/skills/fe-lighthouse/SKILL.mdskill
.agents/skills/fe-lighthouse/references/lighthouse.mdskill
.devin/rules/fe-lighthouse.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Devin / Windsurf: Devin CLI also reads .cursor/rules; with Cursor chosen too, the CLI sees both rule files of a skill.

Planned by the installer itself for the example React project in the repository.

.devin/rules/fe-lighthouse.md

---
trigger: glob
globs: "**/lighthouserc*,**/.lighthouserc*,**/*.html"
---

# Lighthouse and PageSpeed (frontend-skills)

Runs and reads Lighthouse 13 for performance, accessibility, best practices and SEO - locally, in Chrome DevTools, PageSpeed Insights and CI with Lighthouse CI - and turns the report into fixes without chasing the score. Use when asked to run Lighthouse or PageSpeed, set up performance budgets or a CI gate, explain a score or an insight, or "get the page to green".

- The performance score weights TBT 30, LCP 25, CLS 25, FCP 10, Speed Index 10; fix the heaviest failing metric first.
- Run the mobile preset (the default) and `--preset=desktop` separately; report which one.
- Run at least three times and use the median; never gate CI on one run or on 100 (perf/lighthouse-ci).
- A lab score is not a Core Web Vitals result; vitals come from field data at p75 (perf/field-data-p75).
- Lighthouse 13 shows insights (LCP discovery, layout shift culprits, render blocking, third parties) instead of the old opportunities; read them for causes (perf/lcp-image, perf/layout-shift, perf/code-split).
- Accessibility 100 means no automated audit failed, not that the page is accessible; do the manual checks.
- Keep the console free of errors and deprecated APIs (tooling/console-clean).
- Test production builds on a quiet machine in a clean profile (no extensions), not the dev server.
- Never optimise for the score by hiding content from Lighthouse or detecting its user agent.

Before larger changes, read the full skill: `.agents/skills/fe-lighthouse/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-lighthouse lands for OpenCode

.agents/skills/fe-lighthouse/SKILL.mdskill
.agents/skills/fe-lighthouse/references/lighthouse.mdskill
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

OpenCode has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

AGENTS.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-lighthouse lands for Cline

.claude/skills/fe-lighthouse/SKILL.mdskill
.claude/skills/fe-lighthouse/references/lighthouse.mdskill
.clinerules/fe-lighthouse.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Cline: If .clinerules is a single file rather than a folder, Cline rule files are not written; skills still are.

Planned by the installer itself for the example React project in the repository.

.clinerules/fe-lighthouse.md

---
paths:
  - "**/lighthouserc*"
  - "**/.lighthouserc*"
  - "**/*.html"
---

# Lighthouse and PageSpeed (frontend-skills)

Runs and reads Lighthouse 13 for performance, accessibility, best practices and SEO - locally, in Chrome DevTools, PageSpeed Insights and CI with Lighthouse CI - and turns the report into fixes without chasing the score. Use when asked to run Lighthouse or PageSpeed, set up performance budgets or a CI gate, explain a score or an insight, or "get the page to green".

- The performance score weights TBT 30, LCP 25, CLS 25, FCP 10, Speed Index 10; fix the heaviest failing metric first.
- Run the mobile preset (the default) and `--preset=desktop` separately; report which one.
- Run at least three times and use the median; never gate CI on one run or on 100 (perf/lighthouse-ci).
- A lab score is not a Core Web Vitals result; vitals come from field data at p75 (perf/field-data-p75).
- Lighthouse 13 shows insights (LCP discovery, layout shift culprits, render blocking, third parties) instead of the old opportunities; read them for causes (perf/lcp-image, perf/layout-shift, perf/code-split).
- Accessibility 100 means no automated audit failed, not that the page is accessible; do the manual checks.
- Keep the console free of errors and deprecated APIs (tooling/console-clean).
- Test production builds on a quiet machine in a clean profile (no extensions), not the dev server.
- Never optimise for the score by hiding content from Lighthouse or detecting its user agent.

Before larger changes, read the full skill: `.claude/skills/fe-lighthouse/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-lighthouse lands for Zed

.agents/skills/fe-lighthouse/SKILL.mdskill
.agents/skills/fe-lighthouse/references/lighthouse.mdskill
CLAUDE.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Zed: Zed reads only the first instruction file of its list; the block is placed in that file.

Zed has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

CLAUDE.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-lighthouse lands for JetBrains Junie

.agents/skills/fe-lighthouse/SKILL.mdskill
.agents/skills/fe-lighthouse/references/lighthouse.mdskill
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

JetBrains Junie: Junie reads .agents/skills only in a trusted project.

JetBrains Junie has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

AGENTS.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-lighthouse lands for Kiro

.kiro/skills/fe-lighthouse/SKILL.mdskill
.kiro/skills/fe-lighthouse/references/lighthouse.mdskill
.kiro/steering/fe-lighthouse.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.kiro/steering/fe-lighthouse.md

---
inclusion: fileMatch
fileMatchPattern: ["**/lighthouserc*", "**/.lighthouserc*", "**/*.html"]
---

# Lighthouse and PageSpeed (frontend-skills)

Runs and reads Lighthouse 13 for performance, accessibility, best practices and SEO - locally, in Chrome DevTools, PageSpeed Insights and CI with Lighthouse CI - and turns the report into fixes without chasing the score. Use when asked to run Lighthouse or PageSpeed, set up performance budgets or a CI gate, explain a score or an insight, or "get the page to green".

- The performance score weights TBT 30, LCP 25, CLS 25, FCP 10, Speed Index 10; fix the heaviest failing metric first.
- Run the mobile preset (the default) and `--preset=desktop` separately; report which one.
- Run at least three times and use the median; never gate CI on one run or on 100 (perf/lighthouse-ci).
- A lab score is not a Core Web Vitals result; vitals come from field data at p75 (perf/field-data-p75).
- Lighthouse 13 shows insights (LCP discovery, layout shift culprits, render blocking, third parties) instead of the old opportunities; read them for causes (perf/lcp-image, perf/layout-shift, perf/code-split).
- Accessibility 100 means no automated audit failed, not that the page is accessible; do the manual checks.
- Keep the console free of errors and deprecated APIs (tooling/console-clean).
- Test production builds on a quiet machine in a clean profile (no extensions), not the dev server.
- Never optimise for the score by hiding content from Lighthouse or detecting its user agent.

Before larger changes, read the full skill: `.kiro/skills/fe-lighthouse/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-lighthouse lands for Augment

.agents/skills/fe-lighthouse/SKILL.mdskill
.agents/skills/fe-lighthouse/references/lighthouse.mdskill
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Augment has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

AGENTS.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

The real file

Where fe-lighthouse lands for Trae

.trae/skills/fe-lighthouse/SKILL.mdskill
.trae/skills/fe-lighthouse/references/lighthouse.mdskill
.trae/rules/fe-lighthouse.mdrule file
AGENTS.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Trae: Trae reads AGENTS.md only after it is enabled in its settings.

Planned by the installer itself for the example React project in the repository.

.trae/rules/fe-lighthouse.md

---
description: "Runs and reads Lighthouse 13 for performance, accessibility, best practices and SEO - locally, in Chrome DevTools, PageSpeed Insights and CI with Lighthouse CI - and turns the report into fixes without chasing the score. Use when asked to run Lighthouse or PageSpeed, set up performance budgets or a CI gate, explain a score or an insight, or \"get the page to green\"."
globs: **/lighthouserc*,**/.lighthouserc*,**/*.html
alwaysApply: false
---

# Lighthouse and PageSpeed (frontend-skills)

- The performance score weights TBT 30, LCP 25, CLS 25, FCP 10, Speed Index 10; fix the heaviest failing metric first.
- Run the mobile preset (the default) and `--preset=desktop` separately; report which one.
- Run at least three times and use the median; never gate CI on one run or on 100 (perf/lighthouse-ci).
- A lab score is not a Core Web Vitals result; vitals come from field data at p75 (perf/field-data-p75).
- Lighthouse 13 shows insights (LCP discovery, layout shift culprits, render blocking, third parties) instead of the old opportunities; read them for causes (perf/lcp-image, perf/layout-shift, perf/code-split).
- Accessibility 100 means no automated audit failed, not that the page is accessible; do the manual checks.
- Keep the console free of errors and deprecated APIs (tooling/console-clean).
- Test production builds on a quiet machine in a clean profile (no extensions), not the dev server.
- Never optimise for the score by hiding content from Lighthouse or detecting its user agent.

Before larger changes, read the full skill: `.trae/skills/fe-lighthouse/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-lighthouse lands for Continue

.frontend-skills/skills/fe-lighthouse/SKILL.mdskill
.frontend-skills/skills/fe-lighthouse/references/lighthouse.mdskill
.continue/rules/fe-lighthouse.mdrule file

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Planned by the installer itself for the example React project in the repository.

.continue/rules/fe-lighthouse.md

---
name: "Lighthouse and PageSpeed"
description: "Runs and reads Lighthouse 13 for performance, accessibility, best practices and SEO - locally, in Chrome DevTools, PageSpeed Insights and CI with Lighthouse CI - and turns the report into fixes without chasing the score. Use when asked to run Lighthouse or PageSpeed, set up performance budgets or a CI gate, explain a score or an insight, or \"get the page to green\"."
globs: ["**/lighthouserc*", "**/.lighthouserc*", "**/*.html"]
alwaysApply: false
---

# Lighthouse and PageSpeed (frontend-skills)

- The performance score weights TBT 30, LCP 25, CLS 25, FCP 10, Speed Index 10; fix the heaviest failing metric first.
- Run the mobile preset (the default) and `--preset=desktop` separately; report which one.
- Run at least three times and use the median; never gate CI on one run or on 100 (perf/lighthouse-ci).
- A lab score is not a Core Web Vitals result; vitals come from field data at p75 (perf/field-data-p75).
- Lighthouse 13 shows insights (LCP discovery, layout shift culprits, render blocking, third parties) instead of the old opportunities; read them for causes (perf/lcp-image, perf/layout-shift, perf/code-split).
- Accessibility 100 means no automated audit failed, not that the page is accessible; do the manual checks.
- Keep the console free of errors and deprecated APIs (tooling/console-clean).
- Test production builds on a quiet machine in a clean profile (no extensions), not the dev server.
- Never optimise for the score by hiding content from Lighthouse or detecting its user agent.

Before larger changes, read the full skill: `.frontend-skills/skills/fe-lighthouse/SKILL.md`. Explain any rule id with `npx github:dawidolko/frontend-skills explain <id>`.

The real file

Where fe-lighthouse lands for Amazon Q Developer

.frontend-skills/skills/fe-lighthouse/SKILL.mdskill
.frontend-skills/skills/fe-lighthouse/references/lighthouse.mdskill
.amazonq/rules/frontend-skills.mdinstruction block

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Amazon Q Developer: Amazon Q Developer IDE plugins reach end of support on 2027-04-30; AWS points to Kiro.

Amazon Q Developer has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

.amazonq/rules/frontend-skills.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

### Skills

- `fe-lighthouse` (Lighthouse and PageSpeed): when editing `**/lighthouserc*`, `**/.lighthouserc*`, `**/*.html`, first read `.frontend-skills/skills/fe-lighthouse/SKILL.md`.

The real file

Where fe-lighthouse lands for Aider

.frontend-skills/skills/fe-lighthouse/SKILL.mdskill
.frontend-skills/skills/fe-lighthouse/references/lighthouse.mdskill
CONVENTIONS.mdinstruction block
.aider.conf.ymlconfig

For every agent also: .frontend-skills/profile.json, .frontend-skills/lessons.md and .frontend-skills/install.json.

Aider has no rule files scoped to file types; it reads the skills and the instruction block.

Planned by the installer itself for the example React project in the repository.

CONVENTIONS.md

## Front-end work (frontend-skills)

- Before front-end work, read `.frontend-skills/profile.json` (the stack) and `.frontend-skills/lessons.md` (confirmed conventions of this project; they win over any skill).
- Use the installed `fe-*` skill that matches the files you edit.
- After changing UI code, run `npx github:dawidolko/frontend-skills audit --changed --json` and fix findings at `serious` and above; `explain <rule id>` gives the reason, the source and the fix.
- Name rule ids (such as `a11y/img-alt`) in reviews and commit messages.

### Skills

- `fe-lighthouse` (Lighthouse and PageSpeed): when editing `**/lighthouserc*`, `**/.lighthouserc*`, `**/*.html`, first read `.frontend-skills/skills/fe-lighthouse/SKILL.md`.

The real file

How to use it

Once installed, the agent loads the skill by itself when a task matches its description. You can also ask for it in your own words, for example:

Phrases from the skill description that make the agent pick it:

get the page to green

And to check and fix the work:

Use the fe-lighthouse skill on this file.
Run the front-end audit on what I changed and fix everything serious.
Explain perf/lighthouse-ci and fix it here.

Rules it teaches

perf/lighthouse-ci
Lighthouse in CI runs each URL several times, asserts on metrics and categories with realistic thresholds, and never demands a perfect 100.
minormanual
perf/field-data-p75
Claims about Core Web Vitals come from field data at the 75th percentile, not from a Lighthouse score.
minormanual
tooling/console-clean
Pages log no errors and use no deprecated browser APIs, as seen in the console on load and in the main flows.
minorbrowser
perf/lcp-image
The LCP image is in the initial HTML, not lazy, and has fetchpriority="high"; a CSS background LCP image is preloaded.
moderatebrowser
perf/layout-shift
Nothing moves after it appears - space is reserved for images, embeds, ads and late content (CLS 0.1 or less).
moderatebrowser
perf/code-split
JavaScript is split by route, and features that most visits do not use load on demand with dynamic import().
moderatebrowser

The rule digest

This part is copied into each agent's scoped rule file, so it stands on its own:

The performance score weights TBT 30, LCP 25, CLS 25, FCP 10, Speed Index 10; fix the heaviest failing metric first.
Run the mobile preset (the default) and --preset=desktop separately; report which one.
Run at least three times and use the median; never gate CI on one run or on 100 (perf/lighthouse-ci).
A lab score is not a Core Web Vitals result; vitals come from field data at p75 (perf/field-data-p75).
Lighthouse 13 shows insights (LCP discovery, layout shift culprits, render blocking, third parties) instead of the old opportunities; read them for causes (perf/lcp-image, perf/layout-shift, perf/code-split).
Accessibility 100 means no automated audit failed, not that the page is accessible; do the manual checks.
Keep the console free of errors and deprecated APIs (tooling/console-clean).
Test production builds on a quiet machine in a clean profile (no extensions), not the dev server.
Never optimise for the score by hiding content from Lighthouse or detecting its user agent.

Steps the agent follows

Build and serve the production output locally (npm run build then the framework's preview), or use the deployed URL.
Run npx github:dawidolko/frontend-skills audit --url <url>: it runs Lighthouse and axe-core in the local Chrome (after a yes) and maps results to rule ids. Or run npx lighthouse@13.6.0 <url> --output=json --output-path=./lh.json --quiet.
Read in order: metric values, then the insights for the failing metric, then diagnostics. Fix one cause, rebuild, rerun three times.
For CI, add @lhci/cli with a lighthouserc.json: several URLs, numberOfRuns: 3, metric assertions, results kept as artefacts.
Write results with the tool version, preset, number of runs and date.

How the agent checks the work

npx github:dawidolko/frontend-skills audit --url <url> gives the four category scores, the lab metrics and findings by rule id.
PageSpeed Insights (https://pagespeed.web.dev/) adds field data for public URLs with enough traffic.
Compare two runs with the Lighthouse viewer or lhci server only when both used the same preset and machine.

Checked by the audit

The static checks of these rules run in audit; this is a real session on the example project:

Terminal recording: audit lists findings by severity with rule ids and file:line, and fails at serious. — `audit`: counts by severity, each rule with its first location, the exit code.

Reference files

references/lighthouse.md1485 tokens

SKILL.md on GitHub