lite-youtube-embed

ube embed. I then found this, which claims to give a 224x performance increase over YouTube’s stock embed (and shame on YouTube for not improving it): https://github.com/paulirish/lite-youtube-embed In the past, I have written electron applications (I had tried Qt first, but had trouble figuring out how what I wanted after 20 hours of trying, and got what I needed from electron in 10). The electron applications are part of appliances that are based on the Raspberry Pi CM4. The electron application loads in a couple seconds on the CM4 (and less than 1 second on my desktop). Rather than using the tools web developers often use that produce absurd amounts of HTML and JS, I wrote nearly every line of HTML and JavaScript by hand (as I would have done 25 years ago) such that it was exactly what I needed and there was no waste. I also had client side JavaScript code running asynchronously after the page loaded. To be fair, I did use a few third party libraries like express and an on screen keyboard, but they were relatively light weight ones. Out of curiosity, I did a proof of concept port of one application from electron to WebKitGTK with around 100 lines of C. The proof of concept kept nodejs running as a local express server that was accessed by the client side JavaScript running in the WebKitGTK front end via HTTP requests. This cut memory usage in half and seemed to launch slightly faster (although I did not measure it). I estimated that memory usage would be cut in half again if I rewrote the server side JavaScript in C. Memory usage would likely have dropped even more and load times would have become even quicker if I taught myself how to use a GUI toolkit to eliminate the need for client side HTML and JavaScript, but I had more important things to do than spend many more hours to incrementally improve what already worked (and I suspect many are in the same situation). To give a final example, I had a POSIX shell script that did a few tasks, such as polling a server on its LAN for configuration updates to certain files and doing HA failover of another system were down, among other things. I realized the script iterated too slowly, so I rewrote it to launch a subshell as part of its main loop that does polling (with file locking to prevent multiple sub shells from doing polling at the same time). This allowed me to guarantee HA failover always happens within 5 seconds of another machine going down, and all it took were using concepts from C (threading and locking). They were not as elegant as actual C code (since subshells are not LWPs and thus need IPC mechanisms like file locks), but they worked. I know polling is inefficient, but it is fairly foolproof (no need to handle clients being offline when it is time for a push), robustness was paramount and development time was needed elsewhere. In any case, using C (or if you must, C++) is definitely better than a scripting language, provided you use it intelligently. If you use techniques from high performance C code in scripting languages, code written in them often becomes many times faster. I only knew how to do things in other languages relatively efficiently because I was replicating what I would be doing in C (or if forced, C++). If I could use C for everything, I would, but I never taught myself how to do GUIs in C, so I am using my 90s era HTML skills as a crutch. However, reading this exchange (and writing this reply) has inspired me to make an effort to learn.

ty-gap-... > There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too. Not clearly. Not clearly at all. --- Edit: note on the incompetence. If you embed Youtube player in your website, Lighthouse will scream at you for being inefficient and loading too many resources. Nearly all of those issues will come from youtube. Lighthouse will helpfully provide you with a help page [1] listing wrappers developed by other people to fix this. Chrome's "performance lead" even penned an article[2] on lazy loading iframes and linked to a third-party youtube wrapper which promises 224x speed up over the official embed. They know. They either are so incompetent that they cannot do the job themselves, or they don't care. [1] https://developer.chrome.com/docs/lighthouse/performance/thi... [2] Over at webdev: https://web.dev/articles/iframe-lazy-loading pointing to https://github.com/paulirish/lite-youtube-embed BTW. web.dev is created by web devs at Google. Promoting web development best practices. It takes it ~3 seconds to display a list of articles and the client-side only navigation is broken https://web.dev/articles