Responsiveness

Summary#

Responsiveness previews any public page at true desktop, tablet and mobile viewports and, at the same time, has an AI read the page's real HTML and CSS and report what is likely to break. Every finding names the file, the selector and a ready-to-paste fix, and you can keep asking follow-up questions afterwards.

Purpose#

Most responsive faults are invisible until someone complains. Resizing a browser window is not the same as a phone: server-rendered markup, lazy-loaded images and viewport-dependent scripts all keep the desktop output when you drag the window narrower, so the preview you trust is not the page your visitor sees.

The other half of the problem is that a screenshot tells you something looks wrong but not which rule to change. This tool is built to close both gaps: it renders the page at the real device width so the site's own breakpoints actually fire, and it reads the served HTML and CSS so every finding can point at a specific rule rather than at a general principle.

Overview#

Enter a URL. Two things happen in parallel.

The preview loads immediately, through Metric Vault's own proxy. The proxy re-serves the page from our origin, so sites that normally refuse to be embedded still render. The frame is sized to the exact device viewport and then scaled down to fit your screen, which means the previewed site evaluates its real media queries. Switching device reloads the page at the new size rather than merely resizing the frame.

The analysis runs at the same time. Metric Vault fetches the page, extracts a factual digest of it — the viewport meta tag, the actual @media conditions, CSS rules that hard-code large widths or small font sizes, the heading outline, a coarse DOM skeleton, a nav markup sample, and counts of images, links and inputs — and sends that digest to Claude for review.

The model is told exactly what it does and does not have. It has no screenshot, no rendered pixels, no computed styles and no JavaScript execution, and at most two external stylesheets are fetched. It is instructed to ground every finding in a value from the digest, to say "likely" or "check" where something can only be inferred, and to treat missing evidence as unknown rather than as broken.

Once the report lands, the chat panel above it stays live so you can ask for more.

Benefits#

• True device viewports, not a resized desktop window. Desktop renders at 1440 × 900, tablet at 768 × 1024, mobile at 390 × 844.
• Findings that name the file and the selector, so the fix is a lookup rather than a hunt.
• A ready-to-paste snippet with most findings — corrected CSS, HTML or utility classes based on the rule actually in your stylesheet.
• A conversation, not a PDF. Ask for a different approach, more depth, or the same fix expressed for your framework.
• It costs nothing. No credits, on any plan.

Use Cases#

• Pre-launch mobile check. You are shipping a redesign and want a second opinion on breakpoints before it goes live.
• A page that "looks wrong on phones" with no reproducible report from whoever raised it.
• Accessibility first pass. You need a starting list of heading-structure and tap-target issues before a formal audit.
• Competitor or inspiration teardown. Preview any public site at three sizes side by side with its analysis.
• Handing work to a developer. The file, selector and snippet are enough for a ticket.

Requirements#

• A signed-in Metric Vault account. Any plan, including Free.
• A publicly reachable URL that returns real HTML. Pages behind a login, and single-page apps that render everything client-side, will not produce much.
• No integration, no verified domain and no credits.

Permissions#

Available on every plan and to every team role. There is no upgrade prompt on this screen and no reduced version.

Cost#

0 credits. Responsiveness does not charge, does not count against your monthly allowance, and does not consume the hourly light-tool ceiling. Runs are recorded in your Library at zero cost so you can find them again.

This is unusual for an AI-backed tool, and it is deliberate: the analysis reads your page directly rather than calling a paid search-data provider. See How credits work for how the allowance works elsewhere.

Navigation Path#

Dashboard → Site Health → Responsiveness

Inputs#

Step-by-Step Guide#

1. Open Site Health in the left rail, then select Responsiveness.
2. Type the URL in the field marked example.com. Include the path for the specific template you want reviewed.
3. Select Analyze site, or press Enter. The button reads Analyzing....
4. The preview appears immediately at desktop size while the report is still being written. A skeleton holds the report's place.
5. When the report lands, read the score and verdict, then Critical issues.
6. Switch between Desktop, Tablet and Mobile to see the page at each viewport. Each switch reloads the page at that size.
7. Ask a follow-up in the chat panel, or select one of the suggestion chips.
8. Select Add to analyze another site, or return later and reopen the run from Recent analyses or from the Library.

Reading the Results#

The preview panel#

On the left: the URL chip with the site's favicon, the device segment, Reload and Add. Inside the frame, a dimension readout shows the exact viewport and the scale, for example 390 x 844 62%. The scale is only how much the frame is shrunk to fit your screen — the page itself is rendering at the full device width, so its media queries behave exactly as they would on the device.

Two fallback states can appear in place of the preview:

• No preview loaded yet — "Enter a website address and run an analysis to see it previewed here across Desktop, Tablet, and Mobile." with Open the site in a new tab. This is the state before anything has run.
• The lost state — "This website can't be shown in the preview. It navigated away or blocks iframe embedding. Open it in a new tab to continue." with Open in new tab and Return to preview. This appears when the site redirects itself out of the frame, which some sites do on small viewports. The analysis is unaffected; only the visual preview is.

The score ring and verdict#

The report opens with a 0–100 ring, a short verdict phrase, and a two to three sentence summary. The score bands the model is asked to work to:

The summary is worth reading in full. It is where the model says what it could and could not see — for example that only inline CSS was available, which changes how much weight to give a "no breakpoints found" finding.

Critical issues, Medium priority and Suggestions#

Three sections, each with a count badge, and up to three findings each. The severity split is the model's judgement of user impact, not a machine grade.

• Critical issues are things that break the page for real users on a real device: a missing viewport meta tag, a container with a hard-coded width wider than a phone screen, content that will overflow horizontally.
• Medium priority are things that degrade the experience without breaking it: font sizes below comfortable reading size, breakpoints that leave a gap between layouts, tap targets that are probably too small.
• Suggestions are improvements rather than defects.

Inside a finding#

Every finding carries the same five parts, in the same order:

The Where to change it line is the part that saves the most time, and the part to sanity-check first. It points at the served file; if your build compiles from elsewhere, translate it to the source before editing.

Some findings have no snippet. That is intentional — the model is told to leave it empty rather than invent code where no code change applies.

If nothing was found, the report says "No specific issues were returned for this page." On a small, simple page that is a legitimate answer, not a failure.

Ask Claude about this site#

The chat panel sits above the report on purpose: the recommendations can be long, and burying the question box under them made it hard to reach.

It opens with "Ask me anything about this site. I can explain an issue, write the CSS to fix it, or suggest better breakpoints." The four suggestion chips disappear once you send your first message. Replies come back as plain text with real code blocks, and the conversation is stored with the analysis, so reopening the run from Recent analyses brings the thread back with it.

The chat sees the analysis it already produced for this URL and the last ten messages of your conversation. It does not re-fetch the page, so if you deploy a fix mid-conversation, run a fresh analysis rather than asking whether it worked.

Recent analyses#

Below the entry form, up to nine past runs, each with the site favicon, its title, its URL and its score. Selecting one restores the whole workspace: the preview, the report and the conversation.

Every run is also mirrored into your Library at zero credits, where you can reopen it alongside your other work. Choosing Run fresh on a saved responsiveness run brings you back to this screen and re-submits the URL. See Saved Work.

Examples#

Screenshots#

Tips#

• Analyze the template, not the homepage. A pricing table, a product page and an article template each fail differently.
• Switch to Mobile before reading the report. Seeing the fault and reading the finding together is much faster than either alone.
• Use Reload after you deploy a change to refresh the preview, then run a new analysis to refresh the findings — the preview and the report update separately.
• Ask the chat to restate a fix in your stack: "give me that as Tailwind classes", or "as a styled-component".
• If the site navigates itself out of the frame, use Open in new tab and keep reading the report; the analysis does not depend on the preview.

Best Practices#

• Declare a viewport meta tag on every page. Its absence is the single most damaging finding this tool reports.
• Prefer max-width and intrinsic sizing over fixed pixel widths on containers.
• Keep body text at a comfortable size on mobile rather than scaling everything down at a breakpoint.
• Serve your critical CSS so it is readable in the response. Styles injected by JavaScript are invisible to this analysis, and to some crawlers.
• Re-run after each fix. The score is most useful as a before-and-after pair.
• Pair it with PageSpeed & Vitals on the same URL: this tool covers layout and usability, that one covers loading performance.

Common Mistakes#

• Judging the site by the scaled preview. The percentage in the dimension readout is display shrinkage only. The page is rendering at the real width.
• Treating a finding as verified visual fact. The model is explicitly working from HTML and CSS, not pixels, which is why findings are phrased as "likely" or "check". Confirm in the preview before you file the ticket.
• Analyzing a JavaScript-rendered app and expecting depth. No JavaScript is executed, so a page whose content is assembled client-side offers very little to read.
• Editing the file named in "Where to change it" without checking the source. It names the file as served, which may be compiled output.
• Asking the chat whether a deployed fix worked. It is answering from the analysis it already produced. Run a fresh analysis instead.

Limitations#

• No screenshot and no rendered pixels. Findings are inferred from markup and stylesheets.
• JavaScript is not executed. Client-side rendered content is not seen.
• At most two external stylesheets are fetched. When they are not available the analysis is working from inline CSS only, and the summary says so.
• At most three findings are returned in each of critical, medium and suggestions. This is a prioritized list, not an exhaustive audit.
• The AI pass has a 40-second budget; a very slow site can exhaust it.
• Some sites navigate themselves out of the preview frame. The report is unaffected.
• This screen does not use the shared result shell, so it has no export buttons, no category tabs and no Get recommendations panel. Use the Library to keep a run.
• It reviews one URL per run. There is no site-wide crawl.

Troubleshooting#

FAQs#

Does this cost credits? No. It is free on every plan, it does not touch your monthly allowance, and it does not consume the hourly light-tool ceiling. Runs are saved to your Library at zero cost.

How is this different from resizing my browser? Resizing only re-triggers CSS media queries. Server-rendered markup, JavaScript-driven layout, lazy-loaded images and viewport-dependent scripts all keep the desktop output. This tool reloads the page at the target width, so all of those behave as they would on the device.

Can it see my staging site? Only if it is publicly reachable. Anything behind a login, a VPN or an IP allowlist cannot be fetched.

Why does it say "likely" instead of telling me something is broken? Because it is reading HTML and CSS rather than looking at the page. It is instructed never to state a visual defect as fact when it can only be inferred, and to treat absent evidence as unknown rather than as a fault. That constraint is what makes the findings it does assert worth trusting.

Can I get a PDF of the report? Not from this screen — it does not carry the shared export row. Reopen the run from the Library, or copy the findings into a ticket. The full conversation is stored with the analysis, so nothing is lost by leaving it there.

Does it check WCAG conformance? No. Accessibility is one of the lenses the review uses, and it will flag things like heading structure and small tap targets, but it is not a conformance audit and should not be quoted as one.