Page Builder Performance: Lazy Loading, Critical CSS and Image Optimization

1. Why Page Builder pages get slower over time

A freshly created Page Builder page is usually lean and fast. After a few months of editorial maintenance, with additional banners, embedded sliders and nested container structures, Page Builder performance noticeably deteriorates, without any single change being responsible for it. The problem is cumulative: every additional image without optimization, every extra nested container and every unused slider that was never removed adds up to a measurably slower page.

This gradual deterioration is often only noticed once a Core Web Vitals report in the search console dashboard shows red values or a customer complains about long load times. Sustainable Page Builder performance needs both technical measures such as lazy loading and image optimization and a recurring process that detects bloated content before it becomes a real problem.

The situation becomes especially critical on high-traffic entry pages such as the homepage or seasonal campaign landing pages, because most visitors encounter the shop there in the first place. A load time extended by a few seconds on such a page affects the bounce rate in absolute numbers far more than the same delay on a rarely visited subpage. That is exactly why Page Builder performance benefits from prioritization: optimize the highest-traffic pages first, then move on to long-tail pages with lower visitor volume.

2. How serialized Page Builder markup affects load time

Page Builder serializes content as HTML with deeply nested div structures for rows, columns and elements, complemented by numerous style attributes for spacing, backgrounds and responsive adjustments. For complex layouts with many nested columns, this markup alone can amount to several hundred kilobytes of HTML before any images or external resources are even loaded. For Page Builder performance, the sheer number of DOM nodes matters, because the browser has to process every node for layout computation and rendering.

A commonly overlooked factor is Page Builder's inline style practice: every element carries its style information directly in the style attribute instead of an external, cacheable CSS file. That makes sense for editor flexibility but increases HTML size and prevents style reuse across pages. For high-traffic pages, a downstream optimization that converts recurring inline styles into generic CSS classes is worthwhile, without limiting editorial flexibility in the editor itself.

For analyzing an existing page, a simple inventory is a good starting point: how many image content types does the page contain, how many of them are below the fold, and how large is the delivered HTML overall compared to a freshly created, lean reference page. These metrics provide a solid basis to evaluate Page Builder performance not just by feel, but by concrete numbers, and to objectively demonstrate progress after optimization measures.

# Measure raw HTML size and DOM node count of a Page Builder page
curl -s https://shop.example.com/summer-campaign | wc -c
curl -s https://shop.example.com/summer-campaign | grep -o '<div' | wc -l

# Identify pages with unusually large content payloads
bin/mysql -e "SELECT page_id, identifier, LENGTH(content) AS content_bytes
  FROM cms_page ORDER BY content_bytes DESC LIMIT 10"

3. Using lazy loading correctly for images and sliders

Lazy loading defers loading images outside the visible area until the point when a visitor actually scrolls there. For Page Builder performance, the native loading="lazy" attribute on img tags is the simplest and most robust approach, because it works without extra JavaScript and is supported by all modern browsers. Page Builder does not consistently set this attribute on all image content types by default, which requires a targeted retrofit in the renderer template.

The exception for above-the-fold images matters: the first visible image on a page, for example a hero banner, should never receive lazy loading, and instead should be prioritized with fetchpriority="high". Otherwise the Largest Contentful Paint, one of the central Core Web Vitals metrics, gets delayed unnecessarily, because the browser only requests the most important visible element late.

<!-- Renderer template for a Page Builder image content type -->
<!-- Above-the-fold hero image: eager load with high priority -->
<img src="/media/wysiwyg/hero-summer.webp"
     alt="Summer campaign"
     width="1600" height="600"
     fetchpriority="high"
     loading="eager">

<!-- Below-the-fold banner: lazy loaded, decoded asynchronously -->
<img src="/media/wysiwyg/banner-secondary.webp"
     alt="Secondary placement"
     width="1200" height="400"
     loading="lazy"
     decoding="async">

For slider content types, the situation is more complex because slider libraries frequently load all slides into the DOM upfront, regardless of whether they are visible. A slider implementation that only actually loads the active image and the next one in sequence, and loads further images only shortly before the transition, considerably reduces the initial image load, especially for sliders with five or more slides.

For background images, which Page Builder often applies through CSS background-image instead of an img element, the native loading attribute does not work, because it only applies to actual image tags. Here an Intersection Observer based approach helps, setting the actual background image via JavaScript only once the container scrolls into the visible area. For Hyvä themes, this mechanism can be implemented compactly as a small Alpine.js directive, without pulling in an additional external lazy loading library.

4. Critical CSS: styling only the visible area immediately

Since Page Builder delivers styles mostly inline in the HTML, the classic problem of external, render-blocking CSS files for Page Builder's own styles is less relevant than for the base theme. For Hyvä themes, though, the base stylesheet remains a factor for Page Builder performance, especially when additional Tailwind utility classes for custom content types enlarge the CSS bundle. Critical CSS extracts exactly the rules needed for the visible area on first render and delivers them inline in the head, while the rest is loaded asynchronously.

For Page Builder heavy homepages with changing above-the-fold content, however, a static critical CSS extraction is insufficient, because the visible area shifts with every campaign change. An automated build step that regenerates critical CSS on every static content deploy, instead of relying on a one-time generated file, keeps this optimization effective even with frequent content changes.

A realistic compromise for teams without dedicated performance resources is to maintain critical CSS only for the two or three most important entry pages, for example the homepage and the most visited category pages, instead of rolling the technique out across the entire page inventory. This focused application delivers most of the benefit at considerably lower maintenance effort than a full, site-wide critical CSS pipeline.

5. Image optimization: formats, sizes and responsive delivery

The biggest lever for Page Builder performance usually lies with the images themselves, because they typically make up the largest share of transferred data. WebP or AVIF instead of JPEG reduces file size by thirty to sixty percent at comparable visual quality, depending on the image content. Page Builder does not automatically deliver images in modern formats by default, which is why a downstream conversion step in media storage or a CDN feature for automatic format conversion is necessary.

Equally important is responsive delivery through srcset and sizes, so a smartphone visitor does not load the same full-size image file as a desktop visitor with a considerably larger viewport. Page Builder supports responsive images through generated image variants at different breakpoints, but in practice this feature is often not used consistently by editors because it is not obvious in the editor. An editorial guideline with clear rules on maximum source image size prevents editors from uploading four-megapixel photos straight from the camera unasked.

For pages already in production with a historically grown image inventory, a one-time batch conversion run across the entire media storage is worthwhile, rather than only optimizing new uploads. Without this retroactive step, older, uncompressed images remain a permanent drag on Page Builder performance, even if all new uploads already come in modern formats correctly. Such a batch run should happen outside peak hours, since converting many thousand images can create noticeable CPU load.

# Batch-convert existing Page Builder images to WebP with quality 80
find pub/media/wysiwyg -type f \( -iname "*.jpg" -o -iname "*.png" \) \
  -exec cwebp -q 80 {} -o {}.webp \;

# Check average image weight across all Page Builder uploads
find pub/media/wysiwyg -type f \( -iname "*.jpg" -o -iname "*.png" -o -iname "*.webp" \) \
  -exec du -k {} + | awk '{sum+=$1; count++} END {print sum/count " KB average"}'

6. Avoiding layout shifts: reserved heights and aspect ratio

Cumulative Layout Shift measures how strongly visible elements unexpectedly move during a page's load, usually caused by images or embedded content without reserved space. Page Builder images without explicit width and height attributes or without CSS aspect-ratio are one of the most common causes of poor CLS values, because the browser only knows how much space an image needs once it has fully loaded.

Another, less commonly noticed trigger for layout shifts is elements inserted later through JavaScript, for example cookie banners or consent overlays, which push in above Page Builder content and shift all visible content downward. These elements should be planned into the layout from the start with reserved space, instead of being inserted through JavaScript only after the page has fully rendered, because exactly this late insertion causes the largest share of measured CLS values in many Magento shops.

For Page Builder performance, consistently using width and height attributes on every image content type is not optional, it is one of the most effective single measures against layout shifts overall. In addition, reserving a minimum height for slider containers in advance prevents a visible jump in the page layout when the first slide is loaded, especially for sliders that only initialize via JavaScript after the initial render.

An additional CSS approach is consistently using the aspect-ratio property for image containers, combined with a CSS property such as object-fit: cover, which cleanly crops the image content within the reserved frame regardless of the original file's actual aspect ratio. This combination is especially robust because it still works when an editor accidentally uploads an image with a different aspect ratio, without a layout shift occurring or the image being displayed distorted.

7. Content audit: cleaning up bloated pages systematically

Alongside technical optimizations, sustainable Page Builder performance needs a recurring content audit process. A quarterly review of all high-traffic pages, combined with an automated report on HTML size and image count per page, makes visible which pages have grown considerably since the last review. It often turns out that old campaign banners that stopped being relevant long ago were simply never removed from the content, because removing them in the editor feels more effortful than adding to it.

A helpful process step is a fixed rule within the editorial team: for every new banner or slider added to a page, check whether an existing, no longer relevant element can be removed. This simple discipline prevents the gradual growth that otherwise builds up unnoticed over months and eventually makes an expensive overhaul of the page necessary.

For the technical implementation of the audit, a simple reporting script that automatically evaluates content length, number of contained image tags and number of nested row containers for every page and outputs a sorted list is worthwhile. This list makes it visible at a glance which pages have grown the most since the last audit, without having to manually click through every page in the editor.

8. Hyvä-specific optimizations for Page Builder renderers

For Hyvä themes, it additionally applies that the renderer block for Page Builder content types should not load extra framework JavaScript, so as not to undermine the theme's Alpine.js-only strategy. A slider content type that pulls in an external heavyweight JavaScript library contradicts this principle and should be replaced with a lean Alpine.js component that delivers the same functionality at a fraction of the script size.

It is also worth checking whether Page Builder generated inline styles collide with or duplicate the theme's existing Tailwind utility classes. Where possible, frequently recurring style patterns, for example standard spacing between content blocks, should be implemented as a Tailwind class in the renderer template instead of an individual inline style per element, which both reduces HTML size and improves consistency across different pages.

Another Hyvä-specific point concerns preloading fonts and critical assets. Since Hyvä deliberately avoids custom fonts and uses system fonts instead, Page Builder performance avoids an otherwise common problem: web fonts loading with delay, causing a visible flash of unstyled text. This decision by the theme indirectly benefits Page Builder heavy pages, because one less blocking resource in the render process comes without requiring an additional optimization measure.

9. Optimization measures compared

Not every optimization measure delivers the same effect for the same effort. The following overview ranks the most important measures for Page Builder performance by impact and implementation effort.

For most shops, image optimization and correct width/height attributes deliver the biggest effect for the least effort and should therefore be tackled first. Critical CSS extraction pays off particularly for very Page Builder heavy homepages with high traffic, where even small improvements in load time make a measurable difference in conversion rate.

The content audit deliberately occupies a special place in this table because its effect is not immediately measurable but builds up cumulatively over months. A shop that cleans up consistently from the start avoids the need for an expensive overhaul, which eventually becomes unavoidable for pages left unmaintained for years. This preventive effect is hard to capture in a single metric, but makes the biggest long-term difference for consistently good Page Builder performance.

A pragmatic starting point is to begin with the two measures easiest to implement, image format conversion and width/height attributes, and only afterward build up the more elaborate measures such as critical CSS extraction and the recurring content audit process. This order delivers fast, visible improvements while the structural measures can be prepared in the background, without a shop having to wait for one single large optimization project before any effect becomes visible.

10. Summary

Good Page Builder performance is not a one-time state but the result of continuous technical care and editorial discipline. Image optimization with modern formats, correct width and height attributes against layout shifts, and targeted lazy loading below the visible area deliver the biggest effect for manageable effort and should be standard in every Page Builder setup.

Critical CSS extraction and a recurring content audit process complement these technical measures with a structural layer that prevents pages from bloating unnoticed over months. For Hyvä themes, consistently avoiding heavy JavaScript libraries in favor of lean Alpine.js components adds to this, so Page Builder content does not undermine the theme's core principles.

Anyone who treats these measures as a fixed part of daily editorial work rather than a one-time project keeps Page Builder performance at a good level permanently, without having to run a costly general overhaul every few years.

11. FAQ: Page Builder performance