We ran our free audit on our own site first

The first site our free audit looked at was ours. Partly because a tool should be tested where you already know the answers. Partly because offering to find other people’s problems while ignoring your own is not a good look.

It found two kinds of problems on evdevs.com. Neither would show up in a demo, and both affect everyone who visits on a phone. After the fixes, the audit found nothing, and the site got noticeably faster.

Finding 1: files that held up the page

When a browser opens a page, some files must arrive before it will show anything. These are called render-blocking files: like a shop that won’t open its doors until every delivery for the day has arrived. On our site, two things were in that queue:

• The fonts. They came from Google Fonts, which meant the browser first had to connect to another company’s servers, fetch a stylesheet, and only then fetch the fonts themselves.
• Our main script. The browser stopped to load it before drawing the page, although nothing it does is needed for the first view.

The fixes were small. We now serve the fonts from our own site, and tell the browser up front to fetch the two that appear at the top of the page (that is called preloading). The script is now deferred: the browser draws the page first and runs the script right after.

Finding 2: missing security headers

Headers are short instructions a server sends with every page. Three basic ones were missing:

• X-Content-Type-Options stops the browser from guessing what a file is, so a file can’t be passed off as something else.
• Referrer-Policy controls how much of the address of the page someone came from is passed on to other sites.
• X-Frame-Options stops other sites from showing your pages inside theirs, a trick used to make people click things they didn’t mean to.

None of them is dramatic on its own. Together they are basic hygiene, and their absence is something a careful buyer’s technical person may notice. They are now three lines of configuration, applied to every page.

The result

We ran the audit again after deploying: zero findings. Google Lighthouse, the same test the audit runs, now reports:

• Mobile performance: from 72 to 81–87. It is a range because the test simulates a mid-range phone on a slow connection, and repeated runs vary by a few points. We give the range rather than the best run.
• First contentful paint on mobile: from 4.4 s to 1.7 s. That is the moment a visitor first sees something on the screen instead of a blank page. It came in at less than half the time.
• Desktop performance: 97.
• Accessibility, best practices and SEO: 100.

The first paint matters most. A visitor who sees a blank screen for four seconds on a phone often leaves before the page appears, and no copy or offer can work on someone who has gone.

Why we started with ourselves

Testing on your own site is testing against a known answer. We knew what was on our pages, so we could tell whether each finding was real, and whether the fix made it go away. It is the same discipline we use before a client sees any warning from a system we build: check it against a known answer first.

It also kept us honest about the report itself. Reading a finding about your own site shows quickly whether the wording is clear, whether the evidence is enough to check it, and whether the first step to fix it actually works. Here it did: each finding pointed straight at its fix.

The audit that found these is the one we now offer for free, built automatically and approved by an engineer before it goes out. Here is how it works, and here is what it can see from the outside.

Get a free audit

Or see what the free audit checks.