Lighthouse: the audit a new build should pass first

The audit belongs before launch.

An owner sits at a laptop with a new site open, ready to approve it. The home page looks sharp, the colors are right, and the approve button is one click away.

Before that click, ask the builder to run the Lighthouse audit and show you the report, then to check the pages at phone size. A site is ready once it has passed both.

A laptop approval proves one screen

A site that looks right on your laptop has passed one test, on one screen, in one browser. Picture a customer on a small phone, one hand free, standing in a driveway. We wrote about this in test your site on phones before it ships: a site approved on a laptop should also be tested at phone sizes in more than one real browser engine before launch.

Same page, three screens

• Looks right on the laptop.
• Looks right on your phone.
• On a customer's small phone, the call button is gone.
• Your Business: Laptop approved: Looks right
• Your Business: Your phone: Looks right
• Your Business: A customer's small phone: Call button hidden

The call button can sit fine on the big screen, then hide under a bar that follows the scroll on a small phone, and the customer dials the next business on the list. The laptop check was honest, and it covered one size. That is the gap a pre-launch check closes.

Two checks, two jobs

The Lighthouse audit and the phone check answer different questions. The audit report names the pages it ran on. The phone check names the screen sizes and the browser engines. A good launch has both, and the builder shows you the proof of each before the site goes live, because a check run after launch is a post-mortem. We use Lighthouse for local performance audits before anything ships.

In our routine the audit gates the launch. Two other tools watch what happens after. We use Google Search Console for indexing and query data, checked on a regular cadence. We use Microsoft Clarity for session recordings and heatmaps that spot real friction on a page.

A clean report can sit beside a wrong detail somewhere else, because a passing audit says nothing about the parts of the site it never opens. We wrote about another thing that looks fine and is not, in our sitemap post: a sitemap where every page shows the same last-changed date usually means the build cannot read git history at deploy time. Open the real page on a real phone as well.

An example launch routine

1. Build passes
2. Phone check
3. Audit report
4. Owner sign-off
5. Go live

Questions to ask before you approve a site

You do not need to read the report to hold a builder to it. Ask four plain questions: was the audit run, on what screen, in which browsers was the phone check, and what changed after it. A builder who did the work answers each in a sentence, and a vague answer tells you something too.

None of this needs a technical background. It needs the habit of asking before you approve.

Four questions for your builder

• Was the audit run?. A vague answer: We checked it, it was fine. A good answer: A report you can open, with the date it was run.
• What screen?. A vague answer: It looked good. A good answer: A named phone size, including a small one.
• Which browsers for the phone check?. A vague answer: Chrome, I think. A good answer: More than one real browser engine, named.
• What changed?. A vague answer: Nothing needed changing. A good answer: A short list of fixes, each page shown again after the fix.

We also like a second pair of eyes. A pre-mortem, run by someone with no stake in how the plan was built, catches framing errors before they survive into the plan, as we described in run a pre-mortem before you commit. Hand your site to a friend, on their own phone, and ask what they cannot find in ten seconds. Choose someone who has never seen the site and will say what they find. Do it before the launch, while a fix is still quick.

Who sees the site before launch

• designer: Checks on a new, large phone
• owner: Approves on the laptop
• customer: Opens it on a small phone in a driveway (The one nobody asked)

The designer and you each see the page on a device chosen for comfort. Sign-off by proof reaches the customer's screen too.

Sign-off by look

• Opened on one laptop
• Looks finished
• No report to read

Sign-off by proof

• Checked at phone size
• More than one browser engine
• A report you can read in a minute

Sign-off by proof takes a little longer than a glance, and the difference shows the first time a customer opens the site on a phone you never tested.

What a good report looks like

The audit report names the pages it ran on, and the phone check names the screen sizes and the browser engines. Together they should show each page, the size and the outcome, with any failure shown beside its fix. You should be able to read it in a minute. The sample below is invented to show the shape.

Example report

An invented example of the shape to look for.

A failure that got fixed is a good sign, because it means the check had teeth. Be wary of a report where nothing ever fails, and ask which browsers the phone check covered: a pass in one engine says little about another. The same goes for page coverage. A report that checked only the home page has checked one page of many, so ask for the page names. We wrote about why a warning that fires too often gets ignored in an alert that cries wolf.

When the report comes back, read two things: which pages and sizes were checked, and what was fixed. If the smallest phone size is missing, ask why. If a fix is listed, ask to see the page again after it. Five minutes of reading is a short check before launch. If the builder pushes back, that is useful information too. Keep the report. When the next builder or the next redesign comes along, it is your record of what passed.

Our view

A report is proof only when it says what was checked and what was fixed.

The rule we keep

Our rule is that the audit is a gate: the builder passes it and shows you the result before the site goes live. Our web design service runs local performance audits before anything ships.

Before you approve a site

• Ask which screen sizes the phone check covered.
• Ask for the audit report and the date it was run.
• Ask which browser engines were tested.
• Open the site on a small phone yourself.
• Ask to see each fixed page again.

Originally published at optymizer.com.

Want a second set of eyes on this for your business? Talk to Offer. Optymizer was founded in 2011, and I take the first call myself.

Human intelligence, assisted by AI. Offer has run digital marketing for 20 years. AI just helps him say it faster.