So there’s this client site. WordPress, obviously. Slow as shit.
I mean really slow. Like watching paint dry slow. Customers are bailing during checkout because it takes 8+ seconds to process anything.
Started with the usual suspects – optimized images, cleaned out plugins, tried a different host. The works.
Still garbage.
Dave won’t shut up about headless WordPress. I keep telling him it’s overengineered nonsense. Why make WordPress more complicated when regular WordPress is already broken?
But I’m running out of ideas here.
WordPress Does This Dumb Thing
Every single page request makes WordPress rebuild everything from scratch. Database hits, PHP processing, the whole nine yards. Just to show someone a product price.
Like if you had to disassemble and rebuild your car every time you wanted to drive to the store. Makes no sense.
I used to think caching was the magic bullet. It’s not. You’re still doing unnecessary work, just storing the results.
Tried REST API First
Made sense to me. Keep WordPress for the backend stuff, build something faster for the frontend using REST API.
Except REST API sucks for this. Homepage with 10 blog posts? That’s like 40+ separate API calls. Posts, authors, images, categories, tags… it goes on forever.
Might as well stick with regular WordPress at that point.
GraphQL is… Different
GraphQL supposedly lets you ask for everything at once. One request instead of 40.
Sounds great in theory. In practice, the documentation is terrible. Full of examples that work fine until you try to use them on actual websites with real data.
Got the WPGraphQL plugin working eventually:
wp plugin install wp-graphql –activate
wp plugin install wp-graphql-acf –activate
Setting up auth was a nightmare. JWT tokens, rate limiting, preventing people from writing queries that kill your server. Fun stuff nobody tells you about.
My first GraphQL query looked innocent enough:
{
posts {
title
author {
name
}
}
}
Completely tanked the database. Turns out it runs separate queries for each author. Brilliant.
This version works better:
{
posts {
nodes {
title
author {
node {
name
}
}
}
}
}
The “nodes” syntax is confusing as hell but apparently WPGraphQL needs it to batch queries properly. Took me way too long to figure this out.
Query Monitor plugin was the only way I could see what was actually happening in the database. Essential tool.
Next.js Because Internet Says So
Went with Next.js for the frontend. Not sure it’s the best option but everyone recommends it.
export async function getStaticProps() {
const { data } = await client.query({
query: GET_POSTS_WITH_AUTHORS,
variables: { first: 10 }
});
return {
props: { posts: data.posts.nodes },
revalidate: 900
};
}
This rebuilds pages every 15 minutes. Seems fine? I honestly don’t know if that’s too often or not often enough.
Results Were Mixed
Good news: checkout went from 8 seconds to under 2 seconds. Client stopped getting complaint emails.
Bad news: broke a bunch of other stuff. Search was down for a week. SEO took a hit because Google couldn’t crawl properly. Had to fiddle with server-side rendering settings.
Client’s team hated the new workflow. They could edit content in WordPress but couldn’t preview changes easily. Spent weeks setting up staging environments and retraining everyone.
Did another project after this – big publishing site. Cut requests from 43 to 1 per page. Way faster, especially mobile.
But optimizing for GraphQL made regular WordPress admin sluggish. Database was tuned for the wrong queries. Still haven’t figured out the perfect balance.
Mobile app project was easier though. Same endpoint serves web and app. Cleaner than maintaining separate APIs.
Should You Do This?
Probably not.
If your WordPress site is already fast enough, don’t mess with it. This adds complexity and costs more money.
If you’re losing actual sales to slow performance, maybe consider it.
If your team doesn’t know JavaScript, definitely skip it. You’ll need ongoing maintenance.
Page builder users should stay away. Most of that functionality won’t work headless.
Reality Check
Projects take twice as long as you think. Need developers who know WordPress AND JavaScript. Hosting gets more expensive.
More security patches, more things breaking, more late-night troubleshooting calls.
Only worth it if speed actually matters for your business.
Two Years Later
Original client is still running headless. Performance is good, no major issues.
But I’ve talked other clients out of it when they didn’t need the complexity.
Most WordPress speed problems can be fixed easier ways. Better hosting, good caching, image optimization. Try simple stuff first.
Headless only makes sense for specific use cases – e-commerce where speed kills sales, mobile apps, complex frontend requirements.
It’s messier than the tutorials suggest.
