The biggest "best practice" that needs questioning is the excessive use of client side JavaScript. 90% of the websites out there would be able to provide all their functionality with server-side rendering, except that's considered unfashionable or something. I think it's partly web designers inventing fads to keep themselves relevant -- if you're a web developer, you have a financial incentive to try to persuade your customers that their perfectly working site needs redesigned every 3-5 years to feel "modern".
But as a user, that's not really relevant. I want to browse the web of 2004 on the internet connection of 2016.
So then how do you handle all your dynamic behavior, or are you actually suggesting we go back to the click-wait-click-wait paradigm of stateless web applications?
Having client side JavaScript should not really add much to the overhead. Yes, the initial load time will be larger, but every subsequent request will be quicker because the server doesn't need to generate the markup and send it along the wire on every click.
Using JavaScript rarely seems to fix click-wait-click-wait. It just replaces the browsers spinner with a javascript spinner.
Raw HTML provides prefetch hints. That, combined with fast servers and replication to ensure those servers are near your users, are all a fast website needs.
Of course if your website is actually an app then maybe it shouldn't be a website to begin with.
But as a user, that's not really relevant. I want to browse the web of 2004 on the internet connection of 2016.