Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
This is something I really can't make my mind up on. I come from a WordPress background and the way it works there is you specify your image sizes in advance (for example, small, medium, large, xl) and the dimensions for each size. Then, when you upload an image it gets resized into all 4 sizes.
In my Laravel app I have taken the same approach. The image sizes and dimensions are specified in a config file.
The downside to this is that all images throughout the entire app share the same sizes and dimensions. Let's say on the front end of the website you want to show an image 300 x 300 pixels, but the stored small version is 150 x 150 and the stored medium version is 400 x 400, you would have to show the 400 x 400 version, which is 100 pixels bigger than you need it to be. In other words, there is no 300x300 size so you're always left serving the next largest size up.
I have seen some sites store a single image in its largest size, and then dynamically resize the image on the fly based on a width and height parameter (i.e. /images/supercar.jpg?width=400&height=400). I am guessing that the dynamically resized images would be cached so that the image doesn't need resizing on a subsequent request. The beauty about this is on the front-end I would be able to use specific and in some cases very unique image sizes, without being constrained to a set of particular sizes in advance. You can also change your image sizes later on and not have to resize every single image.
There are a lot of downsides though:
If a page has 50 images on it, that's a lot of images to resize on the first request. I think there is going to be a performance hit on the first page view for the first visitor.
On a big and busy website, the above point could have an adverse effect on the server load. Imagine the site owner adds 1,000 new products - those images would need to be resized and it would likely happen at a time not of your choosing.
To check if there is a cached version would by default require the whole framework to be booted for every single image on every single page, every time.
I guess you could get around the above point with a rule in the .htaccess file to check whether a physical file exists before passing the request to Laravel, or if you use a proxy such as Cloudflare the images would be cached there in a static form. But this approach seems fiddly to setup, and in the case of Cloudflare or similar CDN your app is then reliant on a third party.
So, what do you think? Is my current approach the best way? Should I switch to dynamic resizing or is it doomed to failure? Anything else I haven't thought of?
Thanks,
you need to choose option that fits your case the most
for example cloudflare has image storage with resizing ($5/month for 100k images) where you can change resolution, filters etc on the fly . But image has limit to 10Mb. If it fits your needs imo it is good option.
But if you want more control, have very large amount of images or images bigger than 10Mb, and know that you need only 2-5 sizes, you can resize on your onw using imagemagick and host all variants on r2/s3 other cdn
@garet I personally use the dynamic resizing approach, using Glide.
When a user uploads an image, I’ll do an initial resizing to a maximum of around 1,200 pixels wide (as user-uploaded images are never shown at a size greater than that). I’ll then use a combination of Glide and a CDN to generate a thumbnail with the requested dimensions, but then subsequent requests for the same dimensions will just be served by the CDN (AWS CloudFront in my case).
You do have that initial “hit” of the first visitor being the “lucky” person that triggers the resizing. You could get clever here, though. If you’re just uploading images to say, S3, then there’s nothing saying that your Laravel application has to do the resizing, and that you need to boot the entire Laravel framework in order to do the initial creation of a thumbnail. You could use something more lightweight like a Lambda function that would do the conversion instead with less of an overhead that Laravel handling the request would.
@restart93 @martinbean Thanks both for your replies.
I am slowly starting to come around to the idea of dynamic re-sizing because I can see the benefits versus being stuck with a bunch of static sizes. I also do server management though and know what it's like to get an SMS message at 3am in the morning saying "server load is at 50" :-)
Since typing out the question above it has got me thinking, why not merge both approaches?
In other words, when an image is first uploaded I could create the 4 initial sizes. As long as I only use one of those four sizes there would be no "on the fly" resizing as the image would be readily available already. However, if on some webpage somewhere I decide I really need a custom size I could go ahead and have it generate that size on the fly. My intention would be to store any resized versions so they are not resized again a second time.
I believe this is how CraftCMS does it (built on the Yii framework) - you specify your "transform" sizes in advance and these get generated when you first upload an image. But then you can request a custom size which would be created on the fly, at least first time around.
Does this sound like a reasonable approach?
@Garet You just need to weigh up effort versus reward. Is generating thumbnails grinding your server to a halt? If so, look at generating thumbnails up front. If not, then it’s not really worth worrying about and you’re just creating more work for yourself with no gain.
Please or to participate in this conversation.