Jason Deacon Team : Web Development Tags : Web Development Performance

How do I fit optimisation into web development projects?

Jason Deacon Team : Web Development Tags : Web Development Performance

How do I fit optimisation into web development projects?

Often during the development of websites and web apps developers have to work optimisation into the project schedule. There are two approaches to scheduling optimisation, well, three if you count "no optimsation", but lets ignore that option for now. The two main ways are bulk optimisation and incremental optimisation. Let me explain.

Bulk Optimisation involves building the application first, getting all the functionality correct, and then going back and optimising everything. This basically means a large chunk of time at the end of the project is spent on optimisation tasks and nothing else. It can mean staring at a bunch of graphs and performance profiling tools for days on end, tweaking some code and then once again staring at some graphs. Sounds fun right. Right?!

Pros:

  • Can work with a complete, functioning site to understand intended use of core functionality in order to optimise algorithmically before optimising programatically.
  • Can easily see the impact of optimisation since a before and after benchmarks are easy to compare on a site-wide basis using common load testing tools.

 

Cons:

  • Relatively large portion of time spent with no functional changes, just optimisations, which needs to be justified to the business.
  • Depending on the time of the project development, some key knowledge of the structure and impact of certain sub-systems may be lost and have to be rediscovered or relearnt.
  • Will almost certainly be interrupted with functional changes or bug fixes, diluting the effectiveness of the allocated time.
  • Depending on deadlines and crunch periods, the allocated optimisation time may simply be dropped in order to ship a product, which results in a worse product going to market.

 

Incremental Optimisation involves optimising each piece of functionality as it's completed, which should be a fraction of the time it took to complete the actual feature. Typically in web development you would run a tool like MVC MiniProfiler to show the page load time (server side and client side, with MVCMP 2.0) so you can quickly see the impact of changes, but measuring still needs to be done, albeit briefly.

Pros:

  • Optimising code that has been written very recently allows maximum understanding of the process and thus a better performance strategy to be determined.
  • The website or application maintains decent performance during the development of the site, leading to a better understanding of the final performance characteristics.
  • Incorporating optimisation into the criteria for a task to be 'complete' removes the need to justify a large chunk of time at the end of the project for optimisation.

 

Cons:

  • Very difficult to report on the impact of optimisation at the end of the project since there is no fixed 'before and after' benchmarks to compare.
  • Requires developer discipline to actively optimise each component they build. If a component is forgotten it will most likely not be optimised until it's identified as a risk after the project goes live.
  • Requires tools or embedded diagnostics to inform the developer of performance without requiring the developer to go looking for it.

 

I've worked on project which took both approaches and have seen all the pros and cons listed above first hand. In my opinion, Incremental Optimisation provides key strengths over Bulk Optimisation that it should be favoured in almost all scenarios. Best of all it does not require a business discussion in order to start optimising, just make sure the page you're working on right now is fast and efficient!

Just one final note; Some developers or knowledgable IT administrators might be pounding their mice against their desks and screaming "But Incremental Optimisation is premature optimisation! That is evil and stupid!?". Websites are not large continuously running applications, they have discrete chunks of functionality (typically, each page) that can be worked on and optimised in isolation, without impacting other pages in most cases. In this sense, it's not premature if you've completed the page you're about to optimise.