Slick performance is a disaster in Core Web Vitals

Thank you.

> Slick performance is a disaster in Core Web Vitals
Please don't change the title, it is hilarious, anti-mainstream :)

Unlike other negative posters with 0 data, I think you are fair and good.

You provided some data, even very minimal. And you also identified the problem correctly.

I appreciated, honestly. You are not being offhanded with such a negative post.

> The biggest problem seems to be loading all the photo thumbnails from the slider in Slick. And 250 undelayed requests to the server must result in a negative result in the results.
You did identify the problem correctly.

Those thumbnails are indeed not optimized. They are just plain old images as meant for thumbnails which will of course hammer your server given 250 items, or so.

I even abandoned the idea to optimize those thumbnails from the early D7 devs, since they aren't worth any optimization due to being too small a size. Blazy is not even there.

But I think your use case may change my mind only if it is common.

Please reply any below properly so your OP may have more contexts to validate:

• Any screenshots of your Slick formatter, or Slick Views form? Be sure we can see everything, no hidden mysteries.
• Are you using plain or vanilla Slick EntityReference, Slick Paragraps, or even Slick Views? They may indeed lead to disaster too if you don't know how to optimize those images using Blazy as being warned about in the form items.

Existing solutions:

• It partly looks like a design problem to me. What about disabling thumbnail navigation option? Any betterment? Just try, don't refuse it without trying like the other guy on another issue, yet.
• You may want to consider "Loading priority" option properly. They offer you better optimizations given your image position in the viewport. Along with "Preload" option to even unleash the browsers' real power optimization. But never intended for thumbnail images so far. Only relevant for hero images. They are even more relevant for vanilla Slick.
• I am sure you knew this. But just in case a miss. If they are thumbnails, be sure you have a proper image style with sizes suitable for thumbnails, normally small. Logically, do not put large original images as thumbnails as it would defeat your optimization attempts.

You haven't answered all of my previous questions, so I re-highlight them below.

Obvious performance culprits

Slick optionsets:

• Autoplay will trigger immediate hammers, disable this and report.
• Autoplay speed and Speed is way too fast, faster than the recommended default values. You don't even give viewers a chance to see and enjoy your images.
• Enable Use CSS and Use CSS Transform so that browsers can manage and optimize transition and animation better than JavaScript alone.
• Infinite will even hammer your servers with tons of requests. Although most are cached by browsers, but Infinite destroys and recycles revalidates Blazy successful requests. Obvious hammers. Try disabling them. Slick is not intelligent enough with Autoplay, nor Infinite. It is not aware of its position in the viewport. Splide is. Splide answers all those Slick culprits very well. Even with Infinite thanks to its configurable clone constraints.

Slick formatter culprits:

• As said, try leaving Optionset thumbnail empty. And report back your findings. There are other alternatives to make galleries, see below.
• Change Image style "f" to "s" or "xs" if they meant "full", "small" and "extra small". Critical if using Responsive image. Otherwise the controller image controlled by Image style option will defeat Responsive Image optimizations. Or better leave it empty, and at your Responsive Image setting, choose "_empty image_" under Fallback for better performance to avoid hammerings aka double downloads. Also visit Blazy UI to optimize Responsive image globally with 1px.
• Change Loading priority to slider, or defer. The last is relevant for Autoplay below the fold. Almost similar to Splide delayed Autoplay, thus delayed image downloads, till visible on the viewport. But Slick is unfortunately less advanced.
• Enable Preload, only below the fold.

Design culprits:

• Placing Autoplay with massive images above the fold is an unevitable
  or even unfixable problem with the current Slick, or even Splide. Unless you ajaxified them, meaning putting them in chunked requests, says 40 each.
• Placing Autoplay below the fold is fine with Loading priority defer.
• Reduce both Speeds, enable Preload. Only Splide can do delayed Autoplay better and properly, at least till visible in the viewport.

> Maybe Slick is just a bad choice for a gallery this size?
Bad, with the current non-optimized thumbnails given massive amounts and with the above mentioned culprits. Unless you disable Autoplay, Infinite and thumbnails in the least. However gallery alternatives exist without thumbnails:

• Use Blazy Grid + lightboxes,
• or the inclusive Grid option with its revelant Display style along with Media switch option.
• Use Slick library v1.6.0 to minimize a few display issues with your current choices.

https://git.drupalcode.org/project/blazy/-/blob/8.x-2.x/docs/README.md?r...

Lessons learned
Potential future solutions, specific for non-optimized thumbnails:
Automatically change images to lazyloaded ones once its delta hits 9 or larger, and left the below 9 non-optimized as they are now. This has been done with Loading priority named slider. But they should bypass Blazy logic routines since thumbnails are less sophisticated than regular larger images. Patches are welcome if anyone beat me to it. Thank you.

> Is there anything I could do better?

• Aside from above mentioned culprits to address, Splide is way better than Slick as long as you know how to unleash its power.
• Alternatively, specific for massive images, and without AJAX, change your gallery design to use Blazy Grid + lightboxes. That would improve your performance a lot better.
• Be sure to read each form item description properly, and understand the potential pitfalls and or betterments.

The tools and options are there to make great performance, that is why it is Documentation. Failing to take their advantages or to understand them will lead to a disaster.

Normally defaults are already optimized and fairly good for common usages until you messed them up with difficult or problematic options.

Another common pitfall is the underrated Aspect ratio.

Yours is good, not empty. That is why it was not mentioned previously.

Aspect ratio is useful to minimize Layout Reflow in lazyload techniques prior to Native lazy. Still useful and relevant if you disable No JavaScript options at Blazy UI.

Layout Reflow can be exaggerated like painting a wall by destroying, not scraping, the wall first. Inefficient and costly. Aspect ratio keeps the wall to paint on in place and intact.

The most obvious OP bottlenecks are:

• Image style with large images when using Responsive image. It not only costs double downloads hammering your server, but also huge hammers with massive images on the browsers defeating the purpose of Responsive image.
• Autoplay which immediately triggers auto-downloads aka hammers. It makes lazyload, the tool of image optimization and performance, 100% useless.

Conclusion:
Negative posts so far are mostly due to misconfigurations -- failing to take advantage and understanding the pitfalls and benefits of the provided options. Only few are hater aka narrow-minded people problems.

Since they are just configurable options, reading and understanding the provided descriptions is a must.

Most pitfalls, not all, are already described in each form items. Ignoring them will obviously lead you to a disaster.

Basic understanding of performance subject with its own provided solutions, and common sense apply.

Above all, being aware of the options at /admin/config/development/performance is the very basic thing nobody should ignore.

Thumbnail optimization with massive HTTP requests mentioned above should be addressed by Blazy, not here. However seeing the OP misconfigurations, it is not a real bottleneck to worry about for most common usages at Slick.

Note:
Postponed due to too many dups on this subject, or in case any more inputs are needed like Aspect ratio above. Feel free to share your findings to benefit others after this comment.

This one is a good appreciable sample of constructive negativity nevertheless, so thank you again.

3.x is out.

Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....

Anyone concerned about performance should consider using data, docs, and proper tools in the light of the fundamental Drupal knowledge and the web vitals.

We had an intro talk on web vitals at Blazy some time before you posted this issue:
#3407144: Blazy 3.x Roadmap

Important!
There is also a link at Slick project home about performance benchmark. Just press CTRL + F at project home, and type "benchmark" to go to the link.

Extraordinary claim does require extraordinary evidence as they said, but so far we just don't want to boast anything, that is why the link is not so prominent. It is just a regular humble contribution anyway, IMHO.

However, be sure you know how isolation works and have something equal to compare with along with extreme condition and proper tools so to have better and purer benchmarking should you want to run your own benchmarking.

Blazy strived to address web vitals with its configurable options. Not all, not perfect either, but fairly serious and comprehensive. Not to mention those outside visible config, async decoding and the most underrated byte size where every byte counts I learned from mortendk.

Failing to understand web vitals will not only make Blazy options useless and absurd, but also may lead to a disaster as mentioned in this OP and hinted in that thread.

The same disaster applies to Drupal as well. It is a snail until you enable caches and asset aggregations at /admin/config/development/performance. Note the "performance" word at the end of the url. Failing to see to that performance page will equally lead to a disaster as seen at some invalid performance issues at this very project. Some people just don't know that performance page, and immediately jump posting wrong negativity which is not perfectly fine but also improper.

Again negativity would be fine if anyone had done their own homework in the least with fair data or benchmarks. That is why I still appreciated the OP regardless of the devastating title because he has done enough homeworks and showed more interests in having solutions than celebrating problems.

All this has been outlined in the contribution section at Slick, Blazy, etc. and their docs in general.

In short, always spend 5-15 minutes reading and understanding your "enemies" before attacking them blindly, or worse offhandedly.

That would save us both from unnecessary inconvenience and help improve contribution quality in the long run.

Feel free to update your findings should you have one.

Thank you.