5 ms·

Don't most apps reference jQuery from a CDN source (like Google)? In those cases jQuery is probably served from the browser cache. And if "those cases" are "mos

Don't most apps reference jQuery from a CDN source (like Google)? In those cases jQuery is probably served from the browser cache. And if "those cases" are "most cases", is having a smaller version of a similar library particularly valuable?

pamelafox 15y ago
The parse time is significant for jQuery, atleast on some mobile devices. For example, in my tests on an Android N1 today, jQuery took 800ms to parse (even when cached) whilst Zepto took 300ms -- saving 500ms.
- numlocked 15y ago
  Interesting. Is parse time generally a function of code length, or overall complexity/CPU time?
  - pamelafox 15y ago
    (I'm not an expert) but it's more than simply code length - it also depends on if the library runs any functions at parse time, and perhaps also how many variables it puts in the global space. For example: I discovered that my tiny localStorage library was taking 300ms to load, and that was because I was doing feature detection at parse-time and that feature detection attempted to actually set an item in localStorage. I postponed that, and got the load time down to 20ms.
- DiabloD3 15y ago
  Google in their Page Speed ranking consider 100kb == 100ms. See: https://code.google.com/speed/page-speed/docs/mobile.html#DeferParsingJS https://code.google.com/speed/page-speed/docs/mobile.html#De... BTW, their Page Speed thing is now available online: https://developers.google.com/pagespeed/ https://developers.google.com/pagespeed/
  - dextorious 15y ago
    Parent talks about parsing speed.
    - DiabloD3 15y ago
      So does Google.
  - agentgt 15y ago
    I wonder if there is any better optimization that browsers can do for this (like at least cache the AST if the exact same JS is loaded).
- ruethewhirled 15y ago
  Do you mind sharing what are you using/doing to benchmark that? cheers
tfb 15y ago
I'm considering using it because of a combination of the following: 1) You can't always count on users having cached it from the CDN. 2) If it's included on my own server I can be sure they're getting exactly what I intend and there will be less HTTP requests when I include it with the rest of my JS which will only add ~4kb. 3) I'm a bit of a minimalist when it comes to code - for the web at least.
- wisty 15y ago
  For small libraries, and users with fast connections, the HTTP request can be the limiting factor.
  - tfb 15y ago
    The idea is to include all javascript in a single HTTP request. Sorry if that wasn't clear in point #2.
- dextorious 15y ago
  """1) You can't always count on users having cached it from the CDN.""" No, but you can always count the MAJORITY of users will have it cached from the CDN.
  - spjwebster 15y ago
    You need to be careful with your wording here. The "MAJORITY" of the top 1m websites (based on Alexa rankings) don't use Google's CDNs (i.e. load a resource from googleapis.com): http://httparchive.org/trends.php#perGlibs http://httparchive.org/trends.php#perGlibs ...and that's across all versions of all libraries. Quite how that correlates with how many of your first-time visitors will already have the library cached – because they happen to have recently visited another site that uses the same version of the same library – depends on how much your visitor demographic intersects with those sites that use the CDN. You then need to offset that against the DNS lookup time requires for the rest of your visitors to work out whether loading the file from Google's CDN makes sense. If you're talking about repeat visitors, it doesn't matter where the file was served from, so long as you apply the correct cache-controlling headers.
DiabloD3 15y ago
No, a lot of HTTPS sites won't because its a security hazard and also requires a CDN that provides HTTPS as well.
- rsoto 15y ago
  ...Which those CDN provide support as well: https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
  - ufo 15y ago
    ...but is it really worth it to give Google a "backdoor" into your https app just because you want to load jQuery faster?
    - X-Istence 15y ago
      The user most likely already is giving Google a backdoor into your app ... if they are using Chrome.
      - drivebyacct2 15y ago
        What? That's absurd. You understand why that is hyperbolic, right?
        X-Istence 15y ago
        Just as absurd as Google destroying any and all confidence any of us tech people would have in them as a company if they loaded malicious javascript instead of jquery or along with jquery from their CDN's. That is the point I was trying to make.
        drivebyacct2 15y ago
        My apologies. I understand and think you make a very good point.
jaredstenquist 15y ago
Even though the Google Jquery libraries are used by a large number of top 100 sites, I prefer to serve my own files. 100k or 200k for the foundation of functionality that jquery provides isn't going to severely affect your visitors in any way. Of course I'm assuming you're using common best practices with cache-control/expires headers.

pamelafox 15y ago

The parse time is significant for jQuery, atleast on some mobile devices. For example, in my tests on an Android N1 today, jQuery took 800ms to parse (even when cached) whilst Zepto took 300ms -- saving 500ms.

numlocked 15y ago
Interesting. Is parse time generally a function of code length, or overall complexity/CPU time?
- pamelafox 15y ago
  (I'm not an expert) but it's more than simply code length - it also depends on if the library runs any functions at parse time, and perhaps also how many variables it puts in the global space. For example: I discovered that my tiny localStorage library was taking 300ms to load, and that was because I was doing feature detection at parse-time and that feature detection attempted to actually set an item in localStorage. I postponed that, and got the load time down to 20ms.
DiabloD3 15y ago
Google in their Page Speed ranking consider 100kb == 100ms. See: https://code.google.com/speed/page-speed/docs/mobile.html#DeferParsingJS https://code.google.com/speed/page-speed/docs/mobile.html#De... BTW, their Page Speed thing is now available online: https://developers.google.com/pagespeed/ https://developers.google.com/pagespeed/
- dextorious 15y ago
  Parent talks about parsing speed.
  - DiabloD3 15y ago
    So does Google.
- agentgt 15y ago
  I wonder if there is any better optimization that browsers can do for this (like at least cache the AST if the exact same JS is loaded).
ruethewhirled 15y ago
Do you mind sharing what are you using/doing to benchmark that? cheers

tfb 15y ago

I'm considering using it because of a combination of the following: 1) You can't always count on users having cached it from the CDN. 2) If it's included on my own server I can be sure they're getting exactly what I intend and there will be less HTTP requests when I include it with the rest of my JS which will only add ~4kb. 3) I'm a bit of a minimalist when it comes to code - for the web at least.

wisty 15y ago
For small libraries, and users with fast connections, the HTTP request can be the limiting factor.
- tfb 15y ago
  The idea is to include all javascript in a single HTTP request. Sorry if that wasn't clear in point #2.
dextorious 15y ago
"""1) You can't always count on users having cached it from the CDN.""" No, but you can always count the MAJORITY of users will have it cached from the CDN.
- spjwebster 15y ago
  You need to be careful with your wording here. The "MAJORITY" of the top 1m websites (based on Alexa rankings) don't use Google's CDNs (i.e. load a resource from googleapis.com): http://httparchive.org/trends.php#perGlibs http://httparchive.org/trends.php#perGlibs ...and that's across all versions of all libraries. Quite how that correlates with how many of your first-time visitors will already have the library cached – because they happen to have recently visited another site that uses the same version of the same library – depends on how much your visitor demographic intersects with those sites that use the CDN. You then need to offset that against the DNS lookup time requires for the rest of your visitors to work out whether loading the file from Google's CDN makes sense. If you're talking about repeat visitors, it doesn't matter where the file was served from, so long as you apply the correct cache-controlling headers.

DiabloD3 15y ago

No, a lot of HTTPS sites won't because its a security hazard and also requires a CDN that provides HTTPS as well.

rsoto 15y ago
...Which those CDN provide support as well: https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
- ufo 15y ago
  ...but is it really worth it to give Google a "backdoor" into your https app just because you want to load jQuery faster?
  - X-Istence 15y ago
    The user most likely already is giving Google a backdoor into your app ... if they are using Chrome.
    - drivebyacct2 15y ago
      What? That's absurd. You understand why that is hyperbolic, right?
      - X-Istence 15y ago
        Just as absurd as Google destroying any and all confidence any of us tech people would have in them as a company if they loaded malicious javascript instead of jquery or along with jquery from their CDN's. That is the point I was trying to make.
        drivebyacct2 15y ago
        My apologies. I understand and think you make a very good point.

jaredstenquist 15y ago

Even though the Google Jquery libraries are used by a large number of top 100 sites, I prefer to serve my own files. 100k or 200k for the foundation of functionality that jquery provides isn't going to severely affect your visitors in any way. Of course I'm assuming you're using common best practices with cache-control/expires headers.