Introduction
Timber vs WordPress
WordPress powers a huge share of the web for good reasons. Timber isn't a "WordPress killer" — it's a different trade-off for a different kind of site. Here's an honest side-by-side.
At a glance#
| WordPress | Timber | |
|---|---|---|
| Storage | MySQL / MariaDB | JSON files in data/ |
| Install | Create a database, credentials, wp-config, run the installer | Upload, open the site, answer three questions |
| Hosting needs | PHP + MySQL | PHP only |
| Back up | Database dump + files | Copy two folders (or one click: export a .zip) |
| Move hosts | Export/import, fix URLs, hope plugins agree | Copy the folder |
| Forms | Plugin (Contact Form 7, WPForms…) | Built in |
| SEO (titles, OG, sitemap, redirects) | Plugin (Yoast, Rank Math…) | Built in |
| Cookie consent | Plugin | Built in (Google Consent Mode v2) |
| Maintenance mode | Plugin | Built in |
| Multiple designs live-previewed | Customizer / staging plugin | Built in (the Playground) |
| Page weight of a starter page | Depends on theme and plugins | Roughly 50–60 KB gzipped before images |
| Users | Many roles and capabilities, plus plugins | Administrator, Editor (posts), Read-only |
| Updates | Core, themes and every plugin, constantly | You own the code; copy over new core files when you choose |
| Extending | Plugins and hooks | Edit the code; themes; small integration files |
Where Timber is better#
- Setup and moving. No database means nothing to provision, nothing to migrate, nothing to corrupt. A site is a folder.
- Less to update, less to break. There's no plugin ecosystem to keep in sync, so there's no plugin-compatibility roulette.
- A smaller attack surface. Individual accounts with three simple roles, no public login endpoints beyond
/padmin, no plugin vulnerabilities to inherit. Internals are blocked at the web server. - Speed without caching plugins. Pages are server-rendered with no query layer and tiny assets. You don't need a caching plugin to get a fast first byte.
- Out-of-the-box completeness. The features most small sites install plugins for are in the box and designed to work together (forms feed the inbox, the inbox feeds email, SEO feeds the sitemap).
- Design workflow. Run a redesign as a private version next to the live site, compare them side by side, share a preview link, then switch — no staging server.
- Readable. The whole codebase is plain PHP you can skim. There's no hook maze to learn before you can change something.
Where WordPress is better#
Timber has three simple roles, flat-file storage and no marketplace. It also doesn't have WordPress's decades of community answers. If your project needs those things today, WordPress (or something purpose-built) is the right call.
Where they overlap#
For a blog, portfolio, studio site, product site, docs landing page or small-business site edited by one or two people, both work. That's where Timber's simplicity pays off — and where a migration is easy. If that's you, try the WordPress migrator: it imports your posts, pages, menus and images and rebuilds your old site's look as a private Timber version, so you can compare before you commit.
Common worries#
"Isn't flat-file slow?" Not at this scale. Reads are a single JSON file per collection; a site with a few hundred pages renders in a few milliseconds on ordinary hosting. It stops being the right choice at thousands of records or heavy write traffic — see Data & storage and the SQLite item on the roadmap.
"Are three roles enough?" For a small team, usually: administrators run the site, editors write posts, and read-only users look but can't touch. Passwords are hashed, sign-in is throttled and every action is permission-checked on the server. For authors-only-their-own-posts or approval workflows, WordPress is ahead. See Users & roles and Security model.
"Will my plugins work?" No — Timber doesn't run WordPress plugins. The point is that most of what people use plugins for is built in.