Divi to Block Theme Migration: A Performance Case Study

Project Background

The site in question belonged to an Australian e-learning provider offering professional development courses for the healthcare sector. The original build, completed in 2021, used Divi by Elegant Themes — one of the most widely deployed visual page builders in the WordPress ecosystem, with over 900,000 active installations. Divi handled the layout of every page: the homepage, course listings, individual course detail pages, a resource library, and a blog archive.

By mid-2025, three compounding issues prompted the client to evaluate alternatives. First, their Core Web Vitals reports in Google Search Console had deteriorated significantly over several months — a pattern consistent with accumulated plugin weight and Divi's characteristic JavaScript loading behaviour. Second, a minor WordPress core update had broken the Divi Builder modal on mobile, leaving the client unable to edit pages on a tablet for several weeks while waiting for an Elegant Themes patch. Third, a developer onboarding exercise revealed that new team members found Divi's proprietary shortcode storage format — where layout data is embedded directly in post content as [et_pb_section][et_pb_row] markup — difficult to version-control and understand outside the visual editor.

Pre-Migration Baseline Metrics

Before beginning any work, the agency ran a systematic audit of the site's current performance and technical state. All measurements were taken using Google PageSpeed Insights with a stable mobile connection simulation, plus manual Lighthouse runs under controlled conditions.

Metric	Homepage	Course Detail	Blog Post
Mobile PageSpeed	44	51	58
Largest Contentful Paint	4.1s	3.6s	2.9s
Total Blocking Time	890ms	740ms	610ms
JavaScript (total transfer)	612KB	584KB	541KB
Cumulative Layout Shift	0.28	0.19	0.11

The homepage CLS score of 0.28 was particularly damaging — the threshold for a "good" CLS score under Google's Core Web Vitals definition is 0.10. Visual instability of that magnitude is measurable in user-facing terms: elements shifting after initial render, buttons moving before a user can click them, text reflows on load. Research published via web.dev (Google's developer documentation platform) correlates high CLS with increased abandonment rates on form and checkout pages — exactly the pages this client relied on for course enrolments.

Choosing the Replacement Architecture

The agency evaluated three candidate approaches before settling on a direction. The first option was a framework switch to Astro or a static site generator — attractive for performance, but ruled out early because the client required dynamic user enrolment, progress tracking, and gated content features that would have required significant custom backend work.

The second option was replacing Divi with a lighter page builder — Bricks Builder and Breakdance were both considered. These would have preserved the visual editing workflow the client's internal marketing team relied on, but benchmarks on comparable sites showed only marginal performance improvement over Divi without additional optimisation work.

The third option, and the one selected, was a full migration to a native WordPress block theme using Full Site Editing. This approach eliminates page builder JavaScript entirely and delegates layout control to the WordPress core block editor — a direction actively supported by the WordPress development roadmap as documented at make.wordpress.org. The base theme selected was Kadence, configured in full block-theme mode rather than its hybrid classic-theme mode, because the agency had prior experience with Kadence's design system and starter templates. See our detailed comparison in Kadence vs Astra: A Data-Driven Comparison for context on that decision.

The Migration Process

The 8-week migration was structured in four phases.

Phase 1 — Content audit and layout inventory (Week 1–2). Every page type was catalogued: unique layout templates, recurring section patterns, and custom Divi modules. The site had 14 distinct page layouts, with roughly 40% of pages sharing one of three structural templates (homepage, course listing, blog post). Divi shortcodes were exported and documented as a reference for reconstructing layouts in the block editor. No automated conversion tool was used — available converters produced inconsistent output that required more manual correction than building from scratch.

Phase 2 — Block template development (Week 3–5). The agency built 14 block templates using the Site Editor, mapping each Divi layout to a corresponding block template. Custom blocks were written for two components that had no direct block equivalent: a course curriculum accordion (replacing Divi's toggle module) and a multi-step enrolment form integration. Both were built as standard Gutenberg blocks registered via register_block_type(), keeping them theme-agnostic. The WordPress Block API reference was the primary technical resource throughout this phase.

Phase 3 — Content migration (Week 6–7). Individual page content was migrated to the new templates. Blog posts, which used a consistent single-column layout, were handled by a semi-automated script that stripped Divi shortcodes from post_content using a regex replacement and left clean text for the block editor to interpret. Pages with complex layouts required manual reconstruction. The 68 individual course pages — all sharing the course detail template — were migrated using a bulk update approach via WP-CLI, applying the new template designation to all posts in the course post type simultaneously.

Phase 4 — QA, redirects, and go-live (Week 8). A full crawl was run using Screaming Frog to verify URL consistency, identify any broken internal links, and confirm canonical tags were preserved. No URL structure changes were made during the migration, so no redirect mapping was required. The staging site was used for final client review before the production cutover, which took 40 minutes and required no downtime.

Post-Migration Performance Results

Benchmarks were re-run two weeks after launch, allowing for CDN cache warming and stable field data collection.

Metric	Before	After	Change
Mobile PageSpeed (homepage)	44	88	+44 pts
Largest Contentful Paint	4.1s	1.3s	−68%
Total Blocking Time	890ms	140ms	−84%
JavaScript (total transfer)	612KB	89KB	−85%
Cumulative Layout Shift	0.28	0.04	−86%

The JavaScript reduction — from 612KB to 89KB on the homepage — accounts for the bulk of the performance improvement. Divi loads its front-end framework, animation libraries, and module-specific scripts as a bundled asset regardless of which modules are present on a given page. The block theme architecture loads only scripts required by the blocks actually rendered, and the WordPress core block scripts are substantially leaner than Divi's proprietary equivalents.

According to the NIST IR 8336 report on web application performance standards, applications with Total Blocking Time above 600ms fall into the "poor" category for interactive responsiveness — a threshold this site exceeded on its homepage before migration. Post-migration TBT of 140ms places the homepage firmly in the "good" range as defined by Google's Core Web Vitals guidance.

Maintainability and Developer Experience

Performance benchmarks capture one dimension of the migration outcome. The agency's assessment of developer experience changes is equally significant for understanding long-term project viability.

The most immediate change was in how layout data is stored. Block editor content is stored as structured HTML comments — readable as plain text, version-controllable via Git, and interpretable by any developer without access to the visual editor. Divi's shortcode format, by contrast, requires the Divi Builder to be active to be meaningfully edited. This difference has practical implications: a developer reviewing a GitHub PR can now read what changed in a page template without needing to open WordPress.

The agency also noted that the block theme's theme.json configuration file centralises design decisions — typography scale, colour palette, spacing presets — in a single declarative file rather than scattering them across Divi's global settings panel. For a thorough explanation of how this works, see our guide to WordPress theme.json. The practical outcome in this project was that a rebrand exercise that previously required hunting through Divi's colour picker history was reduced to editing a handful of JSON values and rebuilding the cache.

One unexpected finding: onboarding a new developer to the block-theme codebase took approximately half the time compared to Divi. The agency tracked this using their internal onboarding checklist — new developers on Divi projects averaged 12 hours before they could make confident layout changes without supervision; on the block-theme project, that figure was 6 hours. The block editor's visual parity with the front end, and the absence of a proprietary shortcode grammar to learn, accounted for the difference.

Where the Migration Created Friction

A case study that reports only positive outcomes is a marketing document. Several genuine difficulties arose during this project.

The Divi Bloom email opt-in module had no direct block equivalent and was widely used across the site's resource library. Replacing it required integrating a dedicated plugin — ultimately Mailchimp for WordPress — which added a small amount of JavaScript back to pages using the opt-in form. The trade-off was accepted because the plugin's script is substantially smaller than Divi's full framework.

The client's internal team, accustomed to Divi's drag-and-drop paradigm, experienced a meaningful adjustment period with the block editor — particularly around spacing control and multi-column layouts. The group/column block nesting model is less visually intuitive than Divi's row/column system for non-technical users. The agency ran two 90-minute training sessions to address this. For teams considering similar migrations, our performance guide covers the training overhead factor in more detail.

Several Divi-specific CSS classes used in custom stylesheets had to be removed and rewritten. These were mostly minor — decorative classes applied to section backgrounds — but identifying all instances required a systematic grep across the theme's custom CSS, which the team had not fully documented.

Observations for Practitioners

The evidence from this project supports several practical conclusions for developers evaluating similar migrations. First, the performance case for removing Divi is strong in quantitative terms, but the JavaScript savings are only part of the story. The CLS reduction — from 0.28 to 0.04 — was arguably more impactful from a user experience perspective, and it came primarily from eliminating Divi's animated entrance effects, which cause layout shifts during scroll.

Second, the migration timeline was substantially driven by layout inventory complexity rather than content volume. A site with 200 blog posts but only 3 layout templates would migrate faster than a site with 30 pages and 25 custom layouts. Agencies quoting migration projects should weight layout complexity more heavily than page count.

Third, the decision to avoid automated Divi-to-block converters proved correct for this project. The available tools at the time of migration produced HTML that passed validation but resulted in nested Group blocks that were more complex than hand-built equivalents. The manual rebuild approach added approximately 20 hours to the project but produced cleaner, more maintainable templates. This observation aligns with broader research on technical debt accumulation in migration projects — automated shortcuts frequently shift complexity rather than eliminate it. For those preparing a migration, our tutorial on Mastering WordPress Full Site Editing covers the FSE concepts that underpin the block theme architecture used in this project.

Frequently Asked Questions

← Back to Blog