High-performance Ajax Applications

Yet more notes from Velocity.

Next session is High-performance Ajax Applications by Julien Lecomte (Yahoo!).

• Plan for performance from day 1
• work closely with designers and product managers
• understand design rationale
• explain the tradeoffs between design and performance
• offer alternatives and shw what is possible (prototypes)
• as a last resort, simplify design
  

Engineering high performance: a few basic rules:

• don't do anything unnecessary
• less is more
• break the rules
• work on improving perceived performance
• users can generally deal with a little bit of discomfort if they can see something is happening.
• can't compromise security but someother things can be compromised
• in general avoid presentational markup
  

Measuring performance:

• test performance using a setup similar to your user's environment
• profile your code during development
• automate profiling/performance testing
• keep historical records of how features perform
• consider keeping some (small amount of ) profiling code in production
  

Yahoo!'s exceptional performance rules

• make fewer http requests
• use a content delivery network
  

Asset optimization:

• minify CSS and JS files
• combine CSS and JS files
• optimize image assets
  

Reduce unminified code size:

• loading and parsing HTML, CSS and JS code is costly
• be concise and write less code
• make good use of javascript features
• consider optimizing your large JS files into smaller files (bundles) when the parsing and compilation of the script takes an excessive amount of time
• load code (HTML, CSS and JS) on demand
  

Optimize initial rendering (1/4) misc tips

• consider rendering the first view on the server. (server should generate the markup)
• this will speed up the intial rendering.
• close your HTML tags to speed up parsing
• consider flushing the apache buffer very early on
• load only essential assets/load assets on a delay or on demand.
• don't always wait for onload
• most DOM operations can be accomplished before he onload event has fired
• post load script loading:
• a well designed site should be fully functional even without the JS enabled
• therefore you may be able to load scripts on a delay
• conditional preloading:
• preload assets that you know user is likely to need very shortly
• however, one must be smart about when the preloading takes place. Otherwise the preloading may actually worsen the user experience.
  

Part 3: High Performance Javascript:

• look up is performed in JS everytime a variable is accessed.
• declare with the var keyword and use variables in the same scope whenever possible and avoid global resources at all costs.
• never use the with keyword as it prevents the compiler from generating code for fast access to local variables.
• cache the results of expensive lookups in local variables.
  

The prototype chain:

• accessing member found in the primary object is about 25% faster
• optimize object instantiation:
• if you need to create many objects, consider adding members to the prototype instead.
  

Don't use eval

• eval is evil
• the string passed to eval (and its relatives, the function constructr and setTimeout and setInterval function needs to be compiled and interpreted (extremely slow).
  

optimize string concatenation:

• on IE concatentating two strings causes a new string to be allocated and the two original strings to be copied.
• therefore, it is mch faster on IE to append string to an array and then use Array.join
  

optimize regular expressions.

• don't use the RegExp constructure unless your regular expression is assembled at runtime. Instead, use regular expression literals.
• use the test mehod if all you want to do is test for a pattern. (the exec method carries a small performance penlty.
  

Caching

• caching can be justified when there is a high cost associated with getting/accessing the data and when data wouldn't change over time.- increases memory consumption (tradeoff)

memorization

long running javascript running process (longer than 300ms):

• the entire browser UI is frozen.
• to maintain a decent user experience make sure that JS threads never take more than 300 ms.
  

misc:

• function calls have overhead associated with them
• consider using primitive operations since they are often faster than the corresponding function cals
• if possible, avoid using try..catch in performance critical sections
• if possible, avoid for...in in perormance critical sections
• branch outside, not inside, whenever the branching condition does not change

Google tests Ajax AdSense Ads

Today, I noticed something very interesting on my MySQL blog. Google has started using AJAX functionality in their AdSense ad units.

Notice the two blue arrows on bottom-left? Clicking on these buttons does an in-page refresh of ads so you can see more Google's ads. An excellent addition from publisher's point of view. However, as far as I am concerned, Google's attempt will be of no use to me. Are they serious? Do I browse so I can go from site to site clicking on these buttons to keep seeing an endless supply of ads just so Google can make more money.

So, let me ask you a question. Do you think you will be clicking on these buttons the next time you see them? Will they help publishers monetize better?