I built DHSea Score, so the obvious first test was to point it at the site that hosts it. The first report said 86, a B. The second said 97, an A+. This post is about what changed between them, what did not, and why I left one low grade exactly where it was.
The first report: a B with one red box
The first sheet graded dhseadev.online at 86 (B), counting 44 of the 51 checks. Four of the five categories were already at the top: SEO 100, Accessibility 100, Best practices 100. The red box was Security at 59 (F). The report named the cause in its top fixes: no Content-Security-Policy header, no clickjacking protection, and an HTML document of 207 KB against a 200 KB limit.
It also scored Delight, the estimate I added to say how a page tends to feel on first load, at 54 out of 100, labelled Neutral. The tool does not hide that number from its own author, and I did not want it to.
The fix: four headers and no page edits
Security was a server-side gap, not a content gap, so the repair belonged on the server side too. I wrote a very small WordPress plugin that adds four response headers on public pages: nosniff, a Referrer-Policy, a Permissions-Policy, and a Content-Security-Policy limited to framing, the base tag and plugin objects. It touches no page content, and deactivating it removes every header at once.
Before trusting the second grade, I read the headers off the live site myself, logged out, with the cache bypassed, on seven different pages. All four were present on every one of them. Only then did I regrade.
The second report: an A+, and what it does not prove
The second sheet says 97 (A+). Security went from 59 to 100, with the same 44 of 51 checks counted. SEO, Accessibility and Best practices stayed at 100.
I owe you the caveat. The policy I added passes the grader because a policy exists and blocks framing by other sites. It does not restrict which scripts may run, and on this site it cannot, because my pages carry their code inline. A strict policy would break them. So the A+ means the headers are present and correct for what they cover. It does not mean the site is hard to attack, and a tool that grades its own author should say so.
The C- I left alone
Speed (server-side proxies) is 70 (C-) on both sheets, unchanged. The server answered in 54 ms, so the slowness is not the server. Two checks fail: the HTML document is 207 KB against a limit of 200 KB, and the inline script and style total 161 KB against a limit of 100 KB.
Both numbers trace back to the same design choice: each page on this site is one self-contained block of markup, styles and script. Moving that code into separate cacheable files would pass both checks. It would also mean reworking every page that depends on it, to raise a category that carries 10 percent of the overall score. I decided that was a bad trade today, and I would rather show you a real C- than a quiet rewrite. It stays on the list.
What two sheets taught me
- A grade is a to-do list. The top fixes on the first sheet were the whole plan.
- The cheapest fix was the one that changed no content, so nothing visible could break.
- Verify the cause on the live site before you regrade, not after.
- Name the limits of your own score next to the score.
- Leave a low number visible when fixing it costs more than it is worth.
If you want your own sheet, grade a page and start with the top fixes. The project page explains what each category checks, and the first post explains why the tool is built to encourage rather than shame. More notes are on Updates and Projects.