The WordPress Default
WordPress became the default choice for websites. Easy to understand why:
- Massive plugin ecosystem
- Thousands of themes
- No coding required
- Familiar to clients and developers
- Powers major sites
For years, this made sense. The alternatives were worse.
That changed.
The Problems Compound
Performance ceiling:
WordPress sites load slowly. Not because WordPress is inherently slow, but because the architecture creates performance problems:
- PHP generates every page on every request
- Database queries on every page load
- Plugins inject unnecessary JavaScript
- Themes include bloat for features you don't use
Optimization helps. Caching plugins, CDNs, image optimization. But you're fighting the platform's default behavior.
Modern alternatives start fast, not optimized to acceptable speed.
Security maintenance:
WordPress core updates monthly. Plugin updates weekly. Theme updates sporadically.
Miss an update, get hacked. This isn't theoretical. Automated bots scan for outdated WordPress sites constantly.
Pattern: Client launches site. Maintenance plan ends. Updates stop. Site gets compromised six months later.
WordPress security requires active maintenance. Many site owners don't maintain actively.
Plugin dependency:
Need a contact form? Plugin. SEO optimization? Plugin. Caching? Plugin. Image optimization? Plugin. Security hardening? Plugin.
Each plugin adds:
- Potential security vulnerability
- Code that may conflict with other plugins
- Performance impact
- Maintenance burden
Sites accumulate 20-30 plugins easily. Each one is a potential failure point.
Editor limitations:
Gutenberg (block editor) improved the old editor significantly. Still limitations:
- Custom blocks require development
- Fine-grained control requires custom CSS
- Design flexibility limited by theme
- Mobile preview inaccurate
Modern page builders (Elementor, Divi) add more flexibility but multiply the performance and maintenance problems.
Hosting complexity:
WordPress requires:
- PHP environment
- MySQL database
- Regular backups
- Security monitoring
- Update management
This costs more and breaks more than static hosting.
What Changed
Static site generators matured. They deliver advantages WordPress can't match:
Performance:
Static HTML files load instantly. No server processing. No database queries. No PHP execution time.
Typical results:
- WordPress site: 2-4 second load
- Static site: 0.3-0.8 second load
That difference determines bounce rate.
Security:
No server-side code means no server-side vulnerabilities. No database to compromise. No PHP exploits to patch.
Attack surface shrinks to basically zero.
Hosting cost:
Static files host anywhere. Services like Netlify, Vercel, Cloudflare Pages offer:
- Free hosting for most sites
- Global CDN included
- Automatic SSL
- One-command deploys
WordPress hosting: $10-50/month minimum for decent performance.
Developer experience:
Modern frameworks use modern tools. TypeScript, component architecture, hot reload, proper build systems.
WordPress development feels dated because it is. PHP patterns from 2003.
The Alternatives
Astro (my current choice):
Best for content-focused sites. Blogs, marketing sites, documentation.
Advantages:
- Ships zero JavaScript by default
- Fastest static generator available
- Component syntax from modern frameworks
- Bring your own framework (React, Vue, Svelte)
- Excellent documentation
Trade-offs:
- No admin interface out of the box
- Requires developer for updates (or CMS integration)
Typical use: Marketing sites, blogs, documentation sites.
Next.js:
Best for web applications with dynamic features.
Advantages:
- React ecosystem
- Static generation + server rendering
- API routes built-in
- Large community
- Excellent performance (learn more in our web development guide)
Trade-offs:
- More complex than Astro
- React knowledge required
- Can be overkill for simple sites
Typical use: SaaS platforms, e-commerce, complex web apps.
Hugo:
Best for very large sites (thousands of pages).
Advantages:
- Extremely fast build times
- Handles massive sites easily
- Single binary, no dependencies
- Mature and stable
Trade-offs:
- Go templating less intuitive
- Smaller community than JS frameworks
- Fewer integrations
Typical use: Documentation sites, large blogs, enterprise content.
11ty (Eleventy):
Best for developers who want flexibility.
Advantages:
- Use any templating language
- Minimal JavaScript
- Extremely flexible
- Small and focused
Trade-offs:
- Less opinionated (more decisions required)
- Smaller ecosystem than Next/Astro
Typical use: Blogs, portfolios, agencies building client sites.
When WordPress Still Makes Sense
WordPress isn't wrong for everyone:
Multiple non-technical editors:
If five people need to update content regularly without developer help, WordPress makes sense.
Modern frameworks require either:
- Developer involvement for changes
- CMS integration (adds complexity)
- Git-based CMS (learning curve)
Existing WordPress ecosystem investment:
If team knows WordPress deeply, uses WordPress for 50 sites, has optimized workflows, switching has high cost.
Specific plugin requirements:
Some WordPress plugins have no equivalent elsewhere. WooCommerce for e-commerce, specific membership plugins, certain integrations.
Client expectations:
Some clients insist on WordPress because they know it. Fighting this fight sometimes isn't worth the energy.
Migration Approach
Moving existing WordPress sites requires planning:
Step 1: Export content
WordPress exports to XML. Tools exist to convert to Markdown for static generators.
Content structure typically transfers cleanly. Custom features require rebuilding.
Step 2: Recreate design
Static frameworks use components, not themes. This means rebuilding design from scratch or converting theme.
Budget 20-40 hours for typical site redesign.
Step 3: Handle dynamic features
Comments, forms, search require third-party services:
- Comments: Disqus, Commento, utterances
- Forms: Netlify Forms, Formspree
- Search: Algolia, Pagefind
These typically work better than WordPress equivalents.
Step 4: Redirect URLs
Maintain URL structure when possible. When not possible, implement redirects.
SEO depends on preserving link equity.
Step 5: Deploy and monitor
First deployment typically reveals edge cases. Monitor closely for first week.
The Content Management Question
"But clients need to edit content without developers."
Three approaches:
Approach 1: Headless CMS
Sanity, Contentful, Strapi provide admin interfaces. Publish triggers rebuild.
Pros: Familiar editing experience. Cons: Additional cost and complexity.
Approach 2: Git-based CMS
Netlify CMS, Decap CMS edit files in Git repository.
Pros: No additional infrastructure. Cons: Learning curve for editors.
Approach 3: Direct file editing
For technical clients, editing Markdown files directly works fine.
Pros: Simple, no additional tools. Cons: Requires technical comfort.
Most clients edit content less frequently than they think. Many sites see content updates monthly, not daily. Developer involvement becomes acceptable.
Cost Comparison
WordPress (typical setup):
- Hosting: $25/month
- Premium theme: $60/year
- Essential plugins: $100/year
- Maintenance: 2 hours/month at $100/hour
Annual total: ~$2,760
Static site (typical setup):
- Hosting: $0-20/month
- Development time: Front-loaded
- Maintenance: 1 hour/quarter
Annual total: ~$400-640
The difference funds development time for static approach.
Performance Impact
Real examples from sites migrated:
Case 1: Marketing site
- Before: 3.2s load, PageSpeed score 62
- After: 0.6s load, PageSpeed score 98
- Result: 23% increase in conversions
Case 2: Blog
- Before: 2.8s load, 45 HTTP requests
- After: 0.4s load, 12 HTTP requests
- Result: 40% decrease in bounce rate
Case 3: Documentation
- Before: 4.1s load on 3G
- After: 1.2s load on 3G
- Result: Support ticket reduction (better docs access)
Pattern: Load times drop 70-85%. Website conversion rates improve proportionally when pages load faster.
Developer Productivity
Building with modern frameworks feels different:
- Hot reload shows changes instantly
- TypeScript catches errors before runtime
- Component architecture prevents duplication
- Git workflow enables collaboration
- Automated testing actually works
WordPress development involves fighting PHP, wrestling with plugin conflicts, debugging mysterious database issues.
Modern development focuses on building features, not fighting platform.
The Transition Period
Switching technology stacks creates short-term friction:
- Team learns new tools
- Existing knowledge feels less valuable
- Initial projects take longer
- Uncertainty about decisions
This discomfort passes. Within 2-3 projects, new approach feels natural.
Within 6 months, returning to WordPress feels restrictive.
What I Actually Use
Current stack:
- Astro for most projects
- Next.js for complex applications
- Sanity CMS when clients need content management
- Netlify or Vercel for hosting
- Cloudflare for DNS and CDN
This handles 95% of use cases WordPress previously filled.
Remaining 5%: Specific requirements that WordPress truly handles better. These get WordPress.
The Core Question
"Does this project actually need WordPress?"
For most sites, the answer is no.
Blogs, marketing sites, portfolios, documentation, small business sites—these work better as static sites.
WordPress made sense when alternatives were worse. That era ended.
Modern tools deliver better performance, security, developer experience, and lower cost.
The WordPress default should be the WordPress exception.
Ready to Build a High-Performance Website?
I build fast, modern websites that convert visitors into customers. No bloated WordPress, just clean code optimized for performance and SEO.
Get Free Website Performance Audit