While implementing third-party resources has downsides for performance and you should self-host your assets when possible, sometimes relying on external files is unavoidable. But be warned — using them can sometimes cause real headaches.
New web services are being built to a self-defeatingly low UX and performance standard, and existing experiences are now pervasively re-developed on unspeakably slow, JS-taxed stacks. At a business level, this is a disaster, raising the question: why are new teams buying into stacks that have failed so often before?
I guess the point I’m making in a way here is that I could never win a “dev race” because it takes me ages to even get to the point of writing code and that’s been the case for a lot of years now. The benefit to being like this though is I get to put out fires before they even start.
Designing, developing or leading a web project (or an app) have inherent constraints, and adding to them might take time and resources you do not have. On the other hand, avoiding non-quality can bring you much in lost revenue through better position on search engines, better compatibility, speed and accessibility leading to a lesser quit rate, or better word-of-mouth following great after-sale service.
If nothing else, my hope is that this post helped shed some light on the fact that LCP is, by its very nature, a dynamic metric that is heavily dependent on user behavior. You can’t always know ahead of time what the LCP element is going to be for a given page, so it’s important that your optimization techniques can handle a range of possible outcomes, and adapt accordingly.