Website is too complex (eco-design)

[sduperret]

Hello everyone,

I am creating this issue to start a reflection on the complexity of displaying the website index page, which contains more than 33,000 items according to this report: https://www.ecoindex.fr/en/result/?id=145bce69-110c-4e6a-a68f-0a800352e69b

I think it would be beneficial for those of us who have a low-powered machine, or a bad internet connection, to try lazy loading or limiting the display to a home page and not the full list.

What do you think?

Link of the report (not permanent) : https://www.ecoindex.fr/en/result/?id=145bce69-110c-4e6a-a68f-0a800352e69b
To make a new report : https://www.ecoindex.fr/ (and then type the url of the website)

[sduperret]

poke @untypequicode

[nodiscc]

Hi,

to try lazy loading

Our current static site rendering tool is sphinx which doesn't support "lazy-loading" the DOM.

Adding this feature would be a complex task, and would probably require the addition of javascript to a relatively JS-free site (it even works with JS disabled), which would come at the cost of additional CPU cycles on all clients, costs which are, in my humble and baseless opinion, greater than those of "just" loading a large DOM.

That said, if someone would like to go through the process of adding this feature to sphinx, and provide a decent comparative benchmark with loading times/bandwidth use/CO2eq footprint, I would consider adding it. IMHO just the food, coffee and electricity consumed working on this task would negate any possible energy savings in the grand scheme of things; but I'd like to be proven wrong.

Strictly speaking about bandwidth, the HTML weighs 230kb, followed by the favicon at 17kb, followed by the furo and sphinx-design stylehseets at 17 and 10kb. But I realize this discussion is about DOM complexity, which possibly could (how?) be optimized.

The 3 svg badges are only 10-15kb but trigger supplementary HTTP requests to different hosts and browser SVG rendering code, which probably (again, how to get a sensible measurement?) amount to bigger energy costs and loading times than DOM parsing.

In fact, if you run the Firefox performance profiler, you quickly realize that most CPU time is not spent on DOM rendering but on other tasks.

Edit: the DOM is large because there is simply a lot of data to display, the median of 693 and goal of 600 displayed on ecoindex.fr do not make sense if they do not take into account the type of website we are looking at. https://www.ecoindex.fr/en/how-it-works/ says this is taken into account, but there is no actual indicator/exaplnation of what is used to compute these targets. A simple company website landing page should be well under 300. Awesome-selfhosted lists 1227 software items so I don't see how we could hope of reaching these numbers.

In short, I think purely looking at DOM complexity is the wrong approach, even if I agree with the premise of the tool (simple websites are better).

low-powered machine, or a bad internet connection

Is there any evidence that the site is slow to load on e.g. a low-powered ARM box? It is quite fast even on my old-ass Samsung phone from 2016 which struggles on the majority of websites. Again, what potential load time/bandwidth/energy savings are we talking about?

display to a home page and not the full list

What do you suggest? A relatively empty page with a single "Click here to see the full list" would defeat the whole purpose of this issue.