Welcome to the first episode of the Page Builder Sandwich podcast. If you build WordPress sites, you have probably installed a page builder at some point. And you have probably watched those pages get slower right after. This episode is about why that happens and what you can do instead. Everything we mention is live at <a href="https://pagebuildersandwich.com/" rel="noopener noreferrer" target="_blank" style="color: rgb(17, 85, 204);">https://pagebuildersandwich.com/</a> where you can download the free plugin and run your own tests.Here is the test that started this conversation. We installed Page Builder Sandwich on a clean WordPress test site and measured exactly what it added to a page. Less than a kilobyte. Zero requests to any third party server. Lighthouse on phones stayed at full score, before and after. Then we measured Elementor on the same test page and it added hundreds of kilobytes plus multiple external requests. That is not a competitor making a claim. That is a measured test, same page, same day, same method, run multiple times with the middle result taken.Why is the gap so big? Most page builders ship everything on every page. The full stylesheet loads whether you used one block or forty. Your markup gets wrapped in layer after layer of builder specific divs. And when you finally switch, you find shortcodes buried through your database and a site that stops making sense the moment you deactivate the plugin.That last part is what nobody warns you about. Lock in. A native block approach avoids it completely. Pages are saved as standard WordPress blocks, so your SEO plugin reads them, your theme reads them, and deactivating the builder tomorrow leaves your content intact and still rendering. It sounds obvious, but almost no page builder works this way.We also spend time on accessibility, which most builders skip entirely. Keyboard navigation, screen readers, reduced motion, and a checker that flags problems while you build instead of after you ship. Then we get to the part that surprised even us. An MCP server inside the plugin, so Claude or Cursor can create pages and edit blocks using your own WordPress permissions. That works today, not on a roadmap.If you care about Core Web Vitals, clean client handoffs, or keeping your content portable, this one is for you. Tell us what to cover next: importing from Divi, WooCommerce design, the Figma workflow, or translating blocks with Tranzly.

Welcome to the first episode of the Page Builder Sandwich podcast. If you build WordPress sites, you have probably installed a page builder at some point. And you have probably watched those pages get slower right after. This episode is about why that happens and what you can do instead. Everything we mention is live at https://pagebuildersandwich.com/ where you can download the free plugin and run your own tests.Here is the test that started this conversation. We installed Page Builder Sandwich on a clean WordPress test site and measured exactly what it added to a page. Less than a kilobyte. Zero requests to any third party server. Lighthouse on phones stayed at full score, before and after. Then we measured Elementor on the same test page and it added hundreds of kilobytes plus multiple external requests. That is not a competitor making a claim. That is a measured test, same page, same day, same method, run multiple times with the middle result taken.Why is the gap so big? Most page builders ship everything on every page. The full stylesheet loads whether you used one block or forty. Your markup gets wrapped in layer after layer of builder specific divs. And when you finally switch, you find shortcodes buried through your database and a site that stops making sense the moment you deactivate the plugin.That last part is what nobody warns you about. Lock in. A native block approach avoids it completely. Pages are saved as standard WordPress blocks, so your SEO plugin reads them, your theme reads them, and deactivating the builder tomorrow leaves your content intact and still rendering. It sounds obvious, but almost no page builder works this way.We also spend time on accessibility, which most builders skip entirely. Keyboard navigation, screen readers, reduced motion, and a checker that flags problems while you build instead of after you ship. Then we get to the part that surprised even us. An MCP server inside the plugin, so Claude or Cursor can create pages and edit blocks using your own WordPress permissions. That works today, not on a roadmap.If you care about Core Web Vitals, clean client handoffs, or keeping your content portable, this one is for you. Tell us what to cover next: importing from Divi, WooCommerce design, the Figma workflow, or translating blocks with Tranzly.

Page Builder Sandwich Podcast

Heavy Pages

Tired of page builders that bloat your site and lock your content into shortcodes? This podcast is about building WordPress pages the clean way. Native blocks, per-page CSS that adds half a kilobyte instead of 150, accessibility baked in, and AI agents that can edit your pages through MCP. Real tests, real numbers, no hype. For WordPress builders, freelancers and agencies who care about speed and actually owning their content. Grab the free plugin at <a href="https://pagebuildersandwich.com/" rel="noopener noreferrer" target="_blank" style="color: rgb(17, 85, 204);">https://pagebuildersandwich.com/</a>

Tired of page builders that bloat your site and lock your content into shortcodes? This podcast is about building WordPress pages the clean way. Native blocks, per-page CSS that adds half a kilobyte instead of 150, accessibility baked in, and AI agents that can edit your pages through MCP. Real tests, real numbers, no hype. For WordPress builders, freelancers and agencies who care about speed and actually owning their content. Grab the free plugin at https://pagebuildersandwich.com/

hubhopper

Page Builder Sandwich Podcast

hubhopper