home / skills / calm-north / seojuice-skills / audit-speed

audit-speed skill

Q: What thresholds define Good / Poor for Core Web Vitals?

LCP < 2.5s good, CLS < 0.1 good, INP < 200ms good. TTFB < 800ms and FCP < 1.8s are desirable.

Q: What are quick wins I can implement rapidly?

Add width/height to media, set fetchpriority on the LCP image, defer non-critical JS, compress assets, and convert images to WebP/AVIF.

Q: How do third-party scripts affect metrics?

They often block the main thread, increase INP and FCP, and add weight. Audit necessity, lazy-load, or defer them to reduce impact.

/skills/audit-speed

This skill analyzes page speed and Core Web Vitals to identify root causes and provide actionable optimization recommendations.

npx playbooks add skill calm-north/seojuice-skills --skill audit-speed

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

6.0 KB

---
name: audit-speed
description: >
  Deep Core Web Vitals and page speed audit. Use when the user asks about page
  speed, Core Web Vitals, LCP, CLS, INP, FCP, TTFB, Lighthouse scores, why a
  page is slow, performance optimization, or resource size analysis. For broader
  technical SEO issues, see diagnose-seo.
metadata:
  version: 1.0.0
---

# Audit Speed

Deep Core Web Vitals audit with root-cause analysis trees and resource
optimization recommendations.

## Core Web Vitals Thresholds

| Metric | Good | Needs Improvement | Poor |
|--------|------|-------------------|------|
| LCP (Largest Contentful Paint) | < 2.5s | 2.5s - 4.0s | > 4.0s |
| CLS (Cumulative Layout Shift) | < 0.1 | 0.1 - 0.25 | > 0.25 |
| INP (Interaction to Next Paint) | < 200ms | 200ms - 500ms | > 500ms |
| FCP (First Contentful Paint) | < 1.8s | 1.8s - 3.0s | > 3.0s |
| TTFB (Time to First Byte) | < 800ms | 800ms - 1800ms | > 1800ms |

## Before You Start

Gather this context:

1. **Which pages?** Homepage, key landing pages, or specific slow pages.
2. **Current scores.** If the user has Lighthouse or PageSpeed Insights data, start there.
3. **Tech stack.** CMS, framework, hosting — this determines which optimizations are available.
4. **Known constraints.** Third-party scripts they can't remove, design requirements that limit optimization.

If no data is available, suggest running Google PageSpeed Insights on the key URLs.

## LCP Root-Cause Tree

LCP measures when the largest visible element finishes rendering. Diagnose:

**Is TTFB slow (> 800ms)?**
- → Server response time issue
- Check: hosting quality, CDN configuration, database queries, server-side rendering time
- Fix: upgrade hosting, add CDN, optimize server-side code, enable caching

**Is the LCP element an image?**
- → Image optimization issue
- Check: image format (use WebP/AVIF), image size (serve responsive sizes), lazy loading on LCP image (should NOT be lazy loaded)
- Fix: convert to modern formats, add `width`/`height` attributes, use `fetchpriority="high"` on LCP image, preload the LCP image

**Is the LCP element text?**
- → Font loading issue
- Check: custom fonts blocking render, font file size, font-display strategy
- Fix: use `font-display: swap` or `optional`, preload critical fonts, subset fonts to used characters

**Is render-blocking CSS/JS delaying the LCP?**
- Check: large CSS files in `<head>`, synchronous JS before content
- Fix: inline critical CSS, defer non-critical CSS, async/defer JS

## CLS Root-Cause Tree

CLS measures unexpected layout shifts. Diagnose:

**Do images/videos lack dimensions?**
- → Browser can't reserve space before loading
- Fix: add `width` and `height` attributes to all `<img>` and `<video>` elements, use CSS `aspect-ratio`

**Do ads or embeds inject content?**
- → Dynamic content pushing existing content down
- Fix: reserve space for ad slots with min-height, use `contain-intrinsic-size` for lazy content

**Do fonts cause text reflow?**
- → FOUT (Flash of Unstyled Text) causes layout shift when custom font loads
- Fix: use `font-display: optional` (no swap = no shift), or match fallback font metrics

**Does dynamic content insert above the fold?**
- → Banners, cookie notices, notifications pushing content
- Fix: use overlays instead of inline insertions, or reserve space with fixed-height containers

## INP Root-Cause Tree

INP measures responsiveness to user interactions. Diagnose:

**Is the main thread blocked by long tasks?**
- Check: JavaScript execution time, third-party scripts, large DOM
- Fix: break long tasks with `requestIdleCallback` or `setTimeout`, code-split heavy modules

**Do event handlers do heavy synchronous work?**
- Check: click handlers that trigger large DOM updates, form validation on every keystroke
- Fix: debounce inputs, use requestAnimationFrame for visual updates, offload work to web workers

**Are third-party scripts competing for the main thread?**
- Check: analytics, chat widgets, A/B testing tools, social embeds
- Fix: defer loading until after interaction, use `loading="lazy"` for embeds, consider removing low-value scripts

## Resource Analysis

Break down the total page weight:

| Resource Type | Size | Assessment | Action |
|---|---|---|---|
| HTML | [x] KB | [ok/large] | Compress, reduce inline styles/scripts |
| CSS | [x] KB | [ok/large] | Remove unused CSS, minify, critical CSS extraction |
| JavaScript | [x] KB | [ok/large] | Code-split, tree-shake, defer non-critical |
| Images | [x] KB | [ok/large] | Modern formats, responsive sizes, lazy load below fold |
| Fonts | [x] KB | [ok/large] | Subset, limit families/weights, preload critical |
| Third-party | [x] KB | [ok/large] | Audit necessity, defer, self-host if possible |

**Benchmarks:**
- Total page weight under 1.5 MB is good
- JavaScript under 300 KB (compressed) for most sites
- CSS under 100 KB (compressed)
- First-party fonts under 100 KB

## Output Format

### Speed Audit: [URL or domain]

**Core Web Vitals**

| Metric | Value | Rating | Root Cause |
|--------|-------|--------|------------|
| LCP | [value] | Good / Needs Improvement / Poor | [identified cause] |
| CLS | [value] | ... | ... |
| INP | [value] | ... | ... |
| FCP | [value] | ... | ... |
| TTFB | [value] | ... | ... |

**Resource Breakdown**
[Table from Resource Analysis]

**Priority Fixes**

For each failing metric, ordered by impact:

1. **[Metric]: [Root cause]**
   - Current: [value]
   - Target: [threshold]
   - Fix: [specific action]
   - Estimated impact: [high/medium/low]

2. ...

**Quick Wins**
List optimizations that require minimal effort:
- [ ] Add `width`/`height` to images
- [ ] Set `fetchpriority="high"` on LCP image
- [ ] Defer non-critical JavaScript
- [ ] ...

---

> **Pro Tip:** Use the free [CWV Impact Calculator](https://seojuice.com/tools/cwv-impact/)
> to estimate the traffic impact of fixing Core Web Vitals, and the
> [Critical CSS Generator](https://seojuice.com/tools/critical-css-generator/) to extract
> above-the-fold CSS. SEOJuice MCP users can run `/seojuice:page-audit [domain] [url]` for
> instant CWV scores, Lighthouse data, and resource breakdowns.

Overview

This skill performs a deep Core Web Vitals and page speed audit with actionable root-cause analysis and prioritized fixes. It identifies why pages are slow, breaks down resource weight, and recommends targeted optimizations for LCP, CLS, INP, FCP, and TTFB. Use it to turn Lighthouse/PageSpeed data into a practical performance plan.

How this skill works

The skill inspects Core Web Vitals and related metrics, analyzes the LCP element, layout shift sources, main-thread blocking, and server response behavior. It produces a resource breakdown (HTML, CSS, JS, images, fonts, third-party) and a prioritized list of fixes with estimated impact. Where data is missing, it guides on collecting Lighthouse or PageSpeed Insights reports and necessary site context.

When to use it

You need a root-cause diagnosis for slow page loads or poor Core Web Vitals.
Planning performance improvements before a redesign or migration.
Auditing landing pages with high bounce or low conversion due to speed.
Evaluating third-party scripts and their impact on responsiveness.
Preparing a prioritized developer task list for performance work.

Best practices

Collect Lighthouse or PageSpeed Insights reports for the target URLs first.
Identify the LCP element and ensure it’s not lazy-loaded; preload critical assets.
Add explicit width/height or aspect-ratio for media to prevent CLS.
Reduce main-thread work: code-split, defer non-critical JS, and break long tasks.
Audit third-party scripts; defer or remove low-value scripts and consider self-hosting essential assets.

Example use cases

Home page LCP is 5s: find whether TTFB, image, font, or render-blocking assets are the root cause.
High CLS on product pages: detect missing image dimensions, ad slot shifts, or dynamic banners.
Slow interactivity (high INP) on single-page apps: locate long tasks and heavy event handlers.
Pre-launch checklist: ensure total page weight and JS/CSS budgets meet recommended thresholds.
Post-audit handoff: create prioritized developer tasks with estimated impact for each fix.

FAQ

What thresholds define Good / Poor for Core Web Vitals?

LCP < 2.5s good, CLS < 0.1 good, INP < 200ms good. TTFB < 800ms and FCP < 1.8s are desirable.

What are quick wins I can implement rapidly?

Add width/height to media, set fetchpriority on the LCP image, defer non-critical JS, compress assets, and convert images to WebP/AVIF.

How do third-party scripts affect metrics?

They often block the main thread, increase INP and FCP, and add weight. Audit necessity, lazy-load, or defer them to reduce impact.