We rebuilt our own site on Laravel. Here are the numbers

There is an old joke about the builder whose own house has a leaking roof. For a few months, our own website was heavier than several of the ones we were being paid to fix. This is the honest version of what we changed, and what the numbers did.

The starting position

The site runs on Laravel with a custom admin panel rather than a general-purpose CMS. That was a deliberate choice: the content here is structured (services, projects, posts, settings) and every page is assembled from that data, so we wanted the models to be ours, not a plugin's.

Two things were badly wrong. First, the case-study images were full-page captures stored as PNG. Full-page captures of a long scrolling site are enormous, and ours reached around 12,000 pixels tall. Second, both www. and the bare domain served the full site with a self-referencing canonical, which is a polite way of asking Google to index two copies of everything.

What we changed

• Converted every project image to WebP, capped at 1,400 pixels wide, quality 85, metadata stripped, and updated the stored record to point at the new file.
• Kept the originals in a backup outside the web root, then deleted the dead PNGs so they could not be served or recrawled.
• Added a 301 from www. to the bare domain, and from HTTP to HTTPS, before the application even boots.
• Cleared the framework caches and purged the CDN, because a fixed file behind a stale edge cache looks exactly like an unfixed file.

The numbers after

• Total image weight in the project gallery: about 22MB down to 1.6MB.
• Homepage image payload: roughly 15MB down to 1.63MB.
• Server response time, measured repeatedly from a cold client: around 265ms.
• All 44 sitemap URLs still returning 200, with no template changes.

The double-domain problem is the one worth dwelling on. A 301 is a one-line change and it took two minutes. The cost of leaving it is months of split signals that no amount of content will fix.

Why we did not just move to WordPress

For a content-led marketing site, WordPress is a perfectly sane answer, and we use it for clients. But we wanted per-page schema, fine-grained control over image derivative sizes, and an admin flow shaped exactly like our work: a project is a record with a client, a stack, outcomes and one hero capture. In Laravel that is a migration and a form. In a general CMS it is a plugin stack, three custom fields and a maintenance burden.

The right platform is the one whose data model matches the shape of what you actually publish.

The lesson we now apply to client work

Performance is a content problem before it is a code problem. Nobody needs a 1920-pixel-wide screenshot of a scrolling page. They need a sharp, fast, correct image at the size it is displayed. Fix that first, measure second, and only then start talking about caching layers and edge networks. Most sites we audit never get past stage one.