At what point do you perform front-end optimization?

Question

I'm talking about things like page/stylesheet caching, minifying javascript, etc.

Half of me thinks it's better to do these things as early as possible while still in development so I can be consciously aware of more realistic speed and response issues as well as interacting with something that more closely resembles what will be deployed into production, but the other half of my brain thinks it makes more sense to not do anything until just before launch so that I'm constantly working with the raw data that has not been optimized while in development.

Is there common or conventional wisdom on this subject?

Answer 1

I do all optimizations at the end. That way I know when something doesn't work it is because the code is wrong. I've tried to optimize things too early at times, and realized that I wasted an hour because I was caching something etc.

Answer 2

Realize that a user spents most of his time waiting on frontend objects to (down)load. Your application may generate html in 0.1 second but the user spends at least 2 seconds waiting on all the images etc to load. Getting these download times to a small number will positively increase the user experience.

A lot can be done already by enabling GZIP and using minified javascript libraries. You should download and install YSlow and configure your webserver with appropriate caching headers. This alone can save hundreds of miliseconds loading time.

The last step is to optimize the amount of images using CSS sprites. Other steps can include minimizing css and javascript, but this will gain the least of all methods I mentioned already.

To summarize, most of this can be done by properly configuring your webserver, the sprites however should be done during development.

Answer 3

I'm a fan of building the site first, then using a user experience profiler like YSlow to do the optimizations at the very end.

http://developer.yahoo.com/yslow/

I should add that a profiler of some sort is essential. Otherwise, you're optimizing without before/after data, which is not exactly scientific (not to mention you won't be able to quantify how much improvement you made).

Answer 4

Premature optimization is the root of all evil :)

Especially early in development and even more so when the optimizations will interfere with your ability to debug the code or understand the flow of the program.

That said, it is important to at least plan for certain optimizations during the design phase so you don't code yourself into a corner where those optimizations are no longer easy to implement (certain kinds of internal caching being a good example).

Answer 5

I agree with your premise that you should do as much optimization in the early stages as you can. It will not only improve development time (think: saving 1/2 seconds per refresh adds up when you're spamming control+r!) but it will keep your focus in the end -- during the time when you're refacting the actual code you've implemented -- on the important stuff. Minify everything that you won't be modifying right off of the bat.

Answer 6

I agree with the other half of your brain that says 'do what you have to do, and then do it faster'. But for anything you do you must know and keep in mind how it can be done faster.

The main problem I see with this approach is that at the end its easier to ignore the fact that you have to optimise, especially if everything seems to be 'good enough'. The other problem is that if you are not experienced with optimisation issues you may indeed 'code your self in a corner' and that's where things tend to get really ugly.

Answer 7

I think this might be one where it's difficult to get a clear answer, as different projects will have different requirements, depending on how much work they are doing on the client side.

Mine rule of thumb would be probably later rather than sooner. Only because a lot of the typical front-end optimisation techniques (at least the stuff I'm aware of) tend to be fairly easy to implement. I'm thinking of whitespace stripping and changing http headers and so forth here. So I would favour focusing on work that directly answers the problem your project is tackling; once that is being addressed in an effective way move onto stuff like optimising front-end response times.

Answer 8

After coding for a number of years, you get to have a pretty clear idea what the performance bottle necks will be.

DB Queries JS/Jquery functions cfc's images javascripts

By identifying the bottlenecks ahead of time, while you create/modify each piece of the application that deals with those bottlenecks, you can spend time tweaking, knowing that by spending time while coding, gives you better performance in the end.

Also tends to make us less lazy, by always creating optimal code, and learning what that is in real life.