5 ms·
Regarding the payload size argument: If you’re pulling jQuery in from one of the popular CDNs (which you should be), your clients will almost certainly already
by jtdev 8y ago
Regarding the payload size argument: If you’re pulling jQuery in from one of the popular CDNs (which you should be), your clients will almost certainly already have it cached locally anyway.
Can you elaborate on the runtime overhead issue? If you write your own JS functions to replace jQuery, you’re still adding runtime overhead... and jQuery likely wrote a more efficient implementation to begin with; jQuery is battle tested and one of the most widely used pieces of software in history, what makes you think your code will have less runtime overhead?
- acdha 8y ago> If you’re pulling jQuery in from one of the popular CDNs (which you should be), your clients will almost certainly already have it cached locally anyway. Have you ever measured this on a large scale? I’ve never found it to be true because there are many CDNs, versions, and browser caches are not infinite. If performance is a priority it’s almost always faster to serve it directly to avoid things like the DNS and TLS latency from those CDN connections.
- jjeaff 8y agoPlus, I don't think a lot of the engineers on HN are actually even working on first page optimizations. If you are building an application that people are logging in to and using on a regular basis, you can afford a little bit of first load overhead which will then most definitely stay cached for the remainder of the session. All this talk of trying to skim off a few kb of load time only applies to extreme edge cases of landing pages with flighty potential customers.
- acdha 8y agoYes, it’s an oddly specific focus given how few sites have been optimized to the degree that a single cache-friendly resource matters. Given how many sites I run into where a single failure means that functionality breaks entirely, I really think it should be down the list.
- deleted 8y ago[deleted]