Hello Bricks team,
the native Bricks “Product Gallery” element causes a significant Cumulative Layout Shift on WooCommerce product pages and therefore severely affects the Core Web Vitals.
I would like to report this as a reproducible bug and request a fundamental revision of the element.
System environment
- Bricks Child Theme: 1.1
- Bricks: 2.3.9
- WordPress: 7.0.2
- WooCommerce: 10.9.4
- PHP: 8.4.23
- Server: Apache
- MySQL/MariaDB: 10.11.18
- PHP and WordPress memory limit: 256 MB
For privacy reasons, I do not want to disclose the public domain in the forum. I can provide screenshots, HTML excerpts, Lighthouse reports, and, if necessary, a test environment privately.
Configuration
The native Bricks “Product Gallery” element is used in a Single Product template.
- Product image size: WooCommerce Single, 600 × proportional height
- Thumbnail size: WooCommerce Gallery Thumbnail, 100 × 100
- Lightbox: Full
- Thumbnail navigation at the bottom
- Bricks slider disabled by default
Problem
When the Product Gallery is displayed, a significant layout shift occurs during initialization.
A reproducible Lighthouse test produced the following results, among others:
- Performance: approximately 40
- FCP: approximately 5.9 seconds
- LCP: approximately 7.8 seconds
- CLS: approximately 0.441
- TBT: approximately 10 ms
Lighthouse repeatedly identifies the following elements as the causes:
- div.brxe-block.content-wrapper
- img.wp-post-image
- “Unsized image element”
The main image already has explicit attributes:
width=“600”
height=“600”
Nevertheless, it is reported as an “Unsized image element.”
During frontend initialization, the gallery is restructured by FlexSlider. This creates, among other things:
- .flex-viewport
- dynamically calculated slide widths
- a wrapper width of, for example, 800%
- inline styles added afterwards
- thumbnail navigation generated afterwards
Apparently, the final dimensions of the gallery are not reliably established before this JavaScript initialization. As a result, all subsequent product content shifts significantly.
Clear A/B test
I completely disabled the Product Gallery element in the Bricks template and repeated the same test.
Without the Product Gallery:
- Lighthouse no longer reports any layout shift culprits;
- the high gallery-related CLS disappears;
- main-thread work decreases significantly;
- considerably fewer or smaller gallery resources are processed.
As soon as the Product Gallery element is enabled again, the problem returns.
The behavior can therefore be directly attributed to the visible Bricks Product Gallery element or its initialization.
Excluding other causes
The following possible causes were completely disabled or excluded during testing:
- FlyingPress, including cache, lazy loading, and Delay JavaScript
- custom script for automatic variation selection
- browser extensions
- WooCommerce beta feature “Variation gallery”
The underlying CLS problem also occurs without these features.
Attempted solutions
- Prioritizing the first product image
The first product image was successfully changed using a WordPress filter to include the following attributes:
loading=“eager”
fetchpriority=“high”
This removes the corresponding LCP discovery warning. However, the gallery-related CLS remains.
- Hiding additional images before initialization
Initially hiding all gallery images except the first did not result in any relevant CLS improvement.
- Reserving the gallery height in advance
A responsive minimum height for the main image and thumbnail row reduced the CLS only from approximately 0.441 to 0.335.
It does not fully resolve the problem and is not a reliable solution because the required height depends on the gallery width, breakpoint, spacing, and number of thumbnails.
The CSS code was tested both as Bricks Custom CSS and as CSS output early in the . The output location made no difference.
- Enabling the Bricks slider
Slider mode did not resolve the problem either. In one test, the CLS even increased to approximately 0.568.
Existing Bricks topic
The following topic already exists and is marked as “Solved”:
“WooCommerce Product Gallery causes CLS”
The topic was closed with a reference to WordPress 6.9 and “late stylesheet hoisting.”
However, I can still clearly reproduce the problem with WordPress 7.0.2 and Bricks 2.3.9.
Requested solution
I would like to ask you to fundamentally revise the native Product Gallery element so that it complies with Core Web Vitals.
In particular, the element should:
- reserve its final dimensions before JavaScript initialization;
- not cause a significant layout shift;
- not lazy-load the first visible product image by default;
- correctly prioritize the first visible product image;
- output responsive sizes values that match the actual gallery width;
- not depend on estimated or hard-coded minimum heights;
- produce a stable layout in both standard and slider mode.
The current situation cannot be resolved reliably through settings or custom CSS. The only test that completely eliminates the CLS is removing the Product Gallery element.
Additional note regarding the WooCommerce “Variation gallery” feature
Independently of the underlying CLS problem, there is an additional compatibility issue with the beta “Variation gallery” feature integrated into WooCommerce:
- In standard/FlexSlider mode, variation-specific galleries are exchanged correctly.
- With the Bricks slider enabled, this exchange does not work correctly.
However, this is not the cause of the described CLS problem. The high CLS also occurs when the WooCommerce beta feature is disabled.
Could you please investigate this issue again and revise the Product Gallery element accordingly?