I tested UNA 14 on a high-performance server equipped with 256 GB of RAM and 36 processors 2 NVMe in raid 1, with only a single user online. The results remained THE SAME. Regardless of the available computing power, UNA 14 is still in development, and until the development team optimizes the script, no significant performance improvements can be expected.

By comparison, UNA 12 operates roughly five times faster, achieving sub 1 second loading times. UNA 14, however, consistently underperforms and appears fundamentally flawed by design.

I also experimented with various caching and optimization solutions, including Memcache, Dragonfly as a front-end, and Redis, but none produced measurable improvements. In practice, it is comparable to trying to tow a Fiat with a Ferrari raw power cannot compensate for an inefficient design.

In addition, UNA 14 contains numerous errors, and the official mobile applications for Android and iOS (GitHub repository) have not been updated in over a year. Until the much-publicized UNA 14.1 with Neo is officially released, I do not expect any meaningful improvements.

Therefore, if you are considering building a project with UNA, the only realistic options are to wait, as the rest of the community is doing, or to use version 12.X,X. However, it is important to note that UNA 12.X,X also has known security vulnerabilities. At this point, the platform offers limited practical use beyond testing or experimenting for learning purposes . Time will ultimately reveal whether future releases can deliver real progress.

A slow-loading site quickly frustrates users and drives them away. Performance is critical no matter how good your content or features are, if pages take too long to load, user retention drops dramatically. Therefore, I do not see any real commercial use for this script right now. It’s only good for kids to play around with.

However, if you have sufficient resources, you should deploy each component separately for example, databases on one server, the messenger service on another, caching on a dedicated server or cluster, and media files stored on a dedicated storage cluster (e.g., Ceph, GlusterFS, or MinIO). Each application can also run on its own cluster, allowing you to scale and optimize every component individually.

To achieve high performance, interconnect the servers or clusters with a high-speed backend network (10–100 Gb/s) and manage the deployment with orchestration platforms such as Docker Swarm or Kubernetes. Splitting each application is essential to optimize performance; installing everything on a single server will inevitably lead to slow performance.

Additionally, implement an Edge CDN for caching to reduce latency and offload traffic from the backend, ensuring faster content delivery to end users.

The problem, however, remains the same: you still need to deliver the same amount of data to the end user. Since the current script is not optimized, these measures alone are insufficient, making the setup largely ineffective for real-world use.

NOTE: This is my personal opinion.