3 ms·

"Many websites can become faster with little effort, and collective attention to performance can speed up the entire web..." This is true - I have been working

"Many websites can become faster with little effort, and collective attention to performance can speed up the entire web..." This is true - I have been working with many over the last 3 years to help them improve web site performance. Most sites will see a huge performance improvement by just concatenating (bundling) their JavaScript and CSS. Tools like; YUICompressor and www.rockstarapps.com Eclipse tools simplify the process. One issue I have found is that developers always leave performance tuning of all projects to the end.

CodeMage 17y ago
One issue I have found is that developers always leave performance tuning of all projects to the end. Yep! Here's how that works: 1) You hear "premature optimization is the root of all evil" parroted everywhere. 2) You decide to leave the optimization for the end. 3) You develop code that performs suboptimally, sometimes even abysmally. 4) You develop more code on top of it. 5) You repeat the previous step until the codebase is big enough that optimizing away root causes of performance problems is too painful. 6) By this time you have to deal with releases and bugfixes and feature requests and maintenance and whatnots, so you settle for the advice from Coding Horror, where Jeff told you that throwing hardware at performance problems is cheaper than investing programmers' time in solving them. 7) Profit! Er, no, wait, that's the other list of steps...
- nostrademons 17y ago
  The right place to insert performance tuning is probably between #3 and #4. It makes perfect sense to leave optimization until you know what you actually want to build. It also makes sense that a piece of code will be no faster than its slowest component. So write the slow version first, but don't build anything on top of it until it's no longer slow. Don't pile crap on top of crap.
- patio11 17y ago
  In web programming the things that will really give you perceptible speed boosts aren't even optimizations so much as "do it the right way the first time". How hard is it to configure Apache to gzip your textual content? That takes, what, four lines? And it will deliver huge, perceptible boosts to probably six nines of all websites without perceptible downsides? You should require a note signed by your doctor to NOT have that option turned on. Putting all your JS/CSS in one file takes almost no thought in Rails. (:cache => true) If you require multiple sets of included Javascript, you have to make the terribly difficult optimization decision of giving them different names (:cache => "purchasing_scripts") If you're not using Rails, then you might have to actually write code in your build/deploy script, once. (Then you copy/paste it to every project you ever do, because there is never going to be a time when including 6 CSS files individually is a good idea.) Looking at our repository it looks like an ANT script can do it in a dozen lines, so it can't POSSIBLY be that hard in your language of choice.
  - litewulf 17y ago
    Long long ago, gzip would cause some browsers to barf. Some browsers would lie about what they could handle, and you had to check the UA as well as the accept-encoding header. JS/CSS concatenation, at least from the last time I had to roll my own always drove me nuts because I wanted to "recompile" on the fly and thus putting it in my build script meant I had to rebuild with every little change. (I recognize these are excuses. But every action comes with an opportunity cost, blah blah blah)
    - nostrademons 17y ago
      I often copy the uncompressed source directly over the compiled file, make my edits on the live file, and then copy it back when I'm ready to check-in. Granted, the system I work with compiles and doesn't concatenate, which is a slightly simpler problem. But you could easily have your build script leave comment markers in the file (or just look for top-level '(function(){...})()' closures which nearly every sane system uses) and "unbuild" the concatenated file from that.
    - acdha 17y ago
      I think you might be overstating this a bit: browsers definitely had gzip support back in the stone-age (I actually implemented this by hand in 2000 or so) but for slightly shorter values of "long, long ago" it's also been the case that the necessary UA checks were well-known even if your default Apache config didn't already include them. JS/CSS, however, I agree completely on - it's a good deployment step but minification is quite the nuisance for debugging and it's less critical if you've configured your server to set proper Expires/Cache-Control headers.

CodeMage 17y ago

One issue I have found is that developers always leave performance tuning of all projects to the end. Yep! Here's how that works: 1) You hear "premature optimization is the root of all evil" parroted everywhere. 2) You decide to leave the optimization for the end. 3) You develop code that performs suboptimally, sometimes even abysmally. 4) You develop more code on top of it. 5) You repeat the previous step until the codebase is big enough that optimizing away root causes of performance problems is too painful. 6) By this time you have to deal with releases and bugfixes and feature requests and maintenance and whatnots, so you settle for the advice from Coding Horror, where Jeff told you that throwing hardware at performance problems is cheaper than investing programmers' time in solving them. 7) Profit! Er, no, wait, that's the other list of steps...

nostrademons 17y ago
The right place to insert performance tuning is probably between #3 and #4. It makes perfect sense to leave optimization until you know what you actually want to build. It also makes sense that a piece of code will be no faster than its slowest component. So write the slow version first, but don't build anything on top of it until it's no longer slow. Don't pile crap on top of crap.
patio11 17y ago
In web programming the things that will really give you perceptible speed boosts aren't even optimizations so much as "do it the right way the first time". How hard is it to configure Apache to gzip your textual content? That takes, what, four lines? And it will deliver huge, perceptible boosts to probably six nines of all websites without perceptible downsides? You should require a note signed by your doctor to NOT have that option turned on. Putting all your JS/CSS in one file takes almost no thought in Rails. (:cache => true) If you require multiple sets of included Javascript, you have to make the terribly difficult optimization decision of giving them different names (:cache => "purchasing_scripts") If you're not using Rails, then you might have to actually write code in your build/deploy script, once. (Then you copy/paste it to every project you ever do, because there is never going to be a time when including 6 CSS files individually is a good idea.) Looking at our repository it looks like an ANT script can do it in a dozen lines, so it can't POSSIBLY be that hard in your language of choice.
- litewulf 17y ago
  Long long ago, gzip would cause some browsers to barf. Some browsers would lie about what they could handle, and you had to check the UA as well as the accept-encoding header. JS/CSS concatenation, at least from the last time I had to roll my own always drove me nuts because I wanted to "recompile" on the fly and thus putting it in my build script meant I had to rebuild with every little change. (I recognize these are excuses. But every action comes with an opportunity cost, blah blah blah)
  - nostrademons 17y ago
    I often copy the uncompressed source directly over the compiled file, make my edits on the live file, and then copy it back when I'm ready to check-in. Granted, the system I work with compiles and doesn't concatenate, which is a slightly simpler problem. But you could easily have your build script leave comment markers in the file (or just look for top-level '(function(){...})()' closures which nearly every sane system uses) and "unbuild" the concatenated file from that.
  - acdha 17y ago
    I think you might be overstating this a bit: browsers definitely had gzip support back in the stone-age (I actually implemented this by hand in 2000 or so) but for slightly shorter values of "long, long ago" it's also been the case that the necessary UA checks were well-known even if your default Apache config didn't already include them. JS/CSS, however, I agree completely on - it's a good deployment step but minification is quite the nuisance for debugging and it's less critical if you've configured your server to set proper Expires/Cache-Control headers.