FoxeraClear the backlog: 10 Codex prompts for your own files
site-speed-pass
find the pages and images slowing your website down
How to use it
Codex only. Nothing else to install. Save the prompt as a file and run it, or paste it straight into Codex.
codex exec -C "your folder" - < the-prompt.md
It does the whole job in one pass on your own machine and writes the result into the folder you pointed it at.
The prompt
--- name: site-speed-pass description: Measures your website and returns the exact pages and image files costing you load time, ranked by the measured seconds each one costs, with the fix for each. --- # Find the pages and images that are slowing your website down You point it at your website address and your website folder. You get back a ranked list of the actual files that are costing you load time, the measured cost of each one, and the change to make. ## What it does 1. **Pick five real pages, not the whole site:** read `sitemap.xml` if the site has one, otherwise list the page files in the folder. Choose the home page, the page that gets the most visitors, the main product or service page, the contact page and one blog post. Everything after that is noise until these five are fixed. 2. **Take the real-visitor numbers first:** call the PageSpeed Insights API for each of the five addresses with `strategy=mobile`, and read the `loadingExperience` block. Those figures come from real Chrome users over the previous 28-day collection period, at the 75th percentile. If a page has no `loadingExperience` block, write "no field data" against it and carry on. Never quietly use the lab score in its place. 3. **Judge every page against the published thresholds:** Largest Contentful Paint good at 2.5 seconds or less, Interaction to Next Paint good at 200 milliseconds or less, Cumulative Layout Shift good at 0.1 or less, all measured at the 75th percentile of page loads (web.dev, Web Vitals). INP replaced First Input Delay as a Core Web Vital on 12 March 2024, so a report that still talks about FID is out of date. 4. **Name the single file that caused the slow paint:** from the same API response, read `lighthouseResult.audits["largest-contentful-paint-element"]` and the network entries, and write down the exact file address, its transfer size in bytes and the moment it finished loading. On a small business site this is a hero image about nine times in ten. 5. **Weigh every image on disk:** walk the site folder and list every `.jpg`, `.jpeg`, `.png`, `.gif`, `.webp` and `.avif` over 200 KB with its true byte count and the page that references it. Then compare each image's stored pixel width with the width it is displayed at. A 3000 pixel photograph shown in a 600 pixel slot is the most common single fix on a small business website, and the saving is measurable before and after. 6. **Count what blocks the page from drawing:** list every `<script>` and stylesheet in `<head>` that is not marked `defer`, `async` or `media`, with its measured transfer size, and every web font file with its byte count. Fonts and third-party tag managers are the usual second and third offenders after images. 7. **Rank by measured milliseconds, biggest first:** order the fixes by the time each file actually took in the network trace. Lighthouse also prints its own "Est Savings" figures: if you quote one, write the word estimated in the same line, because that number is a model of what might happen, not a thing that was observed. 8. **Write one line per file:** the path, what is wrong with it, the exact change to make, and the measured cost today in kilobytes and milliseconds. No general advice, no "consider optimising". 9. **Re-measure the same five addresses and print both columns:** run the identical API call after the changes and show before and after side by side, with the date and time of each run. A fix without a second measurement is not finished and must not be reported as done. ## Then it checks 1. Every measured page has a run date, a strategy (mobile or desktop) and a source (field or lab) written next to its numbers. 2. Every file named in the fix list exists at the path given, and the byte size in the report matches the size on disk exactly, not rounded. 3. Every number in the report traces back to either a PageSpeed Insights response field or a file size read from disk. Anything else is deleted or labelled estimated. 4. Pages with no real-visitor data are marked "no field data, lab only" and are not counted as passing or failing the thresholds. 5. The thresholds quoted are still 2.5 seconds, 200 milliseconds and 0.1 at the 75th percentile, checked against web.dev on the day the report is written. 6. Before and after figures exist for every change that was applied, from the same address and the same strategy. Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop. ## Rules - Public information only. - Never invent a fact, a number or a quote. - Measured numbers only. If the only figure available is an estimate, say estimated in the same sentence, and never rank a fix list by estimates. - Never overwrite an original image. Write the smaller version alongside it and keep the original until the after measurement has been recorded. - A score out of 100 is not a business number. Report the change in seconds a visitor waits, and leave the score as a footnote. - If a PageSpeed Insights API key is used, it never appears in the report, in a commit, or in any file left behind. Run it in one pass over your own files: ``` codex exec -C "the folder" - < the-prompt.md ``` ## Built from - web.dev, Web Vitals, https://web.dev/articles/vitals, read 7 September 2026: the exact good thresholds quoted in step 3, LCP 2.5 seconds, INP 200 milliseconds, CLS 0.1, and the 75th percentile rule. - web.dev, Advancing Interaction to Next Paint, https://web.dev/blog/inp-cwv-launch, published 12 March 2024: the date INP became a stable Core Web Vital in place of FID, used to date-stamp step 3. - Google, About PageSpeed Insights, https://developers.google.com/speed/docs/insights/v5/about, read 7 September 2026: the 28-day real-user collection period, the 75th percentile reasoning, and the mid-tier mobile device the lab run emulates, which is why step 2 takes field data before lab data. - GoogleChrome/lighthouse, https://github.com/GoogleChrome/lighthouse, 30743 stars: the audit engine behind the API response, and the fact that its opportunity savings are published as estimates, which is why step 7 forces the word estimated. - addyosmani/web-quality-skills, https://github.com/addyosmani/web-quality-skills, 2761 stars: the measurement-first ordering, and its rule that findings from reading code alone are hypotheses rather than measured regressions, which became check 3.
Built from the best public work on this
Sources for site-speed-pass
Everything below was loaded and read on 7 September 2026. Star counts were read from the GitHub API at `https://api.github.com/repos/<owner>/<repo>` and are printed exactly as returned.
web.dev, Web Vitals
https://web.dev/articles/vitals
Google's own definition page for the Core Web Vitals programme, maintained by the Chrome team. It is the page that carries the current metric list and the pass marks. Read for the thresholds and the percentile: Largest Contentful Paint "should occur within 2.5 seconds of when the page first starts loading", Interaction to Next Paint "200 milliseconds or less", Cumulative Layout Shift "0.1 or less", and the instruction to measure "the 75th percentile of page loads, segmented across mobile and desktop devices". Every one of those numbers appears in step 3 of the skill and is re-checked by check 5, so that a stale threshold cannot survive in a report.
web.dev, Advancing Interaction to Next Paint
https://web.dev/blog/inp-cwv-launch
The Chrome team's launch post for the metric change, dated 12 March 2024. It states plainly that INP became a stable Core Web Vital on that day, replacing First Input Delay. This gave the skill a hard date to quote, and gave step 3 its warning that a performance report still discussing FID is measuring something Google retired.
Google, About PageSpeed Insights
https://developers.google.com/speed/docs/insights/v5/about
The official explanation of what PageSpeed Insights actually returns. Two things were taken from it. First, the field data covers "real users' First Contentful Paint (FCP), Interaction to Next Paint (INP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS) experiences over the previous 28-day collection period", which is why step 2 reads `loadingExperience` before anything else and why a page with no field data must be labelled rather than silently replaced by a lab score. Second, the lab run simulates "the page load conditions of a mid-tier device (Moto G4) device on a mobile network", which is why the skill records the strategy next to every number in check 1: a mobile figure and a desktop figure are not comparable.
GoogleChrome/lighthouse
https://github.com/GoogleChrome/lighthouse, 30743 stars
The open-source audit engine that produces the `lighthouseResult` block inside every PageSpeed Insights response, so it is the tool the skill is really reading even when it never runs locally. Its audit output was read for the field names used in step 4, `largest-contentful-paint-element` and the network records. The decision that mattered came from how Lighthouse labels its own opportunity numbers as estimated savings: those are modelled, not observed, so step 7 forbids ranking a fix list by them and forces the word estimated into any line that quotes one.
addyosmani/web-quality-skills
https://github.com/addyosmani/web-quality-skills, 2761 stars
A public collection of agent skills for Lighthouse, Chrome DevTools and Core Web Vitals, described by its own author as measurement-first. Its performance skill was read in full. Two of its rules were adopted. It insists on establishing a field plus lab baseline before editing anything, which is the ordering of steps 2, 3 and 9 here. It also separates observed findings from inferred ones, which became check 3 in this skill: every number must trace back to an API field or a byte count read from disk.
Best public prompt we found for this job
`addyosmani/web-quality-skills`, the file `skills/performance/SKILL.md`, is the best public artefact for this job. It is the only one of the candidates that treats the difference between a measurement and a guess as a rule rather than a preference. The line worth copying verbatim:
"When no runnable page exists, perform static inspection but call findings hypotheses, not measured regressions."
Dropped
`HenryYannis/lighthouse-performance-skills` was found in the search and checked against the GitHub API: 1 star. Too small to cite as evidence of an established practice, so it was left out rather than padded in.
Want this running in your business?
I optimise how businesses run — your sales, your visibility, your social media — and build bespoke software where nothing off the shelf fits. The first conversation is free. Work starts from £150 a day.