NextGen Theme — Fixed Roadmap to Version 1.0
Yes. Before writing code, we should **freeze a finite roadmap** so the theme doesn’t turn into another endless optimization project.
# NextGen Theme — Fixed Roadmap to Version 1.0
### Product mission
Build a production WordPress theme designed from the beginning to work exceptionally well with **NextGenCache**, while remaining fully functional without it.
The performance philosophy is:
> **The theme should avoid creating performance problems rather than expecting the cache plugin to repair them later.**
The goal is **95–100 Lighthouse Performance on clean representative pages under mobile testing conditions**, with **100 as the engineering target, not a guaranteed score for every site/page**.
WooCommerce, LMS, quiz plugins, ads, analytics, embedded media, server configuration and user content can independently affect the final score.
—
## Phase 1 — Ultra-Light Theme Foundation
Build the minimum production WordPress theme architecture.
Core requirements:
* WordPress coding standards
* Current supported WordPress compatibility
* PHP 8.x compatibility
* Translation ready
* RTL ready
* Child-theme compatible
* Hooks/filter architecture
* No NextGenCache dependency
* No jQuery dependency from the theme
* No frontend framework
* No Bootstrap
* No icon font
* No external font
* No analytics/telemetry
* No unnecessary frontend JavaScript
* Fail-safe handling of missing features
* Proper escaping/sanitization
* WordPress.org-compatible structure
Initial templates:
`header.php`
`footer.php`
`index.php`
`front-page.php`
`home.php`
`single.php`
`page.php`
`archive.php`
`search.php`
`404.php`
**Gate:** Theme installs and operates correctly with NextGenCache completely disabled.
—
# Phase 2 — Performance-First Rendering Architecture
Now establish the theme’s performance contract.
### CSS
Use an extremely small base stylesheet.
Target:
**Base CSS ≤ 15 KB uncompressed**
Preferably considerably smaller.
No giant utility framework.
Structure CSS around:
* reset/normalization
* typography
* layout
* header
* navigation
* content
* forms
* footer
* accessibility
Component CSS should load only when the component exists.
### JavaScript
Target:
**Theme JS ≤ 5 KB compressed/minified**
Use vanilla JavaScript.
JavaScript should primarily handle things such as:
* mobile navigation
* accessible toggles
* genuinely interactive theme components
No jQuery.
### Rendering
Above-the-fold HTML must not depend on JavaScript.
**Gate:** A basic page renders correctly with JavaScript disabled.
—
# Phase 3 — Zero-CLS Layout System
Make layout stability part of the theme architecture rather than something NextGenCache repairs.
Requirements:
* image dimensions
* logo dimensions
* reserved media space
* stable header dimensions
* stable navigation
* stable content containers
* stable sidebar
* stable footer
* no JS-created initial layout
* no font-induced layout shift
* predictable responsive breakpoints
Engineering target:
**CLS = 0.00**
on our clean certification pages.
—
# Phase 4 — Native LCP Architecture
The theme should make the likely LCP resource easy for the browser to discover.
For hero/featured content:
* initial HTML contains the resource
* width/height known
* no JS discovery
* no CSS background image when ordinary `<img>` is appropriate
* no theme lazy-loading of probable LCP
* responsive `srcset`/`sizes`
* WordPress image APIs retained
* no duplicate image download
NextGenCache can then add its existing page-specific LCP intelligence on top.
**Gate:** Lighthouse reports the primary LCP resource as immediately discoverable on representative templates.
—
# Phase 5 — Typography & Font Architecture
Default to a system font stack.
That means a fresh site requires:
**0 font requests.**
Optional typography can support local WOFF2 fonts later.
No:
* Google Fonts by default
* Font Awesome
* unnecessary icon fonts
* duplicate font formats
* TTF/WOFF fallback downloads where unnecessary
Icons should primarily use lightweight SVG.
**Gate:** Default theme produces zero frontend font downloads.
—
# Phase 6 — Component-Based Asset Loading
This is one of the most important phases.
The theme must **not globally enqueue everything**.
Example:
A page without comments shouldn’t need comment-specific assets.
A page without search interaction shouldn’t need search JS.
A page without WooCommerce shouldn’t receive theme WooCommerce integration CSS.
Think:
> **Component exists → component assets allowed.**
rather than:
> Theme enabled → load everything.
NextGenCache should have much less unnecessary material to remove.
**Gate:** Asset matrix proves template/component-specific delivery.
—
# Phase 7 — Gutenberg / Block Editor Integration
We cannot achieve performance by breaking modern WordPress.
Support:
* Gutenberg
* wide/full alignment
* galleries
* images
* tables
* quotes
* buttons
* columns
* embeds
* groups
* cover blocks
* navigation where applicable
But avoid blindly loading unnecessary block CSS.
Editor appearance should reasonably correspond to frontend appearance.
**Gate:** Representative core-block test page passes visual and functional verification.
—
# Phase 8 — Accessibility Architecture
Let’s target **Lighthouse Accessibility 100** rather than fixing accessibility afterward.
Requirements include:
* semantic landmarks
* correct heading hierarchy
* skip link
* accessible menu
* keyboard navigation
* visible focus
* accessible buttons
* ARIA only where appropriate
* form labels
* adequate contrast
* meaningful navigation structure
* reduced-motion consideration
This directly addresses issues currently appearing in your tests such as:
**Buttons do not have accessible names**
and
**Heading elements are not sequentially ordered.**
**Gate:** Representative native-theme pages achieve Accessibility 100 with manual keyboard checks also passing.
—
# Phase 9 — SEO & Structured Markup Foundation
The theme should not try to become an SEO plugin.
It should provide correct semantic infrastructure:
* valid document structure
* correct title support
* canonical WordPress APIs
* semantic article markup
* proper heading architecture
* sensible archive markup
* accessible navigation
* clean pagination
* correct image attributes
SEO plugins remain responsible for advanced metadata/schema.
No duplicate SEO system.
**Gate:** Theme introduces no Lighthouse SEO failure of its own.
—
# Phase 10 — WooCommerce Performance Integration
This requires particular discipline.
WooCommerce support must be **conditional**.
Non-commerce pages should not receive NextGen Theme WooCommerce assets merely because WooCommerce is installed.
Support:
* shop
* product
* product categories
* cart
* checkout
* account
* notices
* gallery
* variations
* add-to-cart
* responsive commerce layouts
But do not recreate WooCommerce’s entire styling framework.
This phase directly targets the kind of residual theme CSS we’re currently seeing:
`generate-woocommerce.css`
`generate-woocommerce-mobile.css`
**Gate:** Non-Woo pages receive **zero NextGen Theme WooCommerce assets**.
Commerce pages remain fully functional.
—
# Phase 11 — LMS & Quiz Compatibility
Test the ecosystem we’re actually using.
Initial certification targets:
* LifterLMS
* Quiz Maker
The theme should provide layout compatibility without globally loading special LMS/quiz packages.
Test:
* course
* lesson
* quiz
* logged-out state
* logged-in state
* forms
* navigation
* interactions
**Gate:** LMS/Quiz pages pass without causing theme-specific assets to leak onto ordinary pages.
—
# Phase 12 — NextGenCache Native Compatibility
Only now do we explicitly integrate with NextGenCache.
Important rule:
> **NextGenCache must enhance the theme, never be required by the theme.**
We can expose deterministic information through WordPress APIs/hooks rather than private coupling.
Potential integration points:
* template identity
* component identity
* LCP candidate hints
* critical layout boundaries
* safe asset identity
* WooCommerce template context
* asset exclusion information
But:
**No AI.**
**No self-learning.**
**No autonomous theme mutation.**
And no duplicated cache engine inside the theme.
**Gate:** Activate/deactivate NextGenCache repeatedly; theme functionality remains unchanged.
—
# Phase 13 — Critical Rendering Path Certification
This is where we test the combination.
Representative pages:
1. Homepage
2. Post
3. Page
4. Archive
5. Search
6. 404
7. Product
8. Shop
9. Course
10. Lesson
11. Quiz
12. Cart
13. Checkout
14. Account
Measure:
* TTFB
* FCP
* LCP
* CLS
* TBT
* INP when valid
* render-blocking requests
* request count
* CSS bytes
* JS bytes
* font requests
* image behavior
We specifically investigate every theme-owned critical request.
**Gate:** No unexplained theme-owned critical-path resource.
—
# Phase 14 — Lighthouse 100 Engineering Pass
Now we deliberately attack the final performance tail.
For a **clean ordinary WordPress page** using only NextGen Theme + NextGenCache, target:
**Performance: 100**
**Accessibility: 100**
**Best Practices: 100**
**SEO: 100**
Under the same controlled Lighthouse mobile methodology.
But there will be an important release distinction:
### Engineering target
**100 / 100 / 100 / 100**
### Release requirement
Performance must remain excellent and functionality must remain correct; we do **not** introduce dangerous hacks merely to turn 99 into 100.
That rule will prevent score chasing from damaging production behavior.
—
# Phase 15 — Real-World Performance Matrix
A blank page reaching 100 proves very little.
Therefore test progressively harder configurations:
**A — WordPress only**
NextGen Theme + NextGenCache.
**B — Content site**
Posts, images, navigation, comments.
**C — WooCommerce**
Real product/shop/cart.
**D — LMS**
LifterLMS course/lesson.
**E — Quiz**
Quiz Maker.
**F — Combined production stack**
WooCommerce + LMS + Quiz + NextGenCache.
This tells us exactly where performance cost originates.
—
# Phase 16 — Mobile / Desktop / Browser Certification
Test:
* mobile
* desktop
* Chrome
* Firefox
* Safari-compatible behavior
* responsive navigation
* keyboard
* touch
* orientation changes
* high-resolution displays
* reduced motion
Screen-width matrix should include common mobile/tablet/desktop boundaries.
**Gate:** No visual or functional regression.
—
# Phase 17 — WordPress Compatibility Certification
Test against:
* current WordPress
* supported previous WordPress version(s)
* PHP supported range
* clean permalink structures
* multisite where supported
* child themes
* block editor
* widgets where applicable
* custom logo
* featured images
* menus
* comments
* search
* archives
And run WordPress coding/security checks.
—
# Phase 18 — Security & Input-Safety Compliance
The theme has a much smaller attack surface than a complex plugin, but we still certify it.
Review:
* escaping
* sanitization
* nonce usage
* capability checks
* safe URLs
* safe HTML
* form processing
* AJAX if any
* file operations
* template injection
* direct-file execution
* PHP warnings/notices
* debug mode
**Gate:** No unresolved security/compliance findings.
—
# Phase 19 — WordPress.org Repository Compliance
Prepare a clean distributable theme.
Check:
* required files
* `style.css` headers
* `functions.php`
* screenshot
* licensing
* GPL compatibility
* bundled asset licensing
* translation
* readme/documentation
* prohibited functionality
* theme review requirements
* no plugin-territory functionality
This is especially important.
**Caching, SEO engines, analytics, database cleanup, security systems, etc. stay OUT of the theme.**
NextGenCache handles performance infrastructure.
—
# Phase 20 — Release Certification
Final finite matrix.
Require PASS for:
**Theme standalone operation**
**NextGenCache compatibility**
**Homepage**
**Post**
**Page**
**Archive**
**Search**
**404**
**Gutenberg**
**WooCommerce product**
**Shop**
**Cart**
**Checkout**
**Account**
**LMS course**
**LMS lesson**
**Quiz**
**Mobile**
**Desktop**
**Accessibility**
**Security**
**Fresh installation**
**Upgrade**
**Child theme**
**Uninstall/theme switch recovery**
**No PHP errors**
**No theme-origin console errors**
Then:
# NextGen Theme 1.0 Stable
—
## Performance budget we should freeze now
| Resource | Clean-page target |
| ————————— | —————————-: |
| Theme CSS | **≤15 KB raw** |
| Theme JS | **≤5 KB raw/minified target** |
| Theme font requests | **0** |
| Theme jQuery requests | **0** |
| Theme icon-font requests | **0** |
| Theme external requests | **0** |
| CLS | **0.00 target** |
| TBT | **≈0 ms target** |
| Theme-induced third parties | **0** |
And one more rule:
> **Every byte needs a reason to exist.**
## Development sequence
We should **not build all 20 phases at once**.
The actual release progression should remain finite:
**0.1.0** — Foundation
→ **0.2.0** — Rendering/CSS/JS
→ **0.3.0** — LCP/CLS/Media
→ **0.4.0** — Gutenberg
→ **0.5.0** — Accessibility/SEO
→ **0.6.0** — WooCommerce
→ **0.7.0** — LMS/Quiz
→ **0.8.0** — NextGenCache integration
→ **0.9.0** — Cross-page/performance certification
→ **1.0.0** — Production stable
And I would freeze one final architectural rule:
**We do not add another major phase simply because Lighthouse finds another optimization opportunity. A new phase after this roadmap requires a genuine functional, compatibility, security, or release blocker.**
That gives us a much cleaner path than trying to make NextGenCache itself responsible for every last millisecond.