After ten years of running digitalpixelweb.com on WordPress, we rebuilt it on Next.js in early 2026. This post is a candid account of why we made the switch, what we traded off, and what the results look like.
Why WordPress wasn't working anymore
Our old site was a standard WordPress build. Elementor for the page builder, a handful of plugins for contact forms and SEO, shared hosting. It worked fine for years. So why change?
Three reasons:
1. Performance ceiling. Even with caching, our mobile PageSpeed scores topped out in the mid-60s. For a company selling web development, that was embarrassing. WordPress's server-side rendering model plus plugin bloat made meaningful improvement hard without a complete architecture change.
2. SEO plate spinning. Keeping Yoast configured, managing Open Graph images, maintaining structured data. Every plugin update risked breaking something. We wanted SEO baked into the code, not bolted onto it.
3. We needed to practice what we preach. We build modern web applications for clients. Our own site lagging two generations behind sent the wrong signal.
What the new stack looks like
- Next.js 16 with the App Router for routing and server components
- Tailwind CSS v4 for styling (fast, consistent, no runtime cost)
- Static generation for every page. The site is essentially 30+ pre-rendered HTML files served from Vercel's edge
- Poppins font via
next/font/googlefor brand-aligned typography - Resend + Cloudflare Turnstile for the contact form
- Vercel for hosting and deployment
The entire codebase is on GitHub. You can read the source if you're curious.
The trade-offs
Learning curve. If you're coming from WordPress, the Next.js App Router has a different mental model. Server Components, file-based routing, and static generation all require new patterns. For a developer who's already comfortable with React, the ramp-up is quick. For someone coming from PHP/WordPress cold, it's a real shift.
Content editing. This is the biggest trade-off. WordPress has a world-class admin UI for non-technical users. Next.js does not. We solved this by using MDX files stored in the repo. Every blog post is a git-tracked Markdown file. That works great for a single author but would be a non-starter for a marketing team of ten.
The results
Desktop PageSpeed: 100 / 92 / 100 / 100 across Performance, Accessibility, Best Practices, and SEO.
Mobile PageSpeed: 69-72 on Performance, 92 Accessibility. Mobile tests against a throttled low-end Moto G Power are intentionally harsh. Real-world mobile performance is significantly better.
Page load time in the footer of every page shows real-time measurements, typically 100-250ms for return visitors thanks to edge caching.
Would we do it again?
Yes, but with caveats. Next.js + Vercel is excellent for:
- Marketing sites with occasional content updates
- Portfolio and agency sites
- Sites where performance and SEO matter
- Sites maintained by developers
It's overkill for:
- Sites maintained by non-technical content teams
- Small brochure sites where WordPress + a good theme is fine
- E-commerce sites (use Shopify, not Next.js, for most cases)
If you're considering a similar migration, the honest answer is: it depends on who's editing the content. If it's developers, go Next.js. If it's marketing staff, stick with WordPress or move to a headless CMS like Sanity or Contentful feeding a Next.js frontend. That's the best of both worlds, though at more complexity.
What's next
We're documenting the journey in this blog. Expect upcoming posts on:
- The exact PageSpeed optimization playbook that got us to 100 desktop
- How we structured the sitemap and JSON-LD for rich search results
- The performance and tooling playbook for a production-grade Next.js site
If you're considering a similar rebuild, we'd love to talk. Get in touch.