Changes at "Green ICT: improve Decidim’s performance"

Is your feature request related to a problem? Please describe.
Decidim is currently very resource heavy, both for the server as well as for the data networks that deliver Decidim’s front-end code to the end users. This makes Decidim hard to use when the network speed is limited (e.g. in some public spaces) and it also causes a lot more CO2 emissions for organizations running Decidim based websites.

According to different studies, the ICT industry uses between 4-10% of the total energy consumed around the globe and the amount is constantly growing due to the ICT ubiquity and the growing trends in the ICT sector, such as the increasing utilization of artificial intelligence.

References:
https://post.parliament.uk/research-briefings/post-pn-0677/
https://dl.acm.org/doi/abs/10.1145/3613207
https://www.devsustainability.com/p/paper-notes-ict-sector-electricity
https://lvm.fi/en/-/the-two-faces-of-the-ict-sector-consuming-energy-and-materials-while-also-paving-the-way-to-a-carbon-neutral-society-1210283

Describe the solution you'd like
Decidim should be as lightweight as possible both for the server to operate and for the end users to interact with.

\n
1. \n

   Start by measuring (start simple, use default production configuration):

   \n
   \n

   1. How much data is transferred to the end users from Decidim?

   \n

   2. How much transferred data is needed per minute of Decidim use?

   \n

   3. How many seconds or milliseconds of CPU use is required for serving one user?

   \n

   4. How many seconds does one user need to wait to interact with Decidim under a normal consumer level data connection service? Consider everything that happens for normal users (server response time, data connection time, website render time, possible unnecessary user interface “candy” such as animations, etc.).

   \n

   5. How much RAM is required for running Decidim for 100 users?

   \n

   6. How many CPUs are required for running Decidim for 100 users?

   \n
   \n
\n

2. Investigate which parts could be improved with least development effort, such as lowering the data transfer footprint with simple efforts that are easy to implement or lowering the CPU and RAM consumption by removing dead or unnecessary code. There are many changes that may have a large overall impact with very little effort.

\n

3. Implement the measurements to the normal development pipeline in order to see more quickly what kind of impact a certain change in the system makes for the overall performance, avoid changes that reduce the system’s overall performance (such as changing the software library to manage file transfers, which reduced the overall performance)

\n

4. Plan major changes in the software components and libraries more carefully and analyze their impact (good or bad) before making and releasing major changes

\n

5. Give more value to measuring the software performance rather than the number of features as an indicator of the efficiency of the development process and provide training about the Green ICT topic to the developers who are responsible of the software changes. Also note that all time wasted in the slow performance of the development tools is multiplied by the amount of developers interacting with the Decidim code base.

\n

Describe alternatives you've considered
Implementing one off performance fixes once the performance bottlenecks are noticed but it does not work well as this typically happens during very busy production workloads and therefore these fixes feel more like band-aids rather than well designed platform performance.

Additional context
This came from a discussion about the problems we faced during the last round of PB with a customer.

One example of such change that was not well tested was the migration from Carrierwave to Active Storage. While the technical reasoning could be there for such a change (e.g. dependency maintenance, more recent technology, etc.), having well tested and widely used \"legacy\" components should not be discarded only based on the fact that they are older. Typically the older the component is, the better it is tested and the better it works overall. Especially if the older component is still maintained well and does not pose any other problems (such as security issues), there is typically no reason to change that.

There has been also some prior discussion about these matters e.g. at regarding the front-end:
https://github.com/decidim/decidim/issues/13254

The redesign has not made the user interface lighter than the legacy versions, and on some parts it has made it even heavier, e.g.
https://github.com/decidim/decidim/issues/11178

I also know that in the past OSP has done some work regarding improving the performance under heavy loads but I believe most of that effort went into implementing caching in relevant parts of the use case (cannot find these resources anymore). Caching is not a solution to the problem, the performance needs to be good to begin with and after that, a well designed and engineered caching strategy can be implemented for further improvements beyond the default good performance without any caching.

Does this issue could impact on users private data?
No.

Funded by
N/A