The EmDash Speed Test: A Plot Twist Where WordPress Actually Wins

In my last post, I talked about setting up EmDash and Astro to chase that “insane speed” we all want for our websites. The architecture is lightweight, it ships zero JavaScript by default, and in theory, it should blow a traditional CMS out of the water.

Well, I ran the numbers. And consider me humbled.

I fired up GTmetrix to do a side-by-side comparison of my actual WordPress site (aaronreimann.com) versus the new EmDash clone I built. Keep in mind, my WordPress site is currently just sitting on a free tier WP Engine account.

Here is the plot twist: WordPress won. My WP Engine setup pulled an ‘A’ grade (96% performance) with a Largest Contentful Paint (LCP) of just 939 milliseconds. The lean, mean EmDash machine? It got a ‘B’ grade (81%) with an LCP of 1.8 seconds.

At first, I was scratching my head. How does a static-first, modern architecture lose to my trusty old WordPress setup? Then I looked at the page weight.

The WordPress page was a totally reasonable 1.95MB. The EmDash page was a massive 6.20MB.

Why is the EmDash site so heavy? Here is the frustrating part: it is actually supposed to handle this perfectly. When you pair a modern tool like Astro with an edge network like Cloudflare (which EmDash is built to leverage), it is supposed to dynamically generate the perfect image size, compress it, and serve it in a next-gen format like WebP on the fly.

So, what am I doing wrong?

Honestly, I’m still figuring it out. When you use WordPress, especially on a managed host like WP Engine, it does all this heavy lifting invisibly. You just upload a picture and it works. With this decoupled architecture, I clearly missed a configuration step. I might not be passing the right properties to Astro’s built-in image component to handle remote images from the EmDash database, or maybe I just need to flip a specific switch inside my Cloudflare account to enable the edge image resizing.

You can actually see the architectural difference in the number of requests. The WordPress site had 112 requests to load the page. The EmDash site only had 34. The new framework is incredibly lean structurally, but serving a 6-megabyte payload of raw images completely negated that advantage.

It is a great reminder that moving to a blazing-fast modern framework is awesome, but it means you are now responsible for learning a new set of rules and engineering things you used to take for granted.

I am definitely not giving up on this experiment. The next step is to hit the documentation, figure out what I broke in the image optimization pipeline, and run these tests again. Once those images are properly sized, I fully expect this setup to absolutely fly. I’ll keep you posted!