Saving and loading content takes way too long when multiple image styles are used

Created on 13 June 2022, about 2 years ago
Updated 4 May 2023, about 1 year ago

Problem/Motivation

During evaluating this module for a news website we experienced serious slowdowns on node and media pages when dealing with multiple images.

Steps to reproduce

1. set one image field to have multiple values and GCS as storage. Also, for faster testing, you can disable the required alt field.
2. set an image style or responsive image style for displaying the image field value.
3. upload at least 10 images. (this is the first place where the slowdowns occur)
4. click save.

After clicking save the user is redirected to the canonical node page, so the image styles are generated (probably). The user has to wait until every image is generated to get a response from the server. This takes more than 30 seconds sometimes. If a site has responsive image styles, then this process will run even longer because of the multiple image styles for multiple breakpoints. Also, if someone generates jpg and webp variants (with imageapi_optimize_webp), then again this needed time multiplies until infinity.

Proposed resolution

Think through that should this be the default behavior or not. Add possibility in the settings to generate image styles on the fly after the page HTML is loaded with some lazy-loading mechanism. The s3fs module tries to solve this by generating a different URL while the generated image doesn't exist.

We could use image_style_warmer to process specific styles later. But that could ruin the editorial experience if the content editors could not see the uploaded images in CKEditor and on the article pages immediately.

Remaining tasks

User interface changes

API changes

Data model changes

πŸ› Bug report
Status

Needs review

Version

1.0

Component

Code

Created by

πŸ‡ΈπŸ‡°Slovakia kaszarobert

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡§πŸ‡ͺBelgium DieterHolvoet Brussels
  • @dieterholvoet opened merge request.
  • Status changed to Needs review about 1 year ago
  • πŸ‡§πŸ‡ͺBelgium DieterHolvoet Brussels

    I encountered the same issue and after doing some research I came across ✨ Support delivering local image styles until remote upload is complete Needs work , an effort to fix this issue for all Flysystem adapters at once. Basically, what it does is this:

    1. If an non-existent image derivative is requested (any path starting with styles/), a temporary URL is generated to a Flysystem Drupal route (flysystem.image_style_redirect.serve). This URL is returned to the browser instead of the direct image URL.
    2. The browser requests this URL to get the image.
    3. A check is done to make sure the source image exists. If it doesn't, a 404 is returned and no further action is taken
    4. If in the meantime the image derivative was created (should be rare), redirect to the GCS URL.
    5. If the image still doesn't exist, generate the derivative and store it locally in a temporary folder. The temporary file
    6. is now sent to the browser without having to go through GCS. Once the response is sent and the image is displayed in the browser, Drupal will copy the temporary image to GCS.
    7. If the image is requested again and the temporary file still exists, that file is returned, which saves us a trip to GCS.
    8. Once the temporary file is copied to GCS, that url will be sent to the browser instead of the Flysystem Drupal route (flysystem.image_style_redirect.serve).

    In order to test this code you need to apply the merge request from ✨ Support delivering local image styles until remote upload is complete Needs work to your version of the flysystem module and the merge request from this issue to your version of the flysystem_gcs module. When leaving feedback, please do so first in the flysystem issue since this feature is largely being built over there.

Production build 0.69.0 2024