WordPress.org

Making WordPress.org

Opened 8 months ago

Closed 7 months ago

Last modified 7 months ago

#5062 closed defect (fixed)

Add native lazy loading on theme archive images

Reported by: jonoaldersonwp Owned by: coffee2code
Milestone: Priority: low
Component: Theme Directory Keywords: performance
Cc:

Description

Theme archive templates, like https://en-gb.wordpress.org/themes/, load a lot of images - many of which are frequently initially outside the viewport.

We should add a loading="lazy" attribute to the <img> tags in these cases to force them to encourage them to only load when they're visible.

Change History (6)

#1 @dufresnesteven
7 months ago

I quickly tried to adding loading="lazy" as a progressive enhancement but it didn't work. I'm not super familiar with how it works under the hood, my guess is that our use of JS to inject the images triggers the immediate download.

If we are concerned about performance, we can look at reducing the postsPerPage. It's currently set to 24, which amounts to about ~500kb of images on page load. Larger viewports see 9 images at most. So we could set it to 12 ( 3-6 extra images downloaded on tablet+ viewports).

That property is provided to the page in the _wpThemeSettings configuration object.

#2 @coffee2code
7 months ago

  • Owner set to coffee2code
  • Resolution set to fixed
  • Status changed from new to closed

In 9630:

Theme Directory: Lazy-load images.

Props jonoaldersonwp, coffee2code.
Fixes #5062.

#3 @coffee2code
7 months ago

In 9631:

Theme Directory: Sync the postsPerPage value localized to the JS with value set via posts_per_page option.

In preparation of reducing pageload overhead by loading 12 themes at a time instead of 24. This change will allow JS and non-JS values to match and be changeable via WP admin.

Props dufresnesteven.
See #5062.

#4 follow-up: @coffee2code
7 months ago

At @dufresnesteven's suggestion, I've made a code tweak ([9631]) and then lowered the posts_per_page value (via the WP admin) to 12. We can adjust as necessary.

#5 in reply to: ↑ 4 ; follow-up: @dd32
7 months ago

Replying to coffee2code:

At @dufresnesteven's suggestion, I've made a code tweak ([9631]) and then lowered the posts_per_page value (via the WP admin) to 12. We can adjust as necessary.

Be careful as to how that impacts API clients (ie. WordPress), I believe clients should be passing a specific number, but I can't quite recall. Test a WordPress instance through a probably-not-cached query (Search or tags) after changing them.

#6 in reply to: ↑ 5 @dufresnesteven
7 months ago

Replying to dd32:

Replying to coffee2code:

At @dufresnesteven's suggestion, I've made a code tweak ([9631]) and then lowered the posts_per_page value (via the WP admin) to 12. We can adjust as necessary.

Be careful as to how that impacts API clients (ie. WordPress), I believe clients should be passing a specific number, but I can't quite recall. Test a WordPress instance through a probably-not-cached query (Search or tags) after changing them.

Good point. Definitely should be tested but should be low risk.

The only case where it won't fetch more items is if the page is not long enough and the window onscroll event is not triggered. Otherwise it may show all 12 on screen and on any movement will fetch the next page.

Last edited 7 months ago by dufresnesteven (previous) (diff)
Note: See TracTickets for help on using tickets.