Laravel Image Cache slower than source

Question

I am using Intervention/imagecache to cache my image. However the cache image load slower than the source image file. Almost extra 60-70ms in time latancy (Tested in chrome inspect element network)

This is the code how I load the image at Route.php

    Route::get('images/cars/{src}', function ($src){    
        $cacheimage = Image::cache(function($image) use($src){
            return $image->make("images/products/".$src);
        },1440);

        return Response::make($cacheimage,200, array('Content-Type'=>'image/jpg'));
    });

In blade

<img src="{{ URL::asset('/images/cars/theimage.jpg' }}" alt="">

Any thought or better way to store image cache?

Marissamarist

there's an issue on github about it github.com/Intervention/imagecache/issues/38 – Lucrative

I do made a comment at there as well – Marissamarist

Answer 1

I never used laravel, but this is a general issue.

If you let the webserver handle the delivery of the image to the client, the php interpreter will not be started.

If you deliver something via PHP (I assume, because you write something about a cached image), you need the php interpreter. Then you need to execute the script, and all its logic, which is in a scripted language always slower, then in native.

Your best bet is, to save the image on the file system, and link to it, instead of a PHP script.

This means for example:

Somewhere in your Application you have a point, where the original image is created. Now think about, what versions of it you need. Resize, crop, edit it as much you want. Save each version you need in your file system. So you have instead of image.jpg a image-200x200-cropped-with-branding.jpg. At this point, performance shouldn't be so much important (The image will be viewed thousands times, but only one time created).

You want to have

<img src="/path/to/image-200x200-cropped-with-branding.jpg">;

instead of

<img src="/image.php?param1=1&param2=2">;

Eiger

The PHP interpreter is one thing, bootstrapping a whole framework makes it even worse... – Slipsheet

what you said kinda make sense, seem like I have to use different approach then. – Marissamarist

I have same issue. Thanks @Christian your approach to this resolved the issue for me. +1 for you – Ointment

Answer 2

Just some additional thoughts, based upon the answer of Christian Gollhardt.

He is absolutely right, this is a general issue. But I did not like his approach of creating all the versions needed on creation (or upload) of the original image. Because there is one big problem, what if - at some point the future - you decide that your thumbnails should be 250x250 instead of 200x200 (or any other dimension)? So basically what I want is the flexibility offered by the ImageCache package without the performance drop off.

I haven't actually implemented this, but my approach would be to use some kind of - in between - helper function to include all your images within your views. In essence the helper function would simulate the functionality of the image cache, but instead of processing all that logic on the actual image-request it would be processed during the page-request. So at the time the actual image is requested from the users browser, every image version has already been created on the server and the link would point to the actual image on the filesystem. Some pseudo code explains it better ...

e.g. within a show_profile.blade view

<h1>{{ $profile->name }}</h1>
<img src="{{ image_helper($profile->image->filename, 'small') }}">

helpers.php

function image_helper($filename, $version) {
    if (!file_exists($version . '_' . $filename)) {
        // some other helper function ...
        create_image_version($filename, $version);
    }

    return "my/images/" . $version . '_' . $filename;
}

function create_image_version($filename, $version) {
    // if you want to go that route, you would need some kind of mapping
    // that maps the $version (string) to a codeblock that actually knows
    // what to do if that version is requested.
    // E.g. if the version 'small' is requested, 
    // create an image with a dimension of 100x100
}

Ornithine

This is realy nice, if you need to do it dynamicly. On the other hand, why not simple have an update script which runs a single time? (of course the orginal image would be saved too, in this case) – Eiger

An update script would be a possibility as well. I think it depends on personal preference or project-circumstances. Or whatever you can implement faster. Something to keep in mind though, if you go with an update script is, that you always have to pre-generate the new version for all your images. Whereas with the dynamic approach only the images that are actually requested from a user will be generated. So if you have lots and lots of images, I would prefer the dynamic way as you can save some disk space. – Ornithine