131–140 of 145 posts
Earlier quoted context omitted.
People need to stop saying this.
Please elaborate.
I would be willing to bet that among just the top 1,000 sites, a user would be required to have 25 to 30 copies of jQuery cached to cover all the sites.
I know it's awfully tempting to obsess on something that is easy to measure , like file size. I also know it's tempting to imply things like "twice the file size means twice the page load time". But it's not true. It's NOT true. Look at this video at 6m30s: http://channel9.msdn.com/Events/Build/2012/3-132 Productively optimizing a web page is no different than optimizing any other code. If you want to know why a web…
There's only one way to make a tiny page that loads super fast - and that's to make every single decision with an eye towards efficiency. People who say "hey, what's an extra 30KB for one library? It's only like 10x larger" will tend to reach a similar conclusion at every decision point. And that's why the internet is full of massive, bloated, slow web pages. Single decisions don't cause bloat. Bloat comes from a sla…
That sounds dangerously like premature optimization. For example, why spend the time creating optimized image sprites if it turns out they don't contribute significantly to load time? It's better to spend development time doing something else.
> And that's why the internet is full of massive, bloated, slow web pages. Single decisions don't cause bloat. Bloat comes from a slack attitude towards efficiency.
By using the word "bloat" it sounds like you're talking about bytes. Again, byte counts often aren't always the main culprit in slow loading of web pages. Synchronous scripts and/or 302 redirects can be much worse, for example. Don't start with the premise that the bytes are the problem and do a lot of work to reduce them, only to find out it isn't the problem. Profile the page load and see what is really the problem. Then fix that.
Earlier quoted context omitted.
Focus on speed and modularity next to the clear code sounds interesting, but supporting IE 9+ only is kind of a bummer here, because it means "no" for XP users (I use XP64 on my desktop for instance) and there is still substantial number of them. (And I do curse Microsoft for making IE 9 Vista+ only browser, which is quite likely explainable by use of some shiny new undocumented API, that wasn't available in XP and b…
It does support it if you include es5-shim, though IE8 is effectively dead. It's at Firefox, Chrome and Opera are available for Windows XP :)
I seriously doubt the reasons Microsoft gave for not supporting it are valid. Even if the sandbox mode could not be used there is no reason why the browser and rendering engine could not run on XP if the proper system DLLs were present, and these could have easily been included with the install as Microsoft does in many other cases.
Earlier quoted context omitted.
Test this, you might be surprised. I strongly doubt it, because there are so many versions in use, and as of 2012 only 25% of jQuery sites even used Google CDN, by far the most popular CDN — most hosted it elsewhere. http://royal.pingdom.com/2012/06/20/jquery-numbers/ I have vague memories of reading a post with a stronger conclusion — that CDN caching was basically a non-issue, it would so rarely work — but to my fr…
I wouldn't link to the Google CDN anyway, personally. If your whole site is hosted on your servers and then you add this because maybe some people won't have to reload JQuery, it just means google knows everybody who visits your site. Free analytics you don't get to benefit from.
* an IP,
* a referrer from the first page on your site that included the script (no subsequent pages, because now the client has jQuery cached).
All in all, a pretty poor source of information compared to AdWords, Google Analytics, G+, hundreds of millions of Android users, and running the world's most popular search engine. At most they could crunch some browser stats or jQuery usage stats, but they already get that and more from their own services + crawling the web.
And even if this tiny amount of info were somehow a boon to Google, so what? It doesn't hurt you as a site owner.
Earlier quoted context omitted.
You might be looking for this - http://statichtml.com/2011/google-ajax-libraries-caching.htm...
Yes! Thank you. tl;dr for lazy HN readers: "using Google's CDN to load jQuery isn't likely to benefit the majority of your first-time visitors." As of 2011, jQuery 1.4.2 was by far the most common version and even that was only loaded via googleapis.com on 2.7% of websites.
Note the difference in version Steve found vs my comment (due to query strings etc., which will of course destroy caching)
Earlier quoted context omitted.
"Smaller" on a slow connection does make a big difference. That's almost everyone, everywhere.
My phone is fast enough that the difference between 4KB of data and 80KB is not huge.
The web is often death by a thousand cuts. Every decision by itself may seem small, but the end result is an unenjoyable, inefficient, battery-sucking result that leads people to abandon the web.
Earlier quoted context omitted.
"Smaller" on a slow connection does make a big difference. That's almost everyone, everywhere.
My phone is fast enough that the difference between 4KB of data and 80KB is not huge.
Earlier quoted context omitted.
My phone is fast enough that the difference between 4KB of data and 80KB is not huge.
Unless you're being targeted as a potential customer or a member of the audience, your mobile performance is irrelevant. What is relevant is that the majority of the devices being used to access sites don't have the performance of mid-high end models.