4 ms·

JavaScript on deviantART: DWait and Dependencies

32 points by kemayo 16y ago

dmpatierno 16y ago
They're certainly doing the right thing here. JavaScript optimization is a constant battle between (1) reducing HTTP requests by grouping code together in a single file, and (2) reducing file sizes by splitting code into separate files. You don't want to group too much because you risk downloading code you don't need, but you don't want to split too much because you need to keep HTTP requests low. Proper optimization requires intelligent grouping of related code to create a balance between these two ideals, allowing the browser to cache commonly used resources so subsequent page loads are fast. Their blog page has 6 external JavaScript files and 4 external stylesheets. Those numbers are pretty reasonable given the scope of their site.
- bkrausz 16y ago
  There's no excuse for a blog to have 4 external stylesheets: these can easily be concatenated. Worse yet, they're not even minified.
  - dmpatierno 16y ago
    You're right about them not being minified, but wrong about the need for 4 external stylesheets. Look at their home page, for example. It uses just one stylesheet (v6core.css). That same file is also used on their blog, so my browser already has it cached. Perfect! None of those stylesheets are less than 45K, so the savings they get from not needing to download them on every page outweighs the HTTP request hit they take by including them separately on more complex pages.
    - jluxenberg 16y ago
      Even if the CSS is cached, your browser still needs to ask the server if the files has changed and receive back a "304 Not Modified," so you're still incurring the overhead of those connections.
      - dmpatierno 16y ago
        Not if you set a proper far-future Expires header.
  - kemayo 16y ago
    There's no excuse for a dedicated blog to have 4 stylesheets, sure. But this is a subpage of a big website. The stylesheets are based on logical separation, with more sheets getting added in as you go to more specialized pages. On the frontpage, which is really more of our focus, there's a single CSS file. CSS doesn't get anywhere near as much benefit from being minified as JS does. There's much less scope for transformation of the code to make it smaller, so if you're serving your CSS gzipped (which we do) then the difference is minimal at best.
    - bkrausz 16y ago
      Good point on the redownloading part: I'd have to look into the actual numbers, if the homepage-primed connection count is still only 1 it's definitely worth it. However, I disagree about the low benefit of minifying gzipped CSS. I thought the same thing too until I ran some tests. For example: 34K v6core.css.gz 27K v6core.min.css.gz I ran your core CSS file through YUI compressor and then gzip. 7k of savings, over 20%, definitely seems worth it.
      - kemayo 16y ago
        Interesting; that's a lot more than I had expected. It's only a few lines of code to change to make it happen, so we may well do it. (Need to do some quick checking to make sure that we don't have any old CSS hacks in there that might play poorly with being minified.)
bkrausz 16y ago
All modern browsers have per-domain connection limits higher than 2 by now (Firefox is 6 for example). The problem is that JS blocks all other content loading/parsing because it can impact it upon execution.
- kemayo 16y ago
  The article mentions that just after it talks about connection limits.
  - bkrausz 16y ago
    Yes, but mentioning a connection limit that's normally 2 (i.e. "This limit is normally 2 connection to a domain.") is factually incorrect.
    - kemayo 16y ago
      It makes sense to consider the lowest number amongst browsers in fairly common use when considering the limit. IE7 may not be a "modern browser", but it's still one in widespread enough use that we have to support it. (It was only in IE8 that MS bumped the limit to 6.)
- tlrobinson 16y ago
  Higher connection limits do help page load performance but it's not a complete solution. The overhead of initiating TCP connections and sending HTTP headers adds up quickly if you have dozens of files.
Aetius 16y ago
Seeing $object->method() made me shed a little tear in remembrance of the days I sweated bullets for PHP.
kemayo 16y ago
The first third is a pretty standard introduction: minimize number of files, yadda yadda. The second third talks about how JS/CSS dependency resolution is handled using metadata included in the files themselves. Then it explains a client-side library used for enabling dependency behavior on the frontend, including dynamic loading of files as-needed.
petercooper 16y ago
That's definitely the first time I've seen such a strong literary reference in the first sentence of a programming article :-)
- kemayo 16y ago
  I was expecting someone to comment on that a little sooner, I'll admit. :)
  - ihodes 16y ago
    Au contraire! Check out my post on the front page of HN just a couple days ago (before this was written) ;) The exact same reference, but relating to Clojure. http://copperthoughts.com/p/clojure-io-p1/ http://copperthoughts.com/p/clojure-io-p1/ That's not to say I don't appreciate it, though :)

32 points by kemayo 16y ago

They're certainly doing the right thing here. JavaScript optimization is a constant battle between (1) reducing HTTP requests by grouping code together in a single file, and (2) reducing file sizes by splitting code into separate files. You don't want to group too much because you risk downloading code you don't need, but you don't want to split too much because you need to keep HTTP requests low. Proper optimization requires intelligent grouping of related code to create a balance between these two ideals, allowing the browser to cache commonly used resources so subsequent page loads are fast. Their blog page has 6 external JavaScript files and 4 external stylesheets. Those numbers are pretty reasonable given the scope of their site.

bkrausz 16y ago
There's no excuse for a blog to have 4 external stylesheets: these can easily be concatenated. Worse yet, they're not even minified.
- dmpatierno 16y ago
  You're right about them not being minified, but wrong about the need for 4 external stylesheets. Look at their home page, for example. It uses just one stylesheet (v6core.css). That same file is also used on their blog, so my browser already has it cached. Perfect! None of those stylesheets are less than 45K, so the savings they get from not needing to download them on every page outweighs the HTTP request hit they take by including them separately on more complex pages.
  - jluxenberg 16y ago
    Even if the CSS is cached, your browser still needs to ask the server if the files has changed and receive back a "304 Not Modified," so you're still incurring the overhead of those connections.
    - dmpatierno 16y ago
      Not if you set a proper far-future Expires header.
- kemayo 16y ago
  There's no excuse for a dedicated blog to have 4 stylesheets, sure. But this is a subpage of a big website. The stylesheets are based on logical separation, with more sheets getting added in as you go to more specialized pages. On the frontpage, which is really more of our focus, there's a single CSS file. CSS doesn't get anywhere near as much benefit from being minified as JS does. There's much less scope for transformation of the code to make it smaller, so if you're serving your CSS gzipped (which we do) then the difference is minimal at best.
  - bkrausz 16y ago
    Good point on the redownloading part: I'd have to look into the actual numbers, if the homepage-primed connection count is still only 1 it's definitely worth it. However, I disagree about the low benefit of minifying gzipped CSS. I thought the same thing too until I ran some tests. For example: 34K v6core.css.gz 27K v6core.min.css.gz I ran your core CSS file through YUI compressor and then gzip. 7k of savings, over 20%, definitely seems worth it.
    - kemayo 16y ago
      Interesting; that's a lot more than I had expected. It's only a few lines of code to change to make it happen, so we may well do it. (Need to do some quick checking to make sure that we don't have any old CSS hacks in there that might play poorly with being minified.)

bkrausz 16y ago

All modern browsers have per-domain connection limits higher than 2 by now (Firefox is 6 for example). The problem is that JS blocks all other content loading/parsing because it can impact it upon execution.

kemayo 16y ago
The article mentions that just after it talks about connection limits.
- bkrausz 16y ago
  Yes, but mentioning a connection limit that's normally 2 (i.e. "This limit is normally 2 connection to a domain.") is factually incorrect.
  - kemayo 16y ago
    It makes sense to consider the lowest number amongst browsers in fairly common use when considering the limit. IE7 may not be a "modern browser", but it's still one in widespread enough use that we have to support it. (It was only in IE8 that MS bumped the limit to 6.)
tlrobinson 16y ago
Higher connection limits do help page load performance but it's not a complete solution. The overhead of initiating TCP connections and sending HTTP headers adds up quickly if you have dozens of files.

Aetius 16y ago

Seeing $object->method() made me shed a little tear in remembrance of the days I sweated bullets for PHP.

kemayo 16y ago

The first third is a pretty standard introduction: minimize number of files, yadda yadda. The second third talks about how JS/CSS dependency resolution is handled using metadata included in the files themselves. Then it explains a client-side library used for enabling dependency behavior on the frontend, including dynamic loading of files as-needed.

petercooper 16y ago

That's definitely the first time I've seen such a strong literary reference in the first sentence of a programming article :-)

kemayo 16y ago
I was expecting someone to comment on that a little sooner, I'll admit. :)
- ihodes 16y ago
  Au contraire! Check out my post on the front page of HN just a couple days ago (before this was written) ;) The exact same reference, but relating to Clojure. http://copperthoughts.com/p/clojure-io-p1/ http://copperthoughts.com/p/clojure-io-p1/ That's not to say I don't appreciate it, though :)