Description
This is a comment originally posted by @sneakers-the-rat about why our website is slower to load. the items that Jonny mentioned below seem like things we could fix / chip away at.
i was curious so i went and checked out some stuff that was contributing to page perf probz.
we start here-ish:
- Transcoding the images did help a bit, i was able to go from 568k -> 49k and have it still look ok with this
magick header-mentored-sprints-smaller.png -quality 50 -resize 75% -define webp:image-hint=photo,method=6 ./header-mentored-sprints-smaller.webp
other things roughly in order of impact, i was not being scientific
-[ ] turning off all the css animations: the major thing that's causing the largest contentful paint to be so slow is that there are several reflows of the page, and when the animations all have a delay to them that sometimes coincides with when the image is ready to render, then it has to do another reflow it looks like. idk didn't look too close
-[ ] removing the filter on the header image had a surprisingly large effect on fcp - we should just apply that filter to the image itself since it's just dimming it
-[ ] make all the images that aren't the header do loading="lazy"
and it seems like the last remaining stuff is just from not having the rendering path optimized from stuff flying in without fixed sizes and causing reflows. the thing that happens right before the LCP looks like it's triggered by matomo tracking. so i would put that in the footer and maybe even wait until the page is fully loaded to fire.
also i bet if we set more fixed heights to the major structural elements with position relative i bet we could speed that up a bit too
anyway i ended up here which is not great but sort of ok
Originally posted by @sneakers-the-rat in #373 (comment)
Metadata
Metadata
Assignees
Type
Projects
Status