Fixed Development roadmap topic won't load sometimes

Device: PC
Browser: Chromium 92.0.4515.159
OS: GNU/Linux, Artix, kernel 5.13.12

Steps to reproduce: open feedback/development-roadmap-t101.html

Anything else to add:

Could you be a bit more specific
or add a screenshot? Do you get a server error? Are you using chrome extensions such as an adblocker? What doesn't load - the whole page or just a section of it?

It just wasn't loading the page. I have adblock, but disabling it didn't change anything. Now it loads, but the tab freezes after a few seconds. While recording a screen capture to show this Chrome displayed the "website is not responding" popup, so it's probably some JS running in a loop:

I was experiencing similar problems on sites until I disabled adblock, but you say it didn't have an effect?

Maybe try an incognito browser to rule out caching issues? Possible its a linux/chromium thing i guess.

Okay @klh I'll try to reproduce this and fix if I can next patch.

BMAY wrote: 3 years ago

Maybe try an incognito browser to rule out caching issues? Possible its a linux/chromium thing i guess.

Tried incognito, same thing. Tried Firefox and it's flying, so this may be a Chromium or a Chromium/Linux thing.

EDIT 09/16/21:
Tried profiling, I guess Chromium's profiler doesn't have a RAM cap since it ate it all

This may have something to do with the number of posts there and the fact that JS modifies every post element on scroll. @Teebling couldn't the layout be done with just CSS? Actually the whole masonry thing could be done in plain CSS too.

Probably related too: all icons are blank for a fraction of a second, not sure why since I see they are loaded from cache.

On the topic of JS: one of the libraries (scotch-panels) hasn't been updated in 7 years (not sure how the licensing works in this case )

klh wrote: 3 years ago

This may have something to do with the number of posts there and the fact that JS modifies every post element on scroll. @Teebling couldn't the layout be done with just CSS? Actually the whole masonry thing could be done in plain CSS too.

I began with a CSS grid, but to get true masonry you need JS on top of that. CSS can't handle variable heights on its own. Columns sure, but not heights.

It's probably cause of the huge amount of autolinks on that page - something I'm working on 'lazyloading' so that only what's in the viewport will generate tooltip autolinks.

klh wrote: 3 years ago

Probably related too: all icons are blank for a fraction of a second, not sure why since I see they are loaded from cache.

This is because the site lazyloads images so that you don't request all 500 base item graphics in one go, only what's in the viewport at the time

Teebling wrote: 3 years ago

I began with a CSS grid, but to get true masonry you need JS on top of that. CSS can't handle variable heights on its own. Columns sure, but not heights.

Since you already have "ragged edges" this would work (flexbox, not grid). Or the next solution that uses primarily CSS with some JS (calculation still happens in the browser engine, not JS).

Teebling wrote: 3 years ago

This is because the site lazyloads images so that you don't request all 500 base item graphics in one go, only what's in the viewport at the time

Yeah, but after the first load they are cached, so there shouldn't be a flash.

klh wrote: 3 years ago

Since you already have "ragged edges" this would work (flexbox, not grid). Or the next solution that uses primarily CSS with some JS (calculation still happens in the browser engine, not JS).

I already read this article and gave it a shot, right at the beginning of developing the UI, but it's just not dynamic enough. Please bear in mind that this is not just about the layout itself, its also merged in with filtering, sorting, searching and all kinds of other frontend/backend integrations. CSS grids and flexbox are amazing but they are not suitable for what these pages are used for. They fall short.

klh wrote: 3 years ago

Yeah, but after the first load they are cached, so there shouldn't be a flash.

Yes, they are cached, correct. That doesn't mean that the lazyloading library (lozad) isn't going to behave any differently though. The page loads, lozad uses intersection observer to see if any elements with the lozad class are in the viewport, then changes data-src attributes to src attributes, loading the images on the fly. That's the 'flash' you're describing.

Native browser lazy loading is more sophisticated than the JS solution I'm using, and wouldn't have this issue, but only a few browsers support it at the moment.

@Teebling , you could probably minimize the flashing by using a placeholder image. Either layer the real one on top and using an opacity transition to

Fade the placeholder out as the actual image fades in. Or just swap them without the

Fade transition and just add a width/height transition so the bounding box grows over time rather than snapping larger/smaller instantly.

Also for all the small item thumbnails, you can probably change it to use a sprite. Be a larger initial download, but I imagine would significantly speed up the load on pages with a lot of them, and after it is cached it would be perceivably no worse on pages with only one thumbnail.