chore: optimize down the public/ dir png files - #2490
Open
jonchurch wants to merge 1 commit into
Open
Conversation
## Problem When looking at our cloudflare analytics today it called out a few images as offenders in our LCP. Our LCP is generally quite "good" with 70% of all requests under 2.5 seconds. But these images were called out as potential offenders, Im thinking its their weight Slimming down their weight should help pageload times where these images appear. My plan is to watch the LCP stats over the next few weeks to measure how much of an impact this change had. Specifically for the /5x/guide/writing-middleware/ page bc that was cited as the worst in a couple langs like Japanese. ## Solution This PR optimizes all our pngs in the public/ dir in place. | File | Before | After | Reduction | |---|---:|---:|---:| | `public/apple-touch-icon.png` | 3,557 B | 978 B | 72.5% | | `public/images/blog/redesign/before-after.png` | 435,879 B | 140,677 B | 67.7% | | `public/images/blog/redesign/brand-values.png` | 92,724 B | 36,181 B | 61.0% | | `public/images/blog/redesign/logo-favicon.png` | 47,064 B | 16,418 B | 65.1% | | `public/images/blog/redesign/vision-mission.png` | 82,218 B | 31,845 B | 61.3% | | `public/images/clustering.png` | 6,254 B | 3,696 B | 40.9% | | `public/images/express-mw.png` | 119,397 B | 36,423 B | 69.5% | | **Total** | **787,093 B** | **266,218 B** | **66.2%** | I ran all the pngs in the public dir through [pngquant](https://pngquant.org/) ```sh find public -name '*.png' -exec pngquant --quality 80-98 --skip-if-larger --strip --force --ext .png {} \; ``` in order to "quantize" the pngs. these are simple diagrams/logos mostly so they are pretty well suited to pngquant optimization. The `--quality 80-98` makes pngquant refuse to save any image that would fall below that quality floor. And I spot checked all the images manually against their previous versions and could see no difference. ### context Background on this is that anything in our public dir is not part of the astro build pipeline, so the images will not be optimized into webp like things in our src dir. This PR's in place optimization lets us see how/if our web vital stats are impacted by optimizing these images, without having to update any content pages to point to either new images (swapping png for webp for example) or a new image location. We can eventually move images into the src dir if we wish for anything added in the future to be optimized via the build process, so we dont have to do maual optimizations like this or think much about it in the future (there are also some drawbacks to letting astro handle the images for us, like it lazy loading images in markdown content etc which can actually hurt LCP).
✅ Deploy Preview for expressjscom-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When looking at our cloudflare analytics today it called out a few images as offenders in our LCP. Our LCP is generally quite "good" with 70% of all requests under 2.5 seconds. But these images were called out as potential offenders, Im thinking its their weight
Slimming down their weight should help pageload times where these images appear.
My plan is to watch the LCP stats over the next few weeks to measure how much of an impact this change had. Specifically for the /5x/guide/writing-middleware/ page bc that was cited as the worst in a couple langs like Japanese.
Solution
This PR optimizes all our pngs in the public/ dir in place.
public/apple-touch-icon.pngpublic/images/blog/redesign/before-after.pngpublic/images/blog/redesign/brand-values.pngpublic/images/blog/redesign/logo-favicon.pngpublic/images/blog/redesign/vision-mission.pngpublic/images/clustering.pngpublic/images/express-mw.pngI ran all the pngs in the public dir through pngquant
in order to "quantize" the pngs. these are simple diagrams/logos mostly so they are pretty well suited to pngquant optimization.
The
--quality 80-98makes pngquant refuse to save any image that would fall below that quality floor. And I spot checked all the images manually against their previous versions and could see no difference.context
Background on this is that anything in our public dir is not part of the astro build pipeline, so the images will not be optimized into webp like things in our src dir. This PR's in place optimization lets us see how/if our web vital stats are impacted by optimizing these images, without having to update any content pages to point to either new images (swapping png for webp for example) or a new image location.
We can eventually move images into the src dir if we wish for anything added in the future to be optimized via the build process, so we dont have to do maual optimizations like this or think much about it in the future (there are also some drawbacks to letting astro handle the images for us, like it lazy loading images in markdown content etc which can actually hurt LCP).