Openlibrary: Don't download 300+ book covers on the home page

Created on 25 Sep 2018  路  23Comments  路  Source: internetarchive/openlibrary

A book cover typically appears to be 10-30kb.
On the home page we download 306 of them.

We should use JavaScript to load the book covers off screen.

UI Good First Issue JavaScript Feature Request hacktoberfest

Most helpful comment

Hello, can I work on this issue? I will have to load images above the fold and lazy load other images right?

All 23 comments

@tfmorris explains a good solution here:

https://github.com/internetarchive/openlibrary/issues/1172#issuecomment-424596289

Hello, can I work on this issue? I will have to load images above the fold and lazy load other images right?

Feel free but note that this might be a tricky one!

Am not 100% sure of the right approach here myself but any experimentation or attempts to solve the problem are welcome!

Why don't you label as WIP: to let anyone comment on the process?

Here's the contents of my other note:

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
});

I'd like to see the above solution fail to work before declaring the problem non-trivial.

BTW, the images to be lazy loaded are both below the fold and to the right of the visible portion of the carousel(s).

@Abdulkadir98 unless I'm mistaken is new to this codebase like me, so I just want to make sure he knows what's he getting into.

@jdlrobson Yes, I have no clue where the frontend code lives

@Abdulkadir98 have you set up the repository on your local system?
@jdlrobson can we maybe update the Issue Description to point to the exact file where it can be resolved?

@salman-bhai Yes, I have cloned the repo but I'm getting an error when I run vagrant up in the project folder.
screenshot 70

@Abdulkadir98 that looks like a bug with our vagrant setup. We have had trouble with windows + vagrant in the past... But I don't think that's the problem this time :)

Would you be so kind as to try these setup instructions w/ docker instead?
https://github.com/internetarchive/openlibrary/tree/master/docker

We'll be happy to troubleshoot with you and answer all your questions along the way!
Thank you!

@hornc @cdrini in case you'd like to act on any of the docker feedback we get :)

if that screenshot is from windows os I think I have encountered this without success.

@Abdulkadir98 I'll be happy to help with the docker setup, let us know if you see the same issue, or have other problems, thanks!

Sadly, I don't own a windows 10 pro so I can't run docker on my computer. I am planning to install Ubuntu on my machine. I will let you guys know how it goes. Thanks a lot @hornc @mekarpeles

Oh, your issue is with line-endings and windows. I'm opening a separate issue for this because it is an issue: #1256

Oh, and @Abdulkadir98 , I'd recommend continuing with vagrant, but if you want to try docker, you might be able to use Docker Toolbox. I have Windows 10 home, and that's what I use.

@cdrini Thanks, I'll use vagrant once the error is resolved. In the meantime, I'll check out docker toolbox.

Since the last 10 messages have nothing to do with this ticket, perhaps it's time to open a separate ticket for this unrelated problem.

@Abdulkadir98 this was blocking me on #1241 so I had to tackle it.
Happy to help you find another task when you've got your instance setup!

Alright, I'll let you know once my setup is finished. Thanks! @jdlrobson

It looks like this is only deployed on dev so far.

The original benchmark is here: https://whatdoesmysitecost.com/test/180925_D4_d3656ac7448797bd0a46d8f277f3d6e2
I reran it here to provide a current baseline: http://www.webpagetest.org/result/181006_GX_5c2a1e3fd502df793344c1c940ba4a4f/
then ran it on the dev site here:
http://www.webpagetest.org/result/181006_RP_10299e74d6409663a7286c04705b33e7/

Page size is cut to less than half, from 4 MB to 1.5 MB, and number of requests is cut to less than 1/4 from 358 to 81. I suspect the size will be closer to 1 MB in production, because it looks like static/build/vendor-v2.js and all.js are being served uncompressed in dev at 772KB.

Is there a reason that compression isn't turned on in the dev server? These Javascript files are on the critical path for page rendering and the uncompressed download adds seconds to the rendering time (at least on mobile). Compression will cut bandwidth requirements by 2/3 and allow for more realistic performance comparisons with production.

The other big hit is all the cover images which are below the fold, thus not visible, but which are being loaded anyway.

In addition to the lack of compression for vendor-v2.js, it's also more than twice as big as vendor.js, even with compression. I'm not sure what else got added to it, but it might be worth reviewing to see if there's any fat that can be cut.

See #1162 about gzipping on dev. Comparing apples to oranges without it.

vendor-v2 is non render blocking. It's size is not important. Only for first interactive. Wont impact first paint.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nemobis picture nemobis  路  5Comments

jdlrobson picture jdlrobson  路  5Comments

cdrini picture cdrini  路  5Comments

BrittanyBunk picture BrittanyBunk  路  5Comments

LeadSongDog picture LeadSongDog  路  5Comments