# Audit Performance of a Nuxt Site with Lighthouse

Yes. An agent builds your Nuxt site, serves the production output, runs Lighthouse on its main pages and lists the five fixes that matter, each with its file.

[Run this on Rush](https://cloud.getrush.ai/run/lighthouse-audit/nuxt/).

## What the agent does

The agent clones the repository into its own sandbox and reads the setup that decides what Lighthouse will see. In a Nuxt site like nuxt/movies, `package.json` installs Nuxt as `npm:nuxt-nightly@4.6.0-…` and declares Node `^24.0.0` and pnpm `11.1.2` under `devEngines`. `nuxt.config.ts` loads `@vueuse/nuxt`, `@unocss/nuxt`, `@nuxt/image`, `@nuxtjs/i18n` with 14 locales and `@nuxtjs/html-validator`, and sends all movie data and every image through `https://movies-proxy.vercel.app`: the API as `runtimeConfig.public.apiBaseUrl`, and images through an `ipx` provider at its `/ipx` path. So the site needs no TMDB key to build, and the agent notes that every image request leaves the sandbox for that proxy, which shows up in Lighthouse as network time the code alone does not control.

It runs `pnpm install` and `pnpm build`, which is `nuxt build`, and starts the output with `pnpm start`, which runs `node .output/server/index.mjs`. Measuring `nuxt dev` would be wrong: Vite serves unbundled modules in development, which no visitor ever gets. Then it runs the Lighthouse CLI in headless Chrome against the home page and one movie page under `app/pages/[type]/[id].vue`, taking a real id from the home page's hero link, for mobile and desktop, three times each, and keeps the median.

Then it reads the costly audits against the code. `app/pages/index.vue` awaits `listMedia` and then `getMedia` in turn before the page can render, two requests one after the other on the server, while the movie page already runs `getMedia` and `getRecommendations` together in a `Promise.all`; slow server response time on the home page points there. The largest contentful paint is usually the hero backdrop in `app/components/media/Hero.vue`, a `NuxtImg` at `width="1220"` with `format="webp"`, `loading="eager"` and `preload`, so the agent checks whether it has `sizes` for small screens. Posters in `app/components/media/Card.vue` load eagerly only when `priority` is set, which `index.vue` passes to the first carousel only.

It also checks the response headers: `routeRules` in `nuxt.config.ts` gives every path `cache-control: private, no-store`, which Lighthouse's caching audits may flag, and which matters for a repeat visit more than for a first load. It ranks the five changes by Lighthouse's estimated savings, names the file and edit for each, and changes no code.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Clone https://github.com/nuxt/movies. Run pnpm install and pnpm build, start the production server with pnpm start, and run the Lighthouse CLI in headless Chrome on the home page and one movie detail page, for mobile and desktop, three runs each, keeping the median. Note which requests go to movies-proxy.vercel.app. Write lighthouse.md with the scores and Core Web Vitals per page, the five changes that would help most ranked by estimated savings, and for each the file in the repo that causes it (pages, components and nuxt.config.ts) and the edit you would make. Attach every Lighthouse JSON report. Change no code."
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is `lighthouse.md` and the Lighthouse JSON reports, one per page and form factor, as artifacts on the session; each download link lasts an hour and a fresh one comes with every read of the session. The markdown starts with the median scores for both pages on mobile and desktop, with largest contentful paint, total blocking time, cumulative layout shift and server response time beside them, and a short note on how much of the load went to the image and API proxy.

The ranked fixes come next. Each names the Lighthouse audit, its estimated saving, the file and line of code behind it (the sequential fetches in `app/pages/index.vue`, an image without `sizes` in `Hero.vue`, a header from `routeRules`) and the edit the agent would make. The transcript keeps the build log and each Lighthouse run, so a reviewer can see the spread behind every median.

Before acting, a reviewer separates what the code controls from what the proxy does: an image that is slow because the proxy is far from the sandbox is not a bug in the component. They also check that i18n and the HTML validator behave in the production build as they do in the deployed site. A follow-up to the same session can ask the agent to apply the top fixes on a branch and measure again.

## Run it on every merge to main

To catch a regression in the change that caused it, run the audit on every merge to the default branch. Have the webhook from your Git host reach your server, and send this request with the commit in the prompt and an `Idempotency-Key` built from the commit hash, so a redelivered webhook starts no second run.

With a webhook URL on the API key, Rush POSTs `run.completed` with the `session_url` when each run finishes. Your server compares the new scores with the last ones and comments on the merged change only when a page falls.

## Why run it on Rush?

A Lighthouse number is only as good as the machine and the build it ran on. In a Rush sandbox the agent makes a production build of the Nuxt app, serves `.output` on a machine with nothing else open, and runs each page several times, so the scores reflect the code and not a busy laptop.

The report comes with its proof: the raw Lighthouse JSON, the build output and every run in the transcript, and each recommendation names the file to change. Several pages, branches or sites can run at once, one run each, up to the key's concurrent run limit.

## Frequently asked questions

### Does it measure the dev server or a production build?

A production build. The agent runs `nuxt build` and serves `.output/server/index.mjs`, because the dev server serves unbundled modules and compiles on demand, and its scores say nothing about what visitors get.

### My images go through a CDN or an image proxy. Is that counted?

Yes, as it would be for a visitor. The agent notes which requests leave for the proxy and how long they took, so the report can separate a slow image host from a component that requests an image too large for its slot.

### Can it audit more pages, or pages behind a login?

Yes. Name the routes in the prompt. For a page behind a login, give the agent test credentials as Project secrets and start the session in that Project; it signs in with the sandbox's browser before running Lighthouse.

### Will it fix the problems it finds?

Not in this run: the prompt says to change no code. Ask the same session in a follow-up to apply the fixes on a branch, re-run Lighthouse and open a pull request with the before and after scores.