What you’ll learn:
- Why we built a proprietary WordPress starter theme (and what’s inside it)
- The build tools, PHP standards, and security patterns we use across every project
- Common mistakes we see in WordPress theme audits
- How we approach WooCommerce, animation, and WordPress core updates
Based on: 15+ years and 200+ WordPress projects
Custom WordPress theme development in 2026 shouldn’t look like it did in 2016. But most of the time, it does. jQuery for interactions. Gulp or Webpack for builds. PHP patterns that predate typed properties. Security treated as the server’s problem or a plugin’s concern.
We know because we’ve inherited enough of them.
Over the past 15 years, across 200+ projects, we’ve refined our approach to custom WordPress theme development into something we’re genuinely proud of: a proprietary starter theme we call Wordify. It’s not a commercial product. You can’t download it. It’s the engineering foundation we bring to every WordPress project we deliver, and it evolves with every major WordPress release.
This is how we approach modern WordPress theme development. Not a tutorial with code snippets you can copy and paste. More like a look under the hood at the decisions, trade-offs, and tools that make our WordPress work fast, secure, and maintainable.
Why We Built Our Own Starter Theme
There’s a reason we didn’t just pick a commercial theme and customize it. Or build on a framework like Sage or Underscores and call it a day. We needed something that follows WordPress patterns closely, because longevity matters. When a project needs to be maintained for five or ten years, the theme underneath it can’t depend on abstractions that might not survive the next major WordPress release.
Commercial themes carry technical debt from day one. They support features you don’t need, load assets you’ll never use, make assumptions about your project that rarely match reality, and update on a schedule you don’t control. Page builders add another layer of weight and lock-in. They’re convenient until you need to do something the builder didn’t anticipate. Then you’re fighting the tool instead of building your site.
A starter theme is different. It’s infrastructure you control. Every dependency is intentional. Every pattern exists because it solved a real problem on a real project, not because some marketplace required it for compatibility.
Wordify started as a blank theme we kept copying between projects. Over time, it accumulated our opinions about how WordPress should work when you’re building something serious. Those opinions hardened into architecture. Now it’s a genuine engineering platform that we maintain the way you’d maintain a product, with versioned releases, documented conventions, and a test suite.
We don’t use it because it’s ours. We use it because after 200+ projects, nothing else gives us the control and performance we need.
The Build System: Vite, Not Gulp
Here’s where most WordPress themes fall behind immediately.
The standard WordPress development workflow still revolves around Gulp task runners or Webpack configurations that take 30 seconds to compile. Some developers skip a build system entirely and ship raw CSS and JavaScript to production. Both approaches cost you: time in development, performance in production.
We use Vite 6. Have for the past two major versions.
If you haven’t worked with Vite, the difference is hard to overstate. Hot module replacement happens in milliseconds, not seconds. You change a SCSS variable, and the browser updates before your hand leaves the keyboard. You modify a JavaScript module, and only that module reloads. No full-page refresh. No waiting for a bundler to chew through your entire dependency tree.
Our build pipeline handles more than just CSS and JS. SCSS gets compiled through LightningCSS, which is significantly faster than PostCSS for the transforms we need. ES6 modules are tree-shaken and split for production. Images pass through an optimization pipeline (sharp for raster images, SVGO for vectors) that generates AVIF and WebP variants automatically.
Production builds are minified, cache-busted with content hashes, and stripped of dead code. Development builds? Sub-second feedback loops. That gap between “save” and “see the result” matters more than most people realize. It’s the difference between staying in flow and losing your train of thought entirely.
Why not Webpack? We used it for years. Vite is faster to configure, faster to build, and its dev server architecture (native ES modules in the browser) is fundamentally better suited to the iterative way we work. Webpack still has its place for complex application bundles. For custom WordPress theme development, Vite is the better tool.
Performance From the Ground Up
Performance isn’t something you bolt on after the theme is built. We learned that lesson early, and not always gracefully. It’s a constraint that shapes every decision from the start.
No jQuery. This is the simplest performance win in WordPress theme development, and it’s surprising how many themes in 2026 still ship with it. jQuery minified weighs around 87KB (roughly 30KB gzipped), and that’s before you add jQuery UI or any jQuery plugins. It’s an extra network request, parse cost, and execution overhead your visitors pay on every single page load. Our entire JavaScript layer uses vanilla ES6 modules. No jQuery. No jQuery UI. No jQuery plugins wrapped in compatibility shims.
Responsive images done right. Every image in our themes gets srcset and sizes attributes. We generate multiple sizes during the build process and serve AVIF where supported, WebP as fallback. Above-the-fold images get fetchpriority=”high” for faster LCP. Below-the-fold images get native lazy loading with blur-up placeholders that prevent layout shift.
Critical rendering path. We think carefully about what loads first. CSS is structured so the above-the-fold styles are minimal and inline-able. JavaScript that isn’t needed for initial render gets deferred. Fonts use font-display: swap to prevent invisible text during loading.
What does this actually look like in production? On Bracket Hosting, our LiteSpeed stack with NVMe storage, we consistently measure sub-200ms TTFB and sub-1.5s Largest Contentful Paint on pages with images. Not a synthetic benchmark on an empty page. Real content, real images, real WordPress with plugins and custom post types and all the complexity that comes with it. When our theme runs on our hosting stack, PageSpeed Insights scores consistently land above 90 across all four categories. That’s performance, accessibility, best practices, and SEO passing without a dedicated optimization plugin.
If you’re curious about the full picture of what moves the needle on WordPress speed, our guide to WordPress performance optimization goes deeper into database queries, caching layers, and server-side tuning.
Security as a Default, Not a Plugin
Ask most WordPress developers about security, and they’ll point you to a plugin. Wordfence. Sucuri. iThemes Security. Maybe all of them at once.
Those tools have their place. But relying solely on plugins for security? That’s putting a lock on your front door while leaving the windows open.
Our starter theme ships with security headers configured out of the box. Content Security Policy headers that control which resources browsers are allowed to load. HSTS headers that force HTTPS connections. X-Frame-Options to prevent clickjacking. Referrer-Policy and Permissions-Policy to limit what browser APIs third-party scripts can access.
Beyond headers, we strip WordPress metadata that leaks information: version numbers in the HTML source, feed links, and unnecessary REST API endpoints. XML-RPC is disabled by default (it’s a legacy protocol that’s been a common attack vector for years).
None of this is groundbreaking. It’s standard practice in any serious web application. The difference is that we build it into the theme layer rather than depending on a plugin that might conflict with another plugin, or that the client might deactivate because “it was causing issues.”
Security should be a foundation, not a feature you can uninstall.
No Commercial Plugins
This is a deliberate choice, not a limitation. We don’t use commercial plugins in our projects. Every commercial plugin is a dependency you don’t control: licensing changes, update delays, abandoned projects, support that disappears when you need it most.
The exceptions are few and intentional. ACF (Advanced Custom Fields) for structured content, because nothing else matches its flexibility for custom field architecture. WPML when a project requires multilingual support, because it’s the most reliable solution for that specific problem. And Bracket Post Order, our own plugin for drag-and-drop content reordering, because we built it to solve a problem we kept running into across projects.
Everything else is either built into the theme, written as project-specific functionality, or handled by WordPress core. Fewer plugins means fewer potential conflicts, fewer security vulnerabilities, fewer things that can break on a WordPress update. It also means every piece of functionality in a project is code we understand and can maintain.
Modern PHP: Typed, Autoloaded, Modular
WordPress has a reputation for messy PHP. Honestly? A lot of it is deserved. The platform was born in 2003 when PHP 4 was current. Many themes and plugins still write PHP as if it’s 2010, and some of the code we’ve inherited over 15 years makes that look generous.
We require PHP 8.0 as a minimum. Not because we’re trying to be difficult, but because modern PHP is a genuinely different language than what most WordPress developers write. Typed properties catch bugs at the language level instead of in production. Named arguments make function calls readable. Match expressions replace the switch statements that WordPress core is full of.
Our theme architecture uses PSR-4 autoloading through Composer. No more require_once chains at the top of functions.php. Each concern lives in its own file, loaded automatically when referenced. This isn’t just about organization (though that matters when four developers are working on the same theme). It’s about reliability. You can’t accidentally forget to include a file. You can’t load things in the wrong order. The autoloader handles it.
Composer also gives us proper dependency management. When we need a library for image manipulation or data validation or API integration, we install it through Composer with version constraints. No copying random PHP files into an /includes folder and hoping for the best. (We’ve seen that approach. It ends badly around month six.)
Why does this matter for the people who hire us? Faster debugging. Fewer production errors. Easier onboarding when a new developer joins the project midway through. Code that reads like it belongs in 2026, not 2012.
Animation and Interaction Engineering
Scroll-driven animations. Page transitions. Interactive product showcases. Micro-interactions that make a form feel alive instead of static. This is the work that separates a WordPress site that feels custom from one that feels templated.
We use GSAP with ScrollTrigger for our animation layer. If you’ve worked with CSS animations, you know they handle simple transitions well but fall apart when you need precise sequencing, scroll-linked timelines, or cross-browser consistency on complex interactions. GSAP gives us frame-level control over animation timing, the ability to compose animations into timelines, and reliable performance across browsers and devices.
ScrollTrigger specifically is what makes scroll-driven experiences possible without performance penalties. It handles intersection detection, scroll position mapping, and pin behaviors efficiently. We’ve used it for everything from parallax product pages to interactive storytelling layouts where content reveals as the user scrolls.
For projects that call for it, we’ve gone beyond CSS and canvas into WebGL territory. Three.js scenes embedded in WordPress pages, running at 60fps on modern hardware. Not every project needs this. But when a client wants their site to feel like an experience rather than a document, having the capability built into our stack means we’re not starting from zero.
The point isn’t showing off. It’s that animation is engineering work, and treating it as a CSS afterthought limits what you can build. CSS-only animation is fine for hover states and simple transitions. But the moment you need a timeline with five elements moving in sequence based on scroll position, you need real tools.
WooCommerce: Built to Extend
Wordify isn’t a WooCommerce theme. It’s a starter theme that’s designed to accept WooCommerce cleanly when a project requires e-commerce.
This distinction matters. Themes that bundle WooCommerce support by default carry that weight on every project, whether the site sells products or not. Our approach is different: the starter provides the architectural hooks and patterns that WooCommerce needs, and we activate and customize them per project.
When we do build WooCommerce sites, custom is the operative word. Product page layouts tailored to the specific catalog. Checkout flows that remove friction for that client’s particular audience. AJAX-powered cart interactions that don’t require full page reloads. Product image galleries with lazy loading and responsive variants. Every one of these is built per project because no two e-commerce clients have the same needs.
Performance doesn’t take a back seat just because we’re adding e-commerce. The same vanilla JavaScript approach, the same image optimization pipeline, the same deferred loading strategy applies. WooCommerce has a well-earned reputation for slowing sites down. Most of that slowdown comes from themes and plugins loading WooCommerce assets globally, on every page, whether they’re needed or not. We load WooCommerce resources only on pages that need them.
Across our e-commerce projects, the pattern is consistent: WooCommerce sites don’t have to be slow. They’re slow because most implementations don’t treat performance as a constraint.
Keeping Up With WordPress Core
WordPress isn’t standing still, and neither is Wordify.
WordPress 6.8 introduced Speculative Loading, which tells the browser to prerender pages the user is likely to navigate to next. We adopted it in our starter the same month it shipped. WordPress 6.9 brought on-demand block CSS loading (finally, no more shipping styles for blocks that aren’t even on the page) and fetchpriority support for registered scripts. We integrated both within the first week.
This is the part that separates a maintained starter theme from one that was “finished” three years ago. WordPress ships major releases roughly every four months. Each release includes performance improvements, new APIs, and occasionally breaking changes. If your theme doesn’t evolve with the platform, it accumulates technical debt quietly.
We treat our starter theme the way WordPress Boost treats MCP tooling: as something that needs to stay current to remain useful. Every major WordPress release gets a review cycle. New features get evaluated. Deprecated patterns get replaced. Performance improvements get adopted.
That maintenance isn’t free. It takes engineering time. But the alternative, discovering three WordPress releases later that your theme relies on patterns the platform has moved away from, costs more.
Common Mistakes in Custom WordPress Theme Development
We’ve audited enough WordPress sites to see the same problems repeat. Some of these might sting if you recognize your own setup. That’s fine. Awareness is the first step.
Still using jQuery in 2026. Every modern browser supports ES6 natively. jQuery was essential when Internet Explorer 8 needed polyfills for basic DOM manipulation. That era ended years ago. If your theme loads jQuery for a mobile menu toggle and a smooth scroll function, you’re adding network overhead for something that vanilla JavaScript handles in a few lines.
Ignoring security headers. “That’s the server’s job” is the most common excuse. And sure, you can configure CSP headers at the server level. But if the theme can set sane defaults, why wouldn’t it? Defense in depth means not relying on a single layer.
Shipping unoptimized images from the theme. Your theme has icons, logos, background images. If those ship as uncompressed PNGs or oversized JPEGs, they slow down every page before any content images even load. An SVG optimization pass and responsive image generation should be part of your build process, not an afterthought.
No build system at all. Raw CSS and JavaScript files in production mean no minification, no tree-shaking, no cache busting. Your visitors download more bytes than necessary, and browser caches can’t invalidate properly when files change. This is the most basic performance optimization, and skipping it is leaving speed on the table.
Treating performance as a plugin concern. WP Rocket, Autoptimize, LiteSpeed Cache: these are good tools. But they’re compensating for problems that shouldn’t exist. If your theme generates clean, optimized output from the start, caching plugins become a nice-to-have instead of a necessity. Fix the source, not the symptom.
The Foundation for Every Project
Our starter theme isn’t something we talk about often. It’s not a product we sell or an open-source project we promote. It’s internal infrastructure, and like most good infrastructure, it works best when you don’t notice it.
But when a client asks why their Bracket-built WordPress site loads faster than their competitor’s, or why their Core Web Vitals pass without a performance plugin, or why their site hasn’t had a security incident, the answer traces back to the decisions baked into this foundation.
Two hundred projects. Fifteen years of custom WordPress theme development. Distilled into a single, opinionated starting point that evolves with the platform.
If you’re evaluating WordPress development partners, ask them about their build system. Ask about their PHP version requirements. Ask what happens to their themes when WordPress ships a new major release. The answers tell you more about WordPress theme engineering maturity than any portfolio ever will.
Frequently Asked Questions
Do you use a page builder?
No. Page builders like Elementor and WPBakery add significant overhead, both in page weight and in architectural constraints. We build custom templates that give clients exactly the editing experience they need through the WordPress block editor and custom fields, without the performance penalty of a page builder framework running in the background.
Why not a block theme or Full Site Editing?
FSE is a promising direction for WordPress, and we’re watching its maturity closely. For the level of custom design and interaction our clients typically need, classic theme architecture with selective block support gives us more control. We adopt specific FSE features (like theme.json for global styles) where they add value, without committing to the full FSE paradigm where it would limit us.
What PHP version do your themes require?
PHP 8.0 minimum. We use typed properties, named arguments, and match expressions throughout our codebase. If your hosting environment runs PHP 7.x, we’ll work with your hosting provider to upgrade it before development begins. Modern PHP isn’t optional for the level of code quality we maintain.
Can your themes work with WooCommerce?
Yes. Our starter theme is designed to extend into WooCommerce cleanly on a per-project basis. We don’t bundle WooCommerce support by default because that would add unnecessary weight to non-commerce sites. When a project requires e-commerce, we build custom product pages, checkout flows, and cart interactions tailored to that client’s specific catalog and audience.
How do you handle WordPress updates?
We review every major WordPress release (roughly every four months) and update our starter theme to adopt new features, replace deprecated patterns, and integrate performance improvements. Active projects receive these updates as part of their maintenance cycles. This is ongoing engineering work, not a one-time setup.
Why Vite instead of Webpack?
We used Webpack for years. Vite’s dev server is faster (native ES modules vs. bundle-on-every-change), its configuration is simpler, and its production builds through Rollup produce clean, optimized output. For WordPress theme development specifically, the sub-second HMR feedback loop has measurably improved our development velocity. Webpack still works. Vite works better for our use case.
Do you build headless WordPress sites?
We can, and we have for specific projects. But for most WordPress use cases, a well-engineered traditional theme outperforms a headless setup in total cost of ownership. Headless adds deployment complexity, doubles your hosting requirements, and breaks many WordPress plugins. We recommend it when the project genuinely needs a decoupled frontend (React/Next.js, Vue.js/Nuxt.js, or similar consuming WordPress as a data source), not as a default approach.
The approaches described here reflect our engineering experience across 200+ WordPress projects. Your specific requirements, hosting environment, and team capabilities may call for a different approach. Performance metrics cited are based on our testing environments and hosting stack.
