I worked for many of those and... it is more complicated. When you are a small team, it is easy to create a performant site because you work in a tight circle

I worked for many of those and... it is more complicated. When you are a small team, it is easy to create a performant site because you work in a tight circle with shared conventions, rules, etc. and it is always the same people that work on the project. When you are a large organization (think Facebook blog), there will be hundreds of engineers/designers/copywriters/... that are exposed to the codebase over the course of many years. Each will need to make a 'quick change' that over time compounds into the monstrosities that you are referring to. The best you can do is add automated processes into CI/CD that prevent shipping anything that does not meet certain criteria. This might hold for a while... but as soon something borks the shipping velocity and some higher-up starts asking for names, those checks will be removed "temporarily" to unblock what that's burning. As an engineer who takes pride in developing accessible and performant software, this killed the drive/joy for me of working for large orgs.