What I found when I rebuilt my own website
By Craig Burdett, , 3 minute read
I spend a lot of time telling people what’s wrong with their websites. So I finally did the same review on mine, and it wasn’t pretty.
My site had grown the way most small sites do, with a page added here, a theme swapped there, and a new homepage tried out without the old one ever going away. Everything looked fine in a browser. Underneath, it was a different story.
A whole framework for one page
One of my homepages was a headline and a contact form. To show it, the browser downloaded the complete Bootstrap 3 stylesheet (113 KB) and a 32 KB theme stylesheet, then jQuery and Bootstrap’s JavaScript on top. Almost none of it was used.
The rebuilt stylesheet is under 11 KB, and it covers the portfolio and all 27 project pages as well as that homepage.
A form that complained on every keystroke
The contact form called a validation function every time someone typed a letter. That function lived in a script the page never loaded, so every keystroke threw an error in the background. The form still sent, but only because the browser shrugged and carried on.
A script that crashed on its first line
My newer homepage had a script for switching between light and dark mode. It looked for a toggle button that wasn’t on the page, failed immediately, and took the rest of the script down with it, including the code meant to handle the contact form. Nobody noticed, because the form fell back to working without it.
The spam trap on the same form sat just outside the form’s closing tag, so it was never sent with the form, which meant it never caught anything.
Fourteen scripts for a filterable grid
The portfolio page loaded jQuery, thirteen more scripts and eight stylesheets just to filter the grid by type of work and show a bigger version of an image when you clicked it. The rebuild does both with about forty lines of plain JavaScript and the browser’s built-in dialog element.
The difference shows. I tested a copy of the old portfolio page against the new Work page with Catchpoint’s WebPageTest, under the same conditions. The main content now appears in about a second instead of four, and the page weighs less than a tenth of what it did.
| Measure | Old portfolio | New Work page |
|---|---|---|
| Largest Contentful Paint | 4.03 s | 1.03 s |
| Speed Index | 3.73 s | 1.01 s |
| Fully loaded | 4.17 s | 1.39 s |
| Page weight | 1.8 MB | 178 KB |
| Requests | 90 | 16 |
| Render-blocking requests | 9 | 0 |
| Lighthouse Performance | 85 | 100 |
| Lighthouse Accessibility | 80 | 100 |
Three test runs per page on November 3, 2026, using desktop Chrome on a cable connection from Dulles, Virginia. The figures are from each page’s median run by Speed Index.
A heading nobody could see
My terms and conditions page had a white heading on a white background. The style rule that should have given it a dark banner didn’t exist. Search engines could read the heading, but people couldn’t.
Small things that add up
- My email address was hidden from spam bots with made-up HTML tags. Browsers coped, but it wasn’t valid HTML.
- The app manifest pointed at an icon file that wasn’t there.
- Some links to client sites had no protocol, and some pages hard-coded a copyright year that had already gone out of date.
What I took from it
None of these problems showed up when I looked at the site normally. Every one was invisible until I opened the code, the browser console and the network panel. That’s exactly why I offer reviews, because it’s hard to see your own site the way a browser, or Google, sees it.
If you’d like a second pair of eyes on yours, send me the address. It’s free.