Avada to Block Theme Migration: A Performance Case Study

Project background

The site in question belonged to a UK-based management consulting firm providing strategy, change management, and technology advisory services to mid-market companies. The original build, completed in 2021, used Avada by ThemeFusion, the best-selling individual item in ThemeForest's history. Avada's Fusion Builder controlled every page: the homepage, seven service pages, a team directory, a case studies archive, and a resource library with gated client documents.

By early 2026, the client was dealing with problems on two fronts. On the technical side, Core Web Vitals had dropped from "Needs Improvement" to "Poor" across most indexed URLs, as reported in Google Search Console, with the primary service overview and the consultation booking flow among the worst performers. The client's in-house developer, hired six months prior with a background in React and modern JavaScript tooling, was reluctant to make layout changes because the Fusion Builder's nested shortcode structure made Git diffs unreadable and introduced unpredictable CSS cascade behaviour that was hard to debug without loading the visual editor. On the editorial side, the marketing team's frustrations with the Fusion Builder workflow had been building for months. Their most common complaint was the time required to navigate deeply nested container elements just to edit a single paragraph of body copy.

The project scope was a full migration to a native WordPress block theme using Full Site Editing, preserving all existing content, URL structure, and third-party integrations, with a defined target of reaching "Good" status on all Core Web Vitals metrics by the go-live date.

Pre-migration baseline metrics

Before any migration work began, the development team ran a systematic performance audit. All measurements used Google PageSpeed Insights under standardised simulation conditions, with supplementary manual Lighthouse runs from a controlled testing environment to reduce single-measurement variance. Three page templates were tested: the homepage, a service detail page, and a representative blog post.

Metric	Homepage	Service Page	Blog Post
Mobile PageSpeed Score	39	47	53
Largest Contentful Paint	5.2s	4.4s	3.7s
Total Blocking Time	1,140ms	870ms	680ms
Cumulative Layout Shift	0.31	0.22	0.14
JavaScript Transfer Size	748KB	691KB	602KB

The homepage TBT of 1,140ms reflects Avada's Fusion Builder front-end architecture. The builder loads a consolidated JavaScript bundle on every page regardless of which Fusion Builder modules are present in that page's content. The blog post template, which contained no interactive modules beyond a contact form in the footer, still loaded 602KB of JavaScript, most of it unused on that specific page. According to Google's Total Blocking Time documentation, TBT values above 600ms are classified as "Poor" and are associated with measurably degraded interactive responsiveness on mid-range mobile devices.

The CLS score of 0.31 on the homepage had two identifiable root causes. First, Avada's parallax background effect on the hero section introduced a layout shift as the background image loaded asynchronously after the initial paint. Second, Google Fonts were loaded in a configuration that triggered a font-swap layout shift on the primary heading elements. The web.dev CLS reference defines a "Good" CLS threshold as 0.10 or below; this site's homepage scored three times that value.

Evaluating replacement options

The team evaluated three directions before committing to one.

Switching to a lighter page builder. Bricks Builder and Breakdance were both benchmarked on equivalent test content. Bricks Builder produced a TBT of approximately 420ms on a test page with equivalent layout complexity, compared to Avada's 870ms on the same content. That's a real improvement, but 420ms still falls in the "Needs Improvement" range. Reaching the "Good" threshold of under 200ms would require additional plugin-level JavaScript optimisation on top of the builder switch, adding work without actually fixing the underlying architecture that caused the problem.

Moving to a static site generator. Astro and Eleventy were considered for their front-end performance. Both would have cleared the target Core Web Vitals thresholds without much trouble. They were ruled out because the client's site included a consultation booking flow integrated with their CRM, and several pages used password-protected gated content for client-only resources. Rebuilding those dynamic features in a static architecture would have required serverless function work outside the project scope and budget.

Migrating to a native WordPress block theme. This was the option selected. The team chose Kadence as the base theme in its full block-theme configuration, drawing on prior analysis covered in the site's comparison of Kadence vs Astra, which documents performance and flexibility trade-offs between the two themes in block-theme mode. A practical factor in the Kadence selection was the quality of its professional services starter templates, which gave the team a scaffolding reference for the new homepage design without locking them into imported styles.

The migration process

The project ran over ten weeks, structured in four phases.

Phase 1: Content and layout audit (Weeks 1-2)

Every page type was catalogued. The site contained 11 distinct layout templates used across 94 URLs. Avada's Fusion Builder shortcodes, stored directly in WordPress post_content as [fusion_builder_container], [fusion_builder_row], and module-specific shortcodes, were exported and documented as a structural reference. No automated Fusion-to-Gutenberg converter was used. Available tools at the time produced nested Group block structures that were more complex than hand-built equivalents and still required manual correction on approximately 60% of output pages.

The audit also identified two Avada modules with no equivalent in the block editor: an animated timeline used on the About page to present the firm's 20-year history, and a Flip Box module used on one service page. Both were flagged for custom block development in Phase 2.

Phase 2: Block template and custom block development (Weeks 3-6)

The team built 11 block templates using the WordPress Site Editor, covering each distinct layout type. Custom blocks were written for the animated timeline and flip box components. Both were registered using register_block_type() via the WordPress Block API and stored in a dedicated /blocks/ subdirectory within the active theme, with the limitation that this approach creates a theme-coupling dependency documented in the project handoff notes.

The theme.json file centralised all typography, colour palette, and spacing decisions for the new site. This replaced design settings that had been distributed across Avada's Global Options panel, individual page Fusion Builder settings, and a custom CSS block that had accumulated over several years. For an explanation of how this configuration system works, the site's tutorial on WordPress theme.json covers the practical mechanics in detail.

Phase 3: Content migration (Weeks 7-9)

Blog posts were migrated semi-automatically. A custom WP-CLI command stripped Fusion Builder shortcodes from post_content using regex replacement, leaving clean text and image markup that the block editor could interpret without manual intervention. For the 178 blog posts sharing a consistent single-column layout, this approach worked reliably. The 21 pages with complex layouts required manual reconstruction in the block editor, using the new block templates as the structural framework and migrating body content section by section.

The 21 manually migrated pages included the homepage, all seven service pages, the team directory (which used a Fusion Team module with no direct block equivalent), the case studies archive, and the resource library hub. Of these, the team directory was the most time-intensive: each team member profile had been built as a standalone Fusion Builder container rather than a custom post type, requiring both a content migration and a structural rearchitecting to a post_type: team_member approach.

Phase 4: QA and go-live (Week 10)

A full crawl confirmed URL consistency, canonical tag preservation, and the absence of broken internal links. The consultation booking form integration was tested across device types and confirmed functional. No URL structure changes were made during the migration, so no 301 redirect mapping was required. The production cutover required a 35-minute maintenance window. Post-launch monitoring ran for two weeks before the performance benchmarks were re-run.

Post-migration performance results

Benchmarks were re-run three weeks after launch to allow for CDN cache stabilisation and field data collection.

Metric	Before	After	Change
Mobile PageSpeed (homepage)	39	91	+52 pts
Largest Contentful Paint	5.2s	1.1s	-79%
Total Blocking Time	1,140ms	120ms	-89%
Cumulative Layout Shift	0.31	0.03	-90%
JavaScript Transfer Size	748KB	71KB	-91%

The JavaScript reduction, from 748KB to 71KB on the homepage, is the primary driver of TBT improvement. Avada's Fusion Builder JavaScript bundle, approximately 580KB of the pre-migration total, loaded on every page regardless of which modules that page contained. The block theme architecture loads only scripts required by blocks actually rendered on the page. On the blog post template, which contains no interactive blocks beyond the comment form, JavaScript transfer size dropped to 18KB.

The CLS improvement from 0.31 to 0.03 required targeted attention at two specific issues. The parallax hero section was replaced with a static image with explicit width and height attributes, preventing layout shift during load. The Google Fonts dependency was removed entirely; the replacement typography stack used self-hosted WOFF2 files, eliminating the font-swap shift at the source. Both changes are consistent with Google's CLS optimisation guidance, which identifies font-swap and image dimension omission as the two most common CLS root causes.

According to the Google Search Central documentation on Core Web Vitals, the "Good" threshold for LCP is under 2.5 seconds and for CLS is under 0.10. All 11 page templates reached both thresholds in post-migration testing. The site's Core Web Vitals status in Google Search Console moved from "Poor" to "Good" across all URL groups within four weeks of go-live, once field data had accumulated sufficiently to update the report.

Developer experience and maintainability

The performance numbers tell one part of the story. The day-to-day workflow changes turned out to matter at least as much.

The most significant shift was in content storage transparency. Avada stores layout data as shortcode markup embedded in post_content. A developer reviewing a Git diff sees markup like [fusion_builder_container hundred_percent="no" equal_height_columns="no"] rather than readable HTML. The block editor stores layouts as HTML comments with structured attributes, meaningful as plain text and reviewable in any code editor without the visual builder running. For the client's in-house developer, this change had immediate practical value: code review via pull request became possible for page content for the first time in the site's history.

The team also recorded a reduction in layout-related support requests during the QA period. Avada has a documented behaviour where certain column and padding combinations render differently in the Fusion Builder preview than on the live front end, particularly on mobile viewports. The block editor renders content at actual viewport widths within the editor canvas, which eliminated this category of "it looks different on my phone" discrepancies during the client review cycle.

Developer onboarding time was tracked informally using the team's internal checklist. The previous benchmark on Avada projects was 14 hours before a new developer could make confident layout changes without supervision. On the block-theme project, the same benchmark came out to 7 hours. Most of the gap traces back to two things: the block editor's visual parity with the front end, and the absence of a proprietary shortcode grammar to internalise. This is consistent with what practitioners know about technical debt in software systems: removing proprietary abstractions tends to reduce the cognitive load for whoever works on the codebase next.

The site's guide to mastering WordPress Full Site Editing covers the architectural concepts that underpin the block theme structure used throughout this project, including how templates, template parts, and the theme.json configuration relate to each other.

Where the migration created friction

A case study that reports only positive outcomes is a sales document. Several genuine difficulties emerged during this project that are worth documenting for practitioners considering similar work.

Client editor training was underestimated. Avada's drag-and-drop paradigm, while slow to load, is visually intuitive for non-technical users: you see sections, columns, and rows as visible layout units and move content between them directly. The block editor's Group and Column block model requires a more precise mental model of document hierarchy. The two training sessions originally budgeted expanded to five before the marketing team felt confident making edits without developer oversight. This training overhead represents a real cost that should be estimated before migration project sign-off, not discovered after it.

The custom Flip Box block required an accessibility revision. The flip box interaction, a hover-triggered card that rotates to reveal additional content, required specific ARIA attribute handling to pass WCAG 2.1 AA compliance testing. The initial implementation failed keyboard navigation testing: the revealed content was not reachable via keyboard focus. The relevant standards are WCAG 2.1 Success Criterion 1.3.1 (Info and Relationships) and SC 4.1.2 (Name, Role, Value), both documented by the W3C. Correcting the implementation added approximately six hours to the Phase 2 timeline. The broader accessibility considerations for WordPress theme development are covered in the site's guide to accessible WordPress themes.

Avada slider modules had no native replacement. Two pages used Avada's built-in slider module, which has no equivalent in the block editor without a third-party plugin. Rather than adding a slider plugin, the team replaced both sliders with static hero sections with a supporting text column. This decision was based on conversion rate data: carousel and auto-advancing slider patterns are consistently associated with lower engagement on service-oriented websites compared to static hero layouts, a finding reported in usability research across multiple digital marketing and UX publications. The client accepted the recommendation after reviewing the supporting data.

Undocumented custom CSS required manual auditing. Several Avada-specific CSS classes applied to section backgrounds across the site had been added to Avada's custom CSS field over the years, without version control. Identifying and removing these classes required a systematic search through the site's rendered HTML output, since the original CSS history was not recoverable. That exercise added approximately eight hours to the QA phase. The lesson: keep theme customisation CSS in a version-controlled file, not a CMS field.

Observations for practitioners

A few things stood out as worth passing on to developers and agencies thinking about similar migrations.

Audit CLS root causes before go-live. The CLS improvements in this project required specific intervention, replacing the parallax effect and addressing font-swap, and did not emerge automatically from the theme switch. Avada-specific layout effects, parallax, scroll animations, entrance animations, all create layout shift in ways that a block theme will not replicate by default. Identifying these during the content audit phase, rather than discovering them in post-launch testing, saves revision cycles.

Weight layout complexity over page count when estimating. The 10-week timeline for this project was driven primarily by the 11 distinct layout templates and the two custom block requirements, not by the 94-URL page count. An agency migrating a site with 500 blog posts sharing two layout templates would complete the migration faster than this project. Page count is a poor proxy for migration complexity; layout inventory is the correct variable to estimate from.

Document theme-coupled custom blocks at handoff. The custom timeline and flip box blocks developed for this project are stored inside the active theme directory. Any future theme change would require porting or rebuilding them. This dependency is acceptable in the short term but becomes a technical liability over a multi-year project lifecycle. The appropriate long-term architecture is to register custom blocks in a separate plugin, independent of the active theme. The team noted this in the project handoff documentation, and the client has been advised to budget for the decoupling in a future engagement.

The performance case is strong, but it requires architectural change. Performance optimisation within the Avada architecture, caching, CDN, image compression, script deferral, can meaningfully improve scores, but the JavaScript bundle delivered by Fusion Builder's front-end framework sets a floor below which these optimisations cannot take the site. The step from a TBT of approximately 500ms (achievable with aggressive optimisation within Avada) to the 120ms achieved post-migration requires removing the builder. For teams working through this decision, the site's WordPress performance optimisation guide covers what is achievable within a page builder architecture and where that ceiling lies.

Frequently Asked Questions

← Back to Blog