The schedule to grow this site phase-by-phase, generated from the Django Site model. No OpenRouter / no API — you (Claude Code) do the work, grounded in the real markdown under content/.
- Niche: Real-User Monitoring (RUM) & Core Web Vitals Tracking
- Audience: Frontend engineers, performance engineers, technical leads, webmasters, product analysts
- Live now: 51 pages, 161,186 words
- Current phase: expansion
- Next phase to build: maturity
Work through every step in order. Do not skip the uplift, the term cleanup, the SVG render check, or the finish/deploy steps — those were the gaps in earlier runs.
-
Read & orient. Read this whole file, then skim content/ to learn what exists and the writing tone.
-
Uplift EVERY existing page (not just new ones). Bring all current pages — from earlier phases — up to the Page blueprint below: its page anatomy, frontmatter, JSON-LD schema, the custom SVG visuals, and the mandatory wiki-style interlinking. Old pages must reach the current standard, not be left as they were.
-
Build the next phase. Add this phase’s page mix (see schedule), slotting pages into the existing hierarchy, each built to the same blueprint standard.
-
Keep it niche-specific. Section topics must be drawn from this niche, not generic placeholders.
-
Remove internal IA/SEO terms from visible copy. The words pillar, cluster, long-tail (and “hub and spoke”, “supporting page”, etc.) are internal labels — they must not appear in reader-facing prose. Scan and fix:
python3 /home/martin/WebstormProjects/_qa/term_lint.py rum-core-web-vitals.com
(Legit domain uses of “cluster” — e.g. a Kafka/DB cluster — are fine; rewrite only the information-architecture sense.)
-
Author custom SVG visuals per the “Custom visuals” section, then build the site and verify the SVGs render correctly ON THE PAGE — the page’s CSS/typography must not leak in and break them. Fix and rebuild until clean:
cd /home/martin/WebstormProjects/rum-core-web-vitals.com && npm run build
python3 /home/martin/WebstormProjects/_qa/svg_check.py rum-core-web-vitals.com
It statically validates each SVG (XML, id refs), then renders the BUILT pages in headless chromium with the real stylesheet applied — flagging page typography overflowing labels, distorted/zero-size, and empty SVGs. Must pass with no FAILs.
-
Record completion (updates page/word count, advances current→next phase, and rewrites this plan ready for the next phase). From the Django project (/home/martin/PycharmProjects/Django-Pillar-Cluster-Long-Tail):
.venv/bin/python manage.py finish_phase rum-core-web-vitals.com --completed maturity \
--blueprint "/home/martin/WebstormProjects/rum-core-web-vitals.com/_plan/blueprint.json"
-
Commit & deploy. Build, deploy to Cloudflare, and push to GitHub:
cd /home/martin/WebstormProjects/rum-core-web-vitals.com
npm run deploy
git add -A && git commit -m "Upgrade to maturity phase" && git push
| # |
Phase |
Status |
Adds |
Target total |
Focus |
| 1 |
1. Foundation |
✅ done |
2-3 pillars + 10-14 clusters + 8-12 long-tails |
~22 |
Establish core authority: the main pillars and their primary clusters, with enough long-tails to validate demand. Get a consistent page skeleton in place. |
| 2 |
2. Expansion |
✅ done |
1-2 pillars + 7-10 clusters + 18-25 long-tails |
~50 |
Broaden coverage: fill out each pillar’s clusters and add the high-intent long-tails around them. Strengthen interlinking between siblings. |
| 3 |
3. Maturity |
➡️ NEXT |
4-6 clusters + 28-40 long-tails |
~82 |
Deepen the long tail: comprehensive how-tos, comparisons and edge-case pages under existing clusters. Ensure FAQ blocks and schema on every page. |
| 4 |
4. Authority |
… future |
2-3 clusters + 20-30 long-tails |
~105 |
Complete topical authority: remaining gaps, advanced/expert pages, and a tight internal link graph so every page is 1-2 clicks from its pillar. |
- RUM architecture pillar (rum-architecture-tooling-self-hosting) appears to have no long-tail pages yet — add how-to long-tails covering self-hosted ingestion endpoint setup, ClickHouse/BigQuery schema design, and beacon payload compression
- Custom metrics pillar (custom-metrics-business-impact-tracking) likely needs long-tails on user-timing marks, element timing API, and conversion funnel overlay with RUM data — these are high-intent queries for product analytics engineers
- Add comparison/decision-matrix cluster pages: ‘RUM vendor comparison’ (Datadog vs New Relic vs self-hosted) and ‘synthetic vs field data trade-offs’ — currently missing and high-traffic query patterns
- Framework instrumentation long-tails are absent: Next.js App Router INP instrumentation, React hydration LCP impact, and Nuxt/Vue PerformanceObserver setup are distinct searched topics that fit naturally under existing clusters
(tailored to this site)
- Frontmatter (every page): title, description, slug, type, breadcrumb, datePublished, dateModified
- Schema (JSON-LD): Article, BreadcrumbList, HowTo, FAQPage
- Interlinking: Wiki-style inline cross-links are mandatory. Rules: (1) The first mention of any metric name (LCP, INP, CLS, FCP, TTFB) or named concept (PerformanceObserver, sendBeacon, CrUX, p75, RUM ingestion pipeline, layout shift score, long task, scheduler.yield) that has its own page must be a contextual inline link woven into the sentence — never a bare URL, always descriptive anchor text, e.g. ‘the PerformanceObserver lifecycle and buffered-entry handling must be initialized before hydration’. (2) When a cluster page references a sibling cluster (e.g. LCP page mentioning CLS), link it on first mention. (3) Every cluster and long-tail page must include a parent up-link in the opening paragraph, e.g. ‘as defined in Core Web Vitals & Performance Metrics Fundamentals’. (4) Every page ends with a ‘Related’ block listing 3-5 contextually relevant sibling or child pages as a tight bulleted list — no prose, just link + one-line description.
- H1 + 2-sentence production-context lead (what problem this pillar solves at scale)
- Paradigm/context section: field data vs synthetic, why this domain matters for ranking and UX
- Core metrics/concepts reference table: metric | threshold | engineering action (at least one table per pillar)
- Deep-dive subsections per major metric or concept covered by this pillar (one H2 per cluster topic, with prose + inline cross-link to the cluster page)
- Production instrumentation overview: canonical code snippet showing the unified telemetry hookup pattern for this pillar’s domain
- Data pipeline & sampling architecture: ingestion, percentile aggregation, columnar storage guidance
- Business/UX impact section: how to correlate telemetry to conversion, bounce rate, and ROI; formula or structured example
- Related block: 4-6 child cluster links with one-line descriptions
- H1 + RUM-context lead: one paragraph establishing where this cluster fits in the RUM/CWV pipeline and parent up-link
- Threshold configuration table: value ranges mapped to engineering response (Good/Needs Improvement/Poor with concrete actions)
- Measurement implementation section: production-ready code snippet with observer setup, buffered capture, lifecycle finalization
- Step-by-step debugging workflow: numbered list (identify → trace waterfall → correlate overlaps → validate in lab → deploy fix → monitor delta)
- Field data analysis patterns: segmentation by device class, network type, geography; what divergences to watch for
- Optimization strategies: concrete techniques with before/after impact, specific to this metric (e.g. fetchpriority, aspect-ratio, scheduler.yield)
- Failure modes & gotchas: cross-origin CORS caveats, SPA route transition edge cases, Safari PerformanceObserver gaps, background tab suspension
- CI/CD integration note: how to gate this metric in regression pipelines
- Related block: 3-5 sibling clusters and relevant long-tail pages with one-line descriptions
- H1 + one-paragraph problem framing: exact scenario this page addresses and parent cluster up-link
- Prerequisites / context checklist: what the reader must have in place before applying this guide
- Step-by-step implementation or how-to: numbered steps with runnable, copy-pasteable code blocks; each step explains the why
- Verification / expected output section: how to confirm the implementation is working (DevTools panel, RUM dashboard signal, console output)
- Edge cases and gotchas specific to this narrow scenario (browser quirks, framework-specific issues, timing hazards)
- Related block: 3 links — parent cluster, one sibling long-tail, one cross-pillar link
All code blocks must be JavaScript (or shell for CLI steps) with accurate, runnable syntax — no pseudocode. Metric threshold values must match current Google CWV spec (LCP ≤2.5s Good, INP ≤200ms Good, CLS ≤0.1 Good). Always use p75 as the canonical aggregation percentile, not mean or median. Avoid the word ‘delve’. The tone is production-engineering technical documentation — authoritative, no fluff, assume the reader is a senior frontend or performance engineer. Tables must be used for any threshold, comparison, or parameter reference — do not describe these in prose only. FAQPage JSON-LD should be applied only to pages that include an explicit FAQ section; HowTo JSON-LD applies to long-tail how-to pages.
When upgrading or building any page, add a custom, hand-authored inline SVG wherever a visual would genuinely raise quality (architecture/data-flow diagrams, sequence or state diagrams, comparison matrices, timelines, annotated illustrations). Do NOT add decorative or generic stock-style images. Each SVG must: be original and specific to the page’s content; match the site’s existing design system (colours, fonts, stroke weight); be responsive (viewBox, no fixed pixel width) and accessible (
/<desc>, role=“img”, aria-label); and use currentColor / CSS variables so it adapts to light/dark themes. Prefer one strong diagram that explains the hardest concept on the page over many small ones. Pillar pages should almost always carry a top-level overview diagram.</p>