-
Ehy there dear team,
I built a mega menu that contains images inside a loop.
For performance reasons, especially on mobile I noticed that:
The images inside the mega menu are rendered with
loading=”eager” and fetchpriority=”high”
even though they are not visible on the initial page load: https://imgur.com/mX5wFyeThe generated sizes attribute is:
(max-width: 800px) 100vw, 800px
even though the image is constrained to a width of 140px.The browser seems to select the 768w image instead of a smaller version (150w/300w), which negatively impacts performance.
Is this expected behavior?
Is there a way to prevent GenerateBlocks from forcing eager/high priority for images inside the mega menu? In theory, these images shouldn’t even be loaded since they are hidden.P.S.: I’m attaching the site URL in the private information.
Thaaanks
-
Hi Leonardo,
Regarding
loading="eager"andfetchpriority="high"— this is intentional behavior. The overlay panel uses JavaScript to calculate its size and position, and it needs the images to be fully loaded when that script fires. If the images were set to lazy load, the panel dimensions and positioning would be calculated incorrectly (before the images load in), causing layout shifts and misalignment.The main performance issue here is actually the image size selection. Looking at your markup, the images in the loop are using the full size (800×800) as the source. You can see this in the src attribute — it points to the base filename without any size suffix, e.g.:
about-asheville_city_page_about.webpatwidth="800" height="800"Since the images are constrained to 140px in the mega menu, you should select a smaller image size in the GenerateBlocks image/media settings. The Thumbnail (150×150) would be the most appropriate choice. That change alone will:
- Set the
srcto the 150w version instead of the 800w full size - Result in a more appropriate
sizesattribute - Significantly reduce the payload — you’ll be loading ~5–10KB per image instead of ~50–100KB+
This way the images still load eagerly as needed for proper panel positioning, but the actual file sizes will be much smaller.
- Set the
-
Ehy George,
When you say “Set the src to the 150w version instead of the 800w full size” Do you perhaps mean this setting here? https://imgur.com/l5jRiTi
Because as you can see, the “size” option is not available. Maybe it’s due to the fact that we’re dealing with dynamically set images? Is there a solution to this?
Also, since these images come from a custom field, I was thinking about creating a specific custom field for the images in the mega menu and then uploading images directly at around 200px in size. What do you think? As I mentioned above, that “size” option isn’t editable, so I’m not sure what to do.
-
Hey Leonardo!
Maybe it’s due to the fact that we’re dealing with dynamically set images? Is there a solution to this?
Yeah, just click on that dynamic tag database icon again, you will see the option to select sizes from a dropdown!
-
Sorry George, maybe I misunderstood, but when I click I don’t see any available options, and even after closing the window, that “size” still remains locked. Look here: https://imgur.com/8GCN1hf
-
Oh, I thought that was a dynamic featured image. Any reason why you are not using the featured image instead? You could select a different size from the dropdown then.
-
Basically, the layout uses square images (specific images from a custom field), so when pulling them dynamically they seemed the most appropriate, since they’re also square in the mega menu.
Is it correct that I can modify the “size” option only with the featured image?
At this point, would you recommend setting the featured images? We built only custom fields (with ACF) to make it easier for the end client to insert content, so in practice even the featured image hasn’t been set.
-
Hey Leonardo.
Ok, I see. Yes, you can use a custom field to unify the experience for your users.
Check out this post for the size issue!
https://generate.support/topic/image-size-in-dynamic-tags-from-meta-fields/
-
Gotcha! Thanks George.
Just out of curiosity, if I may ask, is there a specific reason why it’s not possible to do this with dynamic images that aren’t featured? At this point, it would be very useful to implement this in the upcoming versions.
-
Hi Leonardo,
Currently, GenerateBlocks only supports image size selection for featured images because featured images always have an attachment ID available, making it straightforward to retrieve any registered size via WordPress’s
wp_get_attachment_image_src().With dynamic images from custom fields (like ACF), the data can come in different formats — an array, an ID, or a plain URL — so there’s no single standardized way for GenerateBlocks to handle size selection out of the box. It’s not a fundamental technical limitation, more a matter of it not being implemented in the UI yet.
That said, Ying has shared a custom dynamic tag that solves this. It handles all three ACF return formats and gives you the image size selector in the GenerateBlocks UI. Just make sure your ACF field is set to return ID or Array (not URL) so the attachment ID is available for size retrieval.
-
Gotcha!
thanks for the explanation and support George! -
Ok, no problem, Leonardo!
- You must be logged in to reply to this topic.