gchq
7.5 Content Search crashes on `*`
Maybe just needs some caching and improved css?
Even tmdb loads all credits on a single page: https://www.themoviedb.org/tv/1431-csi-crime-scene-investigation/cast
Maybe just needs some caching and improved css?
Even tmdb loads all credits on a single page: https://www.themoviedb.org/tv/1431-csi-crime-scene-investigation/cast
Did some testing, seems like the backdrop-filter on hovering is the cause of the lagging and unresponsiveness when there is a large amount of entries. Tried caching the meta, there was a small performance gain, but nothing major from my limited testing. Maybe you have better methods and code.
Also tried the lazy loading with livewire, and the page loads "instantly". With a nice loading cast member :)
Thanks for looking into this. backdrop-filter is very likely to be causing it since it's a relatively new CSS property that probably isn't properly optimized yet. Do you notice a difference using it between browsers (safari vs chromium vs firefox)? Maybe worth reverting that from a blur to only opacity that I implemented previously for browsers that didn't support the blur. Also try something like CSS' contain: content as well: https://developer.mozilla.org/en-US/docs/Web/CSS/contain.
Regarding livewire lazy loading, there's no bottleneck server-side. I just tested curl'ing it and I receive a response in less than a second. But browser loads for 10+ seconds. It's purely a client-side rendering bottleneck. Therefore I don't think livewire's the right solution in this case. Infiniscroll and removing credits above as you scroll down might be a good alternative, but I ran into issues last time I tried it with livewire and concluded it needs custom js + api endpoints to get it working properly (the way it keeps states it will eventually be sending 2MB+ of data back and forth every request). But that still doesn't optimize cases where only a dozen credits are shown... in which case optimizing the CSS would be a better solution.
If adding contain: content to .meta-chip fixes it for you, that'd be great. If it doesn't, try removing these lines (and the following closing curly brace): https://github.com/HDInnovations/UNIT3D-Community-Edition/blob/5125cd33d6c05027f5c2ac16cbeba192dc44ad39/resources/sass/components/_meta.scss#L306-L310. Hopefully one of those 2 fixes it.
Try lazy loading the actor images.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#loading
loading="lazy"
https://github.com/HDInnovations/UNIT3D-Community-Edition/blob/5125cd33d6c05027f5c2ac16cbeba192dc44ad39/resources/views/torrent/partials/movie_meta.blade.php#L205-L206
Try lazy loading the actor images.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#loading
loading="lazy"https://github.com/HDInnovations/UNIT3D-Community-Edition/blob/5125cd33d6c05027f5c2ac16cbeba192dc44ad39/resources/views/torrent/partials/movie_meta.blade.php#L205-L206
Forgot to say that in my first reply, Adding lazy loading to images helped a tiny bit.
contain: content does not seem to help.
I did some testing in different browsers.
My main browser Brave Version 1.69.160 Chromium: 128.0.6613.114 (Official Build) (64-bit) (same in incognito) its slow AF to render and laggy, basically the reason i reported.
Edge Version 129.0.2792.52 (Official build) (64-bit) it a bit faster to render but still laggy.
Chrome Version 129.0.6668.59 (Official Build) (64-bit) its faster then edge but still laggy,
Firefox 130.0.1 (64-bit) its perfect, it renders everything "instantly" and there is no lag.
Mobile browser seems to be "instant" aswell.
Adding these fixes the lag issues. Now to find out why the rendering is slow.
will-change: backdrop-filter, background; to .meta-chip
will-change: background; to .meta-chip__icon
Seems like the slow rendering seems to be located in the meta__chip-container class.
Possibly related to: flex: 1 0 200px;
.meta-chip:hover {
/* backdrop-filter: var(--meta-chip-backdrop-filter-hover); */
/* -webkit-backdrop-filter: var(--meta-chip-backdrop-filter-hover); */
background-color: rgba(255, 255, 255, 0.13);
}
@LostRager if you comment out the resource intensive (per stack overflow) blur and just use background-color is everything all good?
.meta-chip:hover { /* backdrop-filter: var(--meta-chip-backdrop-filter-hover); */ /* -webkit-backdrop-filter: var(--meta-chip-backdrop-filter-hover); */ background-color: rgba(255, 255, 255, 0.13); }@LostRager if you comment out the resource intensive (per stack overflow) blur and just use background-color is everything all good?
That also fixes the lag issues, yeah.
I also figured out where the slow render problems is. overflow-y: auto; in meta__chip-container is the culprit. Setting the value to overflow-y: scroll; instead signifigantly inproves the slow render time. Still not "instant" tho, like firefox.
Adding transform: translateZ(0); to meta__chips also seems to increase the render speed even more.
It's probably best to remove the blur css for background color or alike and then limit cast and crew to 10 and auto load more on bottom of scroll.
It's probably best to remove the blur css for background color or alike and then limit cast and crew to 10 and auto load more on bottom of scroll.
As mentioned earlier, last time I tried implementing infiniscroll in livewire, it did not play nice and maxed out the 2MB request size limit after awhile. It will probably require a custom api with proper range paging that might be overkill for this.
It's 2024. Browsers should be able to load 10000+ cards where each contains a photo, a name, and a position without breaking a sweat. Just some of my css I originally used wasn't well optimized for scale in modern browsers and hits some bad edge cases that I wasn't aware of at the time. Thank you @LostRager for digging in.
Wow. I was using firefox to debug, but it just got to me that Chrome is the one that feels like I'm using a calculator to browse this page...
Definitely a Chrome bug. Chrome's already been loading for 2+ minutes while I'm writing this and the page isn't loaded yet. Firefox is instant in comparison.