Join Free
+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 20
  1. #1

    question about scaled images

    I'm needing to speed things up. I am pulling 100 images using 500x500 because I like to display a larger image for customers that show an interest in a product. So I display at around 200x200 and if they click on it I display it at 400x390.

    A speed test indicates that since I use a smaller image than what I am getting, it requires more bytes than is needed:

    << is resized in HTML or CSS from 500x500 to 400x390. Serving a scaled image could save 33.7KiB (38% reduction). >>

    Sorry for the ignorance, but there is no way I can request 400x390 from you right? That would require your storing the image at those dimensions, which of course would be impractical for you, right?

    I'm curious--would it speed things up if I displayed the images as 500x500 -- thus not requiring any resources to resize the image?

    Just trying to make sure I understand this issue.
    Last edited by tedm; 11-29-2014 at 07:11 PM.

  2. #2
    You can only request image sizes that we support. Scale it on your side, or use a standard image size that we provide.

  3. #3
    thanks, that's what I thought. I've been using 500x500

    Are some or many of the images returned by an api call of 500x500 not really that large?

    I'm asking because rendering 100 images using api call of 250x250 takes almost the exact same amount of time as when i use 500x500 (about 20 seconds with the connection I was using to test), and yes I was clearing the cache each time. I didn't expect that at all since the overall bytes would be almost 4x more with 500x500. can't figure that out and I could tell that it was returning the expected images - at least in some cases.

    The only other thing I can think of is that it slows things down when my program scales the image down--whether it be from 250 to 200 or 500 to 200.
    Last edited by tedm; 11-30-2014 at 09:44 AM.

  4. #4
    The scaling on your see is going to be what slows things down. We return the size requested.

  5. #5
    thanks. I thought the speed tests were stressing the need to pull down smaller files because the time to load big files was the concern.. it looks more like the time to scale down the big files is the bigger issue. I may end up displaying fewer, or pulling 250x250 and not scaling it, and then using ajax to pull any 500x500 if a user clicks to see any enlarged pics.

    EDIT: see next post-- this one seems wrong now.
    Last edited by tedm; 11-30-2014 at 03:50 PM.

  6. #6
    just wanted to share that I ran some tests all within a 15 min period, which seem to show that rendering a smaller image than what you retrieve doesn't seem to affect speed much at all. The size of the file retrieved seems to be the biggest factor. Not a perfect test because I didn't isolate it, but seems fairly clear as a result. Interestingly, the difference seemed more noticeable to me with this wi-fi test as opposed to a slower hotspot test. weird:

    100 images
    retrieved---scaled to---------time

    500------------200--------28 seconds
    500------------250--------26 seconds
    500-------------25--------26 seconds

    Last edited by tedm; 11-30-2014 at 04:43 PM.

  7. #7
    RE: what the PageSpeed/YSlow recommendation means there.

    If you have a big image and you "scale" it using HTML, it means that people's browsers need to download more data but display it at a different size. It's more optimized to physically resize the images to the size you're using on your browser, because this means the browser has less work to do and needs to download less to achieve the same result.

    Considering that most people have broadband, 37kb extra isn't much. Where it becomes a problem is when your site gets hit 800k times an hour. Then those 37kb means more CPU on server and more bandwidth. However, since Prosperent runs their stuff through a CDN, you shouldn't really worry about that too much because it gets offloaded to Cloudflare and a parallel query to retrieve the image is done when the browser loads it up.

    Focus on link building, you can always tweak this later to suit your own needs as things progress

  8. #8
    Thanks Acid. I noticed that for the online portion of my site I'm actually losing about 30% of my initial users before the page finishes loading and I think it is because my site is too slow in part because of the images. I think I'll move to 250x250 and then when the user clicks on one to display larger I'll use ajax to retrieve the larger image via the API. This will be my first foray into using AJAX, so am looking forward to it since it can be useful for future developments.

    If it doesn't speed things up enough I may try out Cloudflare, or replace some large sessions with a dbase call, or both.

    Have a marketer who is working on the link building aspect for me.

  9. #9
    Add cloudflare now. It's free and will help with all of the issues you have. It takes about 5 minutes to setup and requires zero code changes

  10. #10
    I was just about to last night and then I read that it caused someone a problem with both their cpanel access and using ftp - and I'm daily transferring files from my test site to the live site using filezilla...just dont need more problems...I can do it through my host (hostmonster) ...if it doesn't work can I easily go back??
    Last edited by tedm; 12-01-2014 at 01:11 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
coupons | coupons and deals