Openlibrary: Can we compress book covers?

[jdlrobson]

https://openlibrary.org/ weighs 4.09MB.

A book cover typically appears to be 10-30kb. Pages which make use of many of them are currently very costly.

This explains how:
https://whatdoesmysitecost.com/test/180925_D4_d3656ac7448797bd0a46d8f277f3d6e2

Is there any way we can compress these images on upload or before shipping them to end users?

[salman-bhai]

I think problem is the number of bookcovers and not the size of the bookcovers right? Please do correct me in case I'm mistaken.

[jdlrobson]

I think it's a bit of both. My question here is about the size in bytes of the covers and whether we can compress these covers. If the answer is no it's okay to resolve this with that explanation.

See also #1170 and #1171

[tfmorris]

Yes, cover images can be compressed. Will it have a significant impact on performance? No.

The graph that you posted is pretty clear. Latency is on the order of 1 second per cover image, but download time is just a few milliseconds. Additionally, HUNDREDS of cover images are being downloaded when only ~50-60 are visible, even with a full page scroll. That's NUTS.

Non-visible images should not be downloaded. A reasonable number of cover images to download on initial page load is less than 20 (ie 3 carousels of 6 images apiece).

If you would like to repurpose this ticket for fixing the home page cover image loading performance, please feel free.

[tfmorris]

Actually, it looks like the solution is trivial. Just upgrade to slick carousel 1.7+ and use lazy loading:

// To use lazy loading, set a data-lazy attribute
// on your img tags and leave off the src

<img data-lazy="img/lazyfonz1.png"/>

$('.lazy').slick({
  lazyLoad: 'ondemand',
  slidesToShow: 3,
  slidesToScroll: 1
});

[jdlrobson]

Yes, cover images can be compressed. Will it have a significant impact on performance? No.

Sorry to suggest that it would have a significant impact on performance, that wasnt my intention. I agree #1171 will have far more of an impact (and thanks for finding out a way we can solve that! That's great!)

If you would like to repurpose this ticket for fixing the home page cover image loading performance, please feel free.

I would like to keep this open. Any compression we can do we should do. All bytes are important in my opinion.

I plan to add some tooling for our svg to compress them as part of #1170. Again that won't have as big a performance impact but it will keep our footprint down.

Are there strong reasons not to compress these covers?

[tfmorris]

Are there strong reasons not to compress these covers?

There are strong reasons to do the highest value items first. If, after the real problem is fixed, this is still high priority, I'm sure someone will work on it. If doing image compression distracted from fixing the actual problem, that would be a bad thing.

[jdlrobson]

We are now down to 0.98mb on homepage
https://whatdoesmysitecost.com/test/181231_BR_cef9cf389abfe9cd9149dd8b3ac129be

I still think that's a lot for what it offers and compressing covers will help with that
... but I'm not sensing that's a priority here. We can reopen this later in the year if necessary but i don't wish for this issue to rot in the github issues list.