The use-case here would be if you have so much css and js that loading it all externally pushes you past an acceptable loading time threshold. While inlining critical assets would technically solve this problem, figuring out how to extract and load critical css/js inline is incredibly labor-intensive, and often results in very fragile build processes. It's often less labor-intensive to start stripping out code altogether, or subbing-in slimmer solutions. For existing projects, I'd recommend looking for low-hanging fruit first to reduce your bundle sizes. I'll often look for huge libraries that are being underutilized. I had a junior add loadash and import _ from 'lodash' the other day because they wanted to capitalize a string. Devs will import all of bootstrap or tailwind because they don't want to learn css grid. Stuff like that happens all the time and can result in enormous bundles. (bootstrap's grid alone is >4000 lines of css) On new projects, nip this in the bud by having a perf testing pipeline : Every time you add a package, you'll get a record of what that package does to your performance. This can help train you and your team to not just thoughtlessly npm i your troubles away. Every piece of code you write or include has consequences, If you don't consider those consequences from the start of a project, you end up in this situation where google shrugs and says: "your app is so bloated that your only hope of getting acceptable performance is to inline code" This is getting into "old man shouting at the sky" territory, but sticking to good web development principles (the rule of least power, progressive enhancement, semantic markup, etc) makes this so easy. Answer from _listless on reddit.com