Reports and sharing
Reports are built for decisions. nimo tells you what is slow, why it matters, and what to fix first.
Fix the hero image before touching JavaScript.
It is responsible for the slow first view and has the lowest risk path to a better mobile LCP.
LCP
3.2s
Needs work
CLS
0.05
Good
INP
180ms
Watch
Share report
Public linkWhat a report includes
Verdict
A short explanation of the current state of the page.
Metrics
Core Web Vitals and supporting metrics from field and lab data.
Deep dives
Images, scripts, fonts, third parties, page entities, search context, and traffic context when available.
Next steps
Recommendations ranked by expected impact and practicality.
Incident evidence
Stored regression evidence when nimo has enough baseline and follow-up data.
Readiness findings
Advisory AI-agent readiness checks when readiness work is enabled.
Prioritized recommendations
nimo does not simply repeat every Lighthouse warning. It ranks work by likely user impact, stack relevance, metric trend, and safety.
A recommendation can be important even when the Lighthouse score looks fine. nimo checks the field data first when it exists.
Inspect request evidence
Signed-in reports can show an Inspect requests action when request evidence is available and the Evidence explorer is enabled for the account. The normal report stays compact: it shows the answer, the important loaded-resource facts, and a retained-count note before sending power users into the drill-in view.
Compact by default
The report does not show a dense request table in the main report flow. Use the drill-in only when you need to inspect retained files.
Retained evidence
The explorer uses capped request rows retained from the audit. It is not a complete HAR archive.
Safe labels
Request labels and search values strip query strings and avoid request headers, bodies, cookies, and raw payloads.
Signed-in only
Public report share links stay compact and do not expose Evidence explorer entry points.
Use Evidence explorer to find the biggest, latest, first-party, and third-party retained files. Use a same-device rerun after a deploy before treating one lab run as proof that a fix worked.
Platform-aware quick wins
When nimo has a confident stack signal, a report can show one platform-aware quick win for WordPress, Shopify, Webflow, Next.js, or Cloudflare.
Best-effort detection
Stack detection is a confidence signal, not a guarantee. Confirm the platform before changing production.
One path
The card shows the platform, owner, one action, why it comes first, and a confidence note.
Clear owner
Actions are labeled for the developer, marketer, CMS owner, or hosting/CDN owner.
No unsafe automation
nimo does not remove plugins, disable apps, edit code, or change Cloudflare settings from public chat. Cloudflare changes require a signed-in user, explicit approval, and safe actions enabled for the account.
Examples: WordPress advice may start with the hero image, plugin scripts, or page cache. Shopify advice may start with image sizing, app embeds, pixels, or theme code. Webflow advice may start with assets, embeds, and first-section interactions. Next.js advice may start with next/image, font loading, bundle splitting, route caching, or data fetching. Cloudflare advice only points to cache, image delivery, or headers when the evidence supports it and the page is safe to cache.
Understand field, lab, and missing data
CrUX field data shows real Chrome visits over roughly 28 days. It is not first-party RUM and it is not real-time. It can lag after a deploy and may use origin-level data when page-level data is missing.
Lighthouse lab data is a point-in-time simulation for the tested URL and device. It is useful for debugging and immediate post-fix checks, but it may not match what real visitors experienced.
Field fails, lab passes
Fix the field failure first. Real visitors are seeing the issue even if today's simulated run looks fine.
Lab fails, field passes
Treat the lab failure as a diagnostic clue. Confirm it on the same device before overriding passing field data.
CrUX is missing
The page or origin may not have enough Chrome traffic. Use Lighthouse as a baseline, then rerun the same device after each fix.
Incident evidence
When performance incident tracking is enabled and nimo has enough evidence, a report can show incident evidence for a regression. The panel focuses on what changed, the metric delta, the affected page or site scope, evidence refs, likely owner, confidence, and recommendation context.
Incident evidence is not a raw trace viewer. It uses stored, scoped evidence so a teammate can understand the regression without exposing cookies, credentials, request headers, raw Lighthouse payloads, or private URLs.
If Linear is configured, nimo can preview an issue from an active incident. Creating the issue requires an explicit create action, and duplicate issue links are reused when nimo can identify an existing issue.
Agentic readiness
Agentic readiness is optional and advisory. It checks whether AI agents can discover and interact with the public site more reliably, using signals such as /llms.txt, WebMCP metadata, declarative forms, AI accessibility, and Lighthouse Agentic Browsing output.
Readiness findings do not mean performance monitoring failed. Treat them as optional AI-discovery and interaction-quality work, separate from Core Web Vitals, uptime, and incident alerts.
Eligible readiness findings can show a Linear issue preview after opt-in. nimo keeps the handoff narrow and reuses already ticketed findings instead of creating duplicate work.
Competitor proof reports
Public competitor comparisons answer three questions before the metric table: who wins on LCP, why they win, and what to fix first.
Who wins
The leaderboard ranks your page and each competitor by LCP, with the source labeled as CrUX field data, Lighthouse lab data, or unavailable.
Why they win
The proof section compares simple facts such as page weight, JavaScript weight, request count, third-party scripts, TTFB, and render-blocking resources.
First fix
nimo picks one owner, one expected impact, and one acceptance check so the next step is easy to hand to a developer, marketer, or hosting team.
Confidence
The report says whether the comparison is strong, mixed, or limited so you know how much to trust the result.
Visual proof
When safe screenshots are available, the report can show your page next to the faster competitor.
Six-month trend
When public CrUX history is available, the report shows whether mobile and desktop LCP are improving, flat, or getting slower.
CrUX field data is the 28-day p75 from real Chrome users. It is the best signal for what visitors experienced, but it can lag after a deploy and may use origin-level data when page-level data is missing.
Lighthouse lab data is a point-in-time test for the exact URL. It is useful right after a fix because you can rerun it immediately.
When a comparison mixes CrUX field data and Lighthouse lab data, treat the result as directional. After a deploy, rerun Lighthouse right away and wait 2-4 weeks for CrUX field data to settle.
Public proof reports only include audit facts from public URLs. They do not expose request headers, cookies, secrets, or raw Lighthouse blobs. LCP element snippets are cleaned before display.
Comparison methodology
Source labels stay visible for every comparison fact: CrUX field data, Lighthouse lab data, URL-level CrUX history, origin-level CrUX history, or unavailable. nimo does not blend field and lab data into one unlabeled score.
User-confirmed URLs
Live comparisons run only after the user confirms the URLs and presses Compare speed.
Point-in-time lab data
Lighthouse lab data is a point-in-time test for the exact URL and device.
Delayed field data
CrUX field data reflects the latest available public 28-day Chrome window and can lag after deploys.
Weekly watches
Competitor watches rerun chosen public URL pairs weekly.
CrUX trend history uses roughly six months of public history when available.
The leaderboard orders pages by measured LCP for that comparison only. It is directional evidence, not a promise of search ranking improvement, conversion lift, Core Web Vitals passing status, or the same order after a later CrUX update or Lighthouse rerun.
CrUX trend history
CrUX trend history uses public Chrome usage data to show LCP momentum over roughly the last six months. It is not first-party RUM, it is not real-time analytics, and it may be missing for newer or lower-traffic pages.
Directional trend
The trend section compares the first and latest public LCP values and labels each page as improving, flat, getting slower, or not enough samples.
Mobile and desktop
nimo keeps mobile and desktop trend summaries separate because the same page can move differently on each device.
URL or origin
The report labels whether the trend came from URL-level CrUX history or origin-level CrUX history. Origin fallback means Chrome did not have enough page-level history.
Missing data
If a page does not have enough public history, nimo says that plainly and keeps the current Lighthouse and CrUX field labels visible.
Use CrUX trend history to understand momentum, not to prove a fix the same day it ships. For immediate verification, rerun Lighthouse on the same device, then watch CrUX over the next few weeks.
Visual proof screenshots
Visual proof is a side-by-side screenshot pair from the same kind of Lighthouse lab run used for the comparison. It is meant to make the LCP gap easy to understand, not to replace the metric table.
One lab capture
Screenshots come from a single Lighthouse lab capture per page. Use them as directional evidence, then rerun after a fix.
May be unavailable
nimo hides visual proof when screenshots are missing, expired, too large, unsupported, or fail safety checks.
Stored artifacts only
Reports use stored PNG or JPEG artifacts from the audit. They do not hotlink competitor screenshots from third-party URLs.
Safe exports
Markdown exports include the caption only. PDF exports include thumbnails only when the stored image data is safe.
Treat visual proof as the simple screenshot explanation for a measured gap. Use LCP, source labels, proof facts, and a rerun after deploy to decide whether the fix worked.
Suggested and default competitors
On the public comparison form, nimo can suggest up to three competitor URLs after the user enters their page. Suggestions are optional: the user can pick a suggestion, edit it, remove it, or type competitor URLs manually.
Default competitor presets are editorial starting points used by comparison pages. They prefill known public URLs, but they do not start a live audit by themselves. Before a live comparison runs, the user must confirm one to three competitor URLs by pressing Compare speed.
nimo only sends the target URL to the suggestion endpoint. Analytics for this flow record counts and source labels, not competitor domains or full URLs.
Copy fix prompts
When a public comparison has a safe first fix, use Copy fix prompt to copy a concise handoff for Claude Code, Cursor, or another coding agent.
The prompt includes the public URL, winning competitor URL, failing metric, source labels, first fix, sanitized evidence, acceptance criteria, and a rerun instruction. It tells the agent not to change unrelated behavior and to ask before destructive changes.
Copy fix prompts exclude credentials, cookies, request headers, private account data, raw Lighthouse blobs, raw HTML, and URL query strings.
Export Markdown and PDF
Public competitor comparisons can be copied as Markdown or downloaded as Markdown and PDF. Markdown is best for tickets, pull request notes, agency task lists, and coding-agent handoffs. PDF is best for stakeholder or client handoff when the reader needs a compact, readable report.
Both exports include the verdict, compared URLs, leaderboard, proof facts, visual proof caption when available, first fix when available, rerun guidance, generated date, and source labels.
Markdown does not embed screenshots or external image URLs. PDF thumbnails are included only from stored safe screenshot artifacts. Exports are generated from the public share token on demand and do not include credentials, cookies, request headers, private account data, raw Lighthouse blobs, raw HTML, or URL query strings.
Share a report
Use share links when you need to send a report or comparison to a client, teammate, or developer. Share links are public URLs with an expiry window.
Open the report
Choose an audit report or comparison.
Create the share link
Pick the expiry window that matches how long the recipient needs access.
Send the link
The recipient can view the report without signing in.
Use reports with clients
For client work, save a before audit, make the change, run another audit, and share the comparison. This makes the work concrete: what changed, by how much, and what remains.
Client summary prompt
Summarize this report for a client in five bullets. Focus on business impact and the next fix.
Share the next report
Use a public report link when someone needs the answer without learning the dashboard.