Image Resize Functions Performance

[StephenOC]

Hello.

I am very new to ProcessWire and I am currently building our company website with it. For the most part I understand what is going on and understand how to use the API to get data from the database to the front-end, and I love the way it allows me to do exactly what I want without forcing me to do things 'the ProcessWire way' like other CMS' like WordPress do.

But I have a few questions regarding the Image Resize Functions and how they relate to the performance at the front-end of the site. For example, I have a blog view page where I have a full width hero image at the top of the page and I am looking to utilise ProcessWire's Image Resize Functions along with PictureFill to server the appropriate image to the user depending on their screen size. Now, in some instances the image I am serving - to a desktop with a retina display for example - is massive, 3840px by 1100px.

I am just wondering what would be the best way to go about this? Should I get the user (of the CMS) to upload an image of that size to the CMS and then let ProcessWire take care of all the other resizes? And if so, how long would that take to process before displaying the page?

Currently I have the following in my template:

<?php
    $mobile_2x = $page->blog_image->size(1464, 700);
    $mobile_1x = $page->blog_image->size(732, 350);
    $tablet_2x = $page->blog_image->size(2448, 640);
    $tablet_1x = $page->blog_image->size(1224, 320);
    $desktop_2x = $page->blog_image->size(3840, 1100);
    $desktop_1x = $page->blog_image->size(1920, 550);

    echo "<picture>";
    echo "<!--[if IE 9]><video style=" . '"display: none;"' . "><![endif]-->";
    echo "<source srcset='{$desktop_1x->httpUrl}, {$desktop_2x->httpUrl} 2x'" . ' media="' . '(min-width: 1240px)"' . ">";
    echo "<source srcset='{$tablet_1x->httpUrl}, {$tablet_2x->httpUrl} 2x'" . ' media="' . '(min-width: 768px)"' . ">";
    echo "<!--[if IE 9]></video><![endif]-->";
    echo "<img srcset='{$mobile_1x->httpUrl}, {$mobile_2x->httpUrl} 2x'" . "alt='{$blog_post->blog_image->description}'>";
    echo "</picture>";
?>

When I first loaded the page it took a long time to show, obviously this is not great for my users, or is it? Does it only take a long time to load once? I'm not sure how it all works...

Any advice would be much appreciated.

Thanks.

[LostKobrakai]

It's best to handle the actual resizing in code, but something like 3k x 1k images certainly shouldn't be resized on client requests. There are various topic here on the forms and two module (Thumbnails and CroppableImage) which handle resizing of images on upload rather than on request. Also for such large images you'd need to make sure the server does have enough ram available for php to actually process those images, because the images need to be loaded uncompressed into the ram (around 30 MB only for a single image of that size).

[kongondo]

Hi StephenOC,

Welcome to PW and the forums. What LostKobrakai said. Also wanted to add that ProcessWire resizes and caches the image (the variations you request) once to avoid doing it subsequent times

[StephenOC]

Hi guys,

Thanks for the feedback and advice. I didn't think my way was going to be the best way to do things. I'll have a look at the modules suggested and see which one best fits my situation, on quick glance the CroppableImage one looks good, but I will need to test it out.

Thanks again.

[bernhard]

hi stephenoc,

welcome to the forum. you can also resize images on ajax upload: https://processwire.com/talk/topic/3718-lots-of-images-to-resize-timeout-in-frontend/

could also lead to timeout / memory issues but just wanted to show the option

[Julie]

 I'd check whether all six image sizes are actually needed. Your template calls size() for every variation before rendering the <picture> element, even though the browser will only download the image that matches the device. I'd also check the actual rendered width of the hero before generating a 3840px version. If it displays at 1920 CSS pixels, that size makes sense for 2x Retina. But if the hero is narrower, you might be processing and serving a larger file than necessary.

I'd compare the first request with a cached one and check the server response time separately from the image download. That should help show how much of the delay comes from generating the variations versus loading the images themselves.

[Tiberium]

It is necropost here but for the argument sake: 

3 hours ago, Julie said:

 I'd check whether all six image sizes are actually needed. Your template calls size() for every variation before rendering the <picture> element, even though the browser will only download the image that matches the device. I'd also check the actual rendered width of the hero before generating a 3840px version. If it displays at 1920 CSS pixels, that size makes sense for 2x Retina. But if the hero is narrower, you might be processing and serving a larger file than necessary.

I'd compare the first request with a cached one and check the server response time separately from the image download. That should help show how much of the delay comes from generating the variations versus loading the images themselves.

That sounds very over complicated. And why someone should manual compare if the request has a cached one? ProcessWire will create the variants one time and then saved them along the image. You can see the saved variants in the backend behind every image and how big they are and how much compressed they are. So after the variants where created on a frontend call, the next call don't will perform the re-size again.

The Problem is a one-timer when many new big image are uploaded and the frontend gets called the first time in that status. For that bernhand linked a solution, there is also a module who then delayed the creations in frontend, so ProcessWire will only re-sized a manageable part.

The easiest and efficient solution is, to activate the ImageMagic module, that re-size process is much faster as the php-gd one. Since then even 30 MB big images are getting fast variants creations.