• Hi,

    I would like to suggest some performance improvements for the Woo Product Gallery Slider plugin, especially regarding Core Web Vitals, CLS and initial rendering.

    We noticed that the product gallery is initialized dynamically, and the layout can change when the gallery and its Slick slider are initialized. This can potentially cause the right-hand product information to move after the initial render.

    I think the following improvements would significantly improve the plugin’s performance:1. Reserve the gallery’s final space before JavaScript initialization

    The gallery should have its final dimensions/aspect ratio defined in the initial HTML/CSS state, before Slick is initialized.

    The browser should already know how much space the gallery will occupy during the first render. Initializing the slider should not change the gallery’s height or cause the surrounding product summary content to move.

    2. Avoid layout shifts during Slick initialization

    The current gallery appears to depend on JavaScript initialization to reach its final layout.

    Ideally, the gallery should render in a stable state immediately, and Slick should enhance that existing layout rather than changing its dimensions after the page has already been painted.3. Optimize the CSS assets

    The plugin currently loads:

    • slick.css
    • slick-theme.css
    • fancybox.css
    • flaticon.css

    It would be worth reviewing whether all of these are required on every product page.

    For example, fancybox.css should ideally only be loaded when the lightbox functionality is actually used.

    Likewise, if only a few Slick styles are required, the plugin could provide a smaller, optimized gallery stylesheet instead of loading the full Slick CSS/theme combination.4. Consider replacing the Flaticon dependency

    flaticon.css appears to be used for icons.

    If only a small number of icons are required by the gallery, inline SVG icons would likely be considerably more efficient than loading an entire icon font/CSS dependency.

    For example, navigation arrows could be implemented directly as SVG.5. Conditional asset loading

    The plugin should only enqueue its CSS and JavaScript when the gallery functionality is actually required.

    For example:

    • Non-product pages → no gallery assets
    • Product page without the relevant gallery functionality → only required assets
    • Product page with slider → slider assets
    • Lightbox functionality → lightbox assets

    This would prevent unnecessary CSS/JS from affecting the rest of the website.6. Defer non-critical JavaScript

    The gallery JavaScript and other non-critical scripts should ideally not block the initial page rendering.

    Using deferred loading where possible would allow the main product content to render first.7. Optimize image loading

    The main product image should be treated differently from the other gallery images.

    The main/LCP image should be available immediately and have its dimensions defined in the HTML.

    Images below the fold should use lazy loading.

    Thumbnail images should use appropriately sized WordPress-generated image files rather than unnecessarily downloading large original images.8. Avoid unnecessary slider initialization

    If a product only has one gallery image, there is no need to initialize the complete Slick slider functionality.

    Similarly, unnecessary gallery/lightbox functionality should not be initialized when it is not required.Most important issue

    From a Core Web Vitals perspective, I would prioritize preventing layout shifts during the initial gallery rendering and JavaScript initialization.

    The goal should be that the product page has essentially the same layout:

    before JavaScript loads → after JavaScript initializes

    so that the product title, price, rating and short description do not move when the gallery becomes initialized.

    This would help improve both CLS and perceived loading performance, while conditional asset loading and reducing unnecessary dependencies could further improve the overall page performance.

    Thank you!

Viewing 1 replies (of 1 total)
  • Plugin Author Niloy – Codeixer

    (@im_niloy)

    Hi,

    Thank you for the detailed suggestions and for taking the time to analyze the plugin’s performance.

    At the moment, I’m putting less focus for the plugin and mainly prioritizing security updates, compatibility updates, and keeping it working properly with the latest WooCommerce and WordPress versions.

    I’ve noted your suggestions, especially the points around CLS, initial gallery rendering, conditional asset loading, and image optimization. I agree these are areas that could be improved.

    Hopefully, in the future, I’ll be able to spend more time on a broader performance-focused update and address these issues properly.

    Thanks again for the detailed feedback!

Viewing 1 replies (of 1 total)

You must be logged in to reply to this topic.