Assuming this task is about the SDAW-MediaSearch code project, hence adding that project tag so other people who don't know or don't care about team tags can also find this task when searching via projects.

You should compare Pagespeed insights reports to a well-optimised page, like a small popular article. We don't have a perfect score in general, as some of the suggestions are tradeoffs that aren't necessarily worth building. For instance, we do serve WebP thumbnails, but only for hot enough thumbnails traffic-wise. We don't do it for all thumbnails due to current storage constraints.

Also, newer formats aside, due to the nature of our on-demand thumbnail generation, we can't afford to optimise thumbnails as much as we could, as it would make cold cache hits very slow for users who request new thumbnails. Some of the best JPG optimisers have render times one of two orders of magnitude greater than our current settings. One day we will build an async image optimiser that goes through popular thumbnails and improves them which will give us the best of both worlds, but that's a big undertaking that requires brand new technical architecture.

For CSS/JS inlining, it's a tradeoff as well: inlining means reduced caching across pages. Pagespeed Insights tends to be blind to decisions that make things better when the average user experience is browsing multiple pages. In that case, the cache reuse across pages (probably) offsets the render-blocking nature in most situations. It's a recurring issue with synthetic performance testing tools that only look at a single page load in isolation. They will take an absolutist stance in their advice that assumes cache reuse between pages isn't worth it. Because they're online analysing a single page, the one you gave to the tool.

While Pagespeed Insights gives a great starting point, I would advise against trying to achieve a perfect score at all costs.

The fact that it identified unused JS is great and that's absolutely something to pursue, avoid loading modules that aren't used.

The image size advice it might give is also ignorant of our own caching tradeoffs: a slightly bigger image, albeit of a popular size, will be on average served much faster than an image of exactly the size your container needs but which will be very likely to be requested for the first time. Despite the better fitted smaller image being more lightweight. Pagespeed Insights can't take into account the fact that not all image sizes are cached/rendered equally in our environment and will therefore look for pixel perfection.

Copying information from @Etonkovidova in T271874 which has been merged with this task:

Click on the link - https://commons.wikimedia.org/wiki/Special:MediaSearch?q=tulip&type=bitmap.
Or refresh Special:MediaSearch page with the search results displayed.

The following issues are present

• The filters are not visible, but the tabs are visible
• When the search icon and the clear button become visible, the grid images start loading again.

The animated gif below captures the three issues above (it's recorded with slow network connection, but the issues are visible without throttling).

Note: I checked other pages (Special:Homepage, Special:Search, Special:RecentChanges, and Special:ContentTranslation - all of them display smoother loading (and re-loading).