Skip to content
This repository has been archived by the owner on Feb 22, 2023. It is now read-only.

Image thumbnail improvements (dimensions, compression) #531

Closed
zackkrida opened this issue Feb 24, 2022 · 0 comments · Fixed by #630
Closed

Image thumbnail improvements (dimensions, compression) #531

zackkrida opened this issue Feb 24, 2022 · 0 comments · Fixed by #630
Assignees
Labels
💻 aspect: code Concerns the software code in the repository ✨ goal: improvement Improvement to an existing user-facing feature 🟩 priority: low Low priority and doesn't need to be rushed
Projects

Comments

@zackkrida
Copy link
Member

Problem

Currently on the frontend, there are two optimizations we could make with thumbnails:

  • Thumbnails are 600px wide at their largest dimension; On the frontend thumbnails are rarely larger than 300px. Display size is a factor here, but one I need to test more.
  • Thumbnails could benefit from some lossy compression. Using tinypng.com I was able to give this thumbnail:

https://api.openverse.engineering/v1/images/3fa11800-4907-43d0-9921-52ed5ddb22aa/thumb/

a 56% size reduction with minimal obvious visual differences:

image

GitHub may apply compression, I'm not sure, so you might want to run this test yourself.

before after
dog-thumb dog-thumb

Description

While images are pretty "cheap" for browsers, compared to something like JS, because they don't need to be parsed, and
we're employing lazy-loading in Openverse, this would not really effect the percieved performance of the site. Or if it did, it would likely de negligible. However, it would significantly improve the number of real bytes transferred to users, and that's always a wonderful thing.

This could be a good opportunity to give our thumbnail cache some basic sizing options, because then we could also use it on the single result pages, instead of hotlinking to our 3rd party providers.

@zackkrida zackkrida added 🟩 priority: low Low priority and doesn't need to be rushed 🚦 status: awaiting triage Has not been triaged & therefore, not ready for work ✨ goal: improvement Improvement to an existing user-facing feature 💻 aspect: code Concerns the software code in the repository labels Feb 24, 2022
@dhruvkb dhruvkb added this to Backlog in Openverse Feb 24, 2022
@krysal krysal removed the 🚦 status: awaiting triage Has not been triaged & therefore, not ready for work label Feb 24, 2022
@dhruvkb dhruvkb self-assigned this Apr 6, 2022
@openverse-bot openverse-bot moved this from Backlog to In progress in Openverse Apr 6, 2022
Openverse automation moved this from In progress to Done! Apr 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
💻 aspect: code Concerns the software code in the repository ✨ goal: improvement Improvement to an existing user-facing feature 🟩 priority: low Low priority and doesn't need to be rushed
Projects
No open projects
Openverse
  
Done!
Development

Successfully merging a pull request may close this issue.

3 participants