Drupal Cms Front Page Hero image not visible in the first load / visit (needs a reload)

@itamair could you provide the exact steps you're taking? When you use the installer, you land on the dashboard. Are you saying that after that, you load the home page and the image isn't there? Or are you installing via drush and then going directly to home?

I can't reproduce this using either method, but would be great to get more info. Doesn't seem like there should be an issue creating just the one image style on the fly, that's how it should work. Does the logo image embedded in the content also not load?

@pameeela here it is ...

I am testing on the 1.0.0-rc2 ( https://www.drupal.org/project/cms/releases/1.0.0-rc2 → )

I don't use DRUSH
and I simply follow the instructions and run (from my Terminal inside PhpStorm) the following script:
./launch-drupal-cms.sh

with the following setup:
MacOS X Sonoma 14.6.1
Safari 18.0
ddev version v1.24.1

and checking NONE of all the available pre configured types of content (blog, case studies, events, news, person profiles and projects).
But this also happens when I check some of the above.

Indeed all the process lands nicely in the Dashboard
BUT then when I click on the"Back to Site" link or on the Drupal drop icon (top left) and visit the Home / Front Page for the first time, the Hero image is not yet loaded / found as styled image ... in this use case of mine (this is not random, but happens every time to me)
(further screenshot attached)

I can recreate this issue in Safari but it doesn't happen in Chrome.

It doesn't only happen after installation but also if I flush the image styles.

I can never seem to reproduce the issue once I have published the content but I wouldn't say that I can reliably reproduce that behaviour. I could not reproduce it on some new content I created.

This is an image in the body content so it's lazy loaded, it's above the fold that's bad form. I moved the image further down in the content and the image loaded.

The lazy loading of responsive images is quite a new feature and if it's a bug with loading lazy images above the fold feels like something that's potentially one to look at upstream.

I also report and confirm that this also happens to me (atm)
with the same setup of mine (described in this issue description, this with Safari 18.0, etc.)
with the install / build from the Drupal CMS GIT repo itself (https://git.drupalcode.org/project/drupal_cms)
if I run the following commands:

ddev start
ddev drush site:install --yes
ddev launch

as instructed from the "Contributing to Drupal CMS" page: https://git.drupalcode.org/project/drupal_cms/-/wikis/Contributing-to-Dr...

The most likely cause of this is that the first front page visit is creating the image style, this means the image is served via PHP, and then on safari specifically, something is wrong with the headers.

I don't have safari to test with, but someone who can reproduce this could check the following:

1. Are there any console messages from the first load of the front page - mis-matched mime type etc.

2. If you view the network tab (or safari equivalent I guess) when viewing the front page, what do you get for the image?

Browser shows:
[Error] Failed to load resource: the server responded with a status of 503 () (drupal-cms-hero.png.webp, line 0)

But this is more helpful from dblog:
Symfony\Component\HttpKernel\Exception\ServiceUnavailableHttpException: Image generation in progress. Try again shortly. in Drupal\image\Controller\ImageStyleDownloadController->deliver() (line 218 of /var/www/html/web/core/modules/image/src/Controller/ImageStyleDownloadController.php).

Backtrace:

#0 [internal function]: Drupal\image\Controller\ImageStyleDownloadController->deliver()
#1 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
#2 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(593): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#3 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext()
#4 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
#5 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(183): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#6 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#7 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle()
#8 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#9 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#10 /var/www/html/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle()
#11 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(201): Drupal\big_pipe\StackMiddleware\ContentLength->handle()
#12 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(138): Drupal\page_cache\StackMiddleware\PageCache->fetch()
#13 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(87): Drupal\page_cache\StackMiddleware\PageCache->lookup()
#14 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#15 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#16 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#17 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#18 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(709): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#19 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle()
#20 {main}

A quick search suggested this might be a memory limit issue, but it was already set to 1024MB. I tried increasing it to 2GB and it still happened so don't think that is the path to success.

@catch it’s not a true hero but a content image high up the page. I’m not sure there’s too much we can do about that without granular control of an instance. I’ll add a bullet point for looking at it to an existing checklist.

Did some more debugging and replicated the same behaviour below the fold so let’s steer away from the lazy loading theory.

@tonypaulbarker FYI it will be a true hero once we style it, right now it's just in the body because the page styling isn't done yet and the featured image isn't configured to display.

That exception is thrown only when another process is holding the lock on creating the image which should be almost impossible with a single user site.

Next step would be to add some debugging/logging in ImageStyleController where the lock is about to be required, and log a backtrace.

There's no image style pregeneration on cron like image_style_warmer is there? That could cause this, and generally is unlikely to work well on Drupal CMS sites because there's a high likelihood of them relying on automated cron module.

If it's not pregeneration, maybe something safari-specific is causing the image to be requested twice by the same page request?

We could look at adding some lock-wait-and-retry logic to ImageStyleController to make it less keen to send a 503, but should track down how this condition is getting reached at all first.