/portal or root domain: which one to choose?

Most people will use /portal (or any other slug) and do it correctly. Long multi-level URLs depress me. Right now I’m writing a post with the address:

https://community.wpmanageninja.com/portal/space/community-meta/home
58 characters.

It’s tempting to remove portal, space and home. For images it’s even worse, because the subdomain also disappears, and https is out as well. What remains is a clean 16-character domain.

The only legal way to build a feed in 16 characters (or 5 if you are Elon with x.com) is to use the root domain. No /portal suffix. The instructions are on GitHub, but here is the core snippet (do not use without a backup):

define('FLUENT_COMMUNITY_PORTAL_SLUG', '');

User experience becomes cleaner. The problem: high server load. The Fcom script will load instantly for all users, guests and bots. This can trigger resource spikes and downtime if you don't monitor traffic.

This is the classic “angel vs demon on your shoulders” moment.
I’m not giving advice. I’m sharing what I’ve learned. My site is not in production yet, and I still think about these trade-offs.

If someone in the community has tested this setup and can confirm how reliable the Fcom cache is and whether running it from root creates real risks, it would be valuable to hear your experience. Developers’ comments on this would also help many users.

P.S.
I will keep using /portal for now.
Reason: reduce unnecessary CPU and RAM consumption.

Input: dynamic Fcom module.
Lever: limit how often the script autoloads.
Output: stability during traffic spikes.

A root-feed loads Fcom for everyone. This expands the load surface and hits the server even without real user traffic. Cache does not eliminate the risk.

Conclusion: the root option makes sense only for extreme URL minimalism. My priority is reliability.

But the torment over this decision still follows me to this day.