Faster HTML and CSS: Layout Engine Internals for Web Developers (@GoogleTechTalks)

I think I never cared about these – but the way David Baron from Mozilla describes these, I think I will now.
The points he was making started seeming so crucial that I jotted them down as if taking notes – something I never did with previous videos.

The things which I picked up from this video are…

From fetching the DOM over the wire to displaying it, following steps take place in order…
(1) Compute => (2) Compute Style => (3) Construct the DOM frame => (4) Layout => (5) Paint

The further Left (towards (1)) you push the browser’s rendering engine via your DOM/JS/CSS, the slower the browser would get.

Hence…

Use as specific CSS tags as possible. The more generic tag, the higher performance hit while searching the DOM. For example, a “#some-id {}” is way way faster than “body > div p {}” – as in the second tag, a larger portion of DOM is parsed to check which elements are affected by the selector. You push the browser to start from stage (2).

“:hover” style hits the browser pretty badly – as it pushes the browser back to stage (2). Coupled with the above mentioned CSS selectors problem, it can lead to real slow computation. Use it with CSS selectors which are very very specific in nature.

Programmatic scrolling of tags (some of which might have overflow property) via javascript – as that does not causes re-computation of style (stage 2). While if you do it with CSS magic, you push your browser back to stage (2).

Mozilla’s rendering tree, while building itself – does not takes any element with with CSS property “display:none” into account – it just skips it. So when this property is flipped, it triggers a full re-computation of the tree – which is expensive. However if we use the style “visibility:hidden” – the rendering tree picks up the related element while building itself. Hence when visibility is flipped, its much faster as there is no re-calculation of the rendering tree.

An old one – when javascripts are being downloaded, the browser stops itself from any other processing and waits for the script to download and execute (as script can modify the DOM anyhow it likes). During this time, the precious time is lost – which could have been used in downloading other content – like images, DOM, CSS, etc. Hence – keep the javascripts as further in the DOM as possible. Use caching is possible.

Learn more about speeding up your website at – Yahoo’s best practices (YSlow stuff) – some of which we regularly follow at AdoMado.com

Related posts:

1. OMG! Chrome-4.0 is nearly 59% and 76% faster than Firefox-3.7a1pre on my T61 (Ubuntu Jaunty) Okay, to start off – I really wanted Firefox to…
2. Getting around the dreaded Operation Aborted error in Internet Explorer with Ruby on Rails If you have ever experienced this… …you know how painful…

Related posts brought to you by Yet Another Related Posts Plugin.

If you have ever experienced this…

…you know how painful it is to debug and rectify.

This error was so common that Microsoft created a knowledge base (KB927917) article for this. It even has a dedicated explanation at the IE Blog. The error basically is – “HTML Parsing Error: Unable to modify the parent container element before the child element is closed (KB927917)”.

While building the Social sharing plugins for AdoMado, we were facing similar problems. Anywhere FB share, Orkut share or Digg buttons were being used, IE was complaining of exactly the same problem. Since social share plugins are the backbone of our community building process, fixing this ASAP was high on my agenda.

NOTE – There was no such problem on any version of Firefox or Chrome.

If you notice the IE blog entry, they mention that

Moving the location of your script block to a child of the body (this usually solves most problems, while allowing the most flexibility in terms of scenarios).

can be a possible solution.

Cool! But how do we reach here? My javascripts were spread all over the place!

First things first… I refactored the code in such a way that all possible usage of problem causing scripts was moved to one single partial. Now error was originating from only one location. The fix, as mentioned on the IE blog – was then straight forward.

In your layout, just before closing the BODY tag, use the “yield” block to render any such javascript – and render all such scripts into this “yield” block.

Here are some screen captures from our codebase…

Notice the “yield :delayed_loading” block…

Yield’ing to delayed_loading block.

If you browse over to our offer – Send Ad Free SMS using IE, you will notice that you see no such error. All the social share plugins render in harmony.
I’ve even thrown in a little jQuery fadeIn magic

Related posts:

1. Revisting Ruby – Array.each I’ve been in love with Ruby for long now –…
2. Authentication using Google Accounts for your Rails App The methodology is very simple. Redirect the user to grant…
3. AdoMado… the Next Phase!! Hey everyone!! Last week we embarked on the next phase…

Related posts brought to you by Yet Another Related Posts Plugin.

At AdoMado, we are always trying to improve the skewed gender ration we have amongst our user base. As part of the same endeavor, we have introduced a special set of coupons available for redemption while keeping in  mind the needs of the ladies. This includes 5 sections:

AdoMado Offers

1. Apparel (2 coupons)
2. Bakery and Confectionery (2 coupons)
3. Beauty (9 Coupons)
4. Fitness (5 coupons)
5. Jewellery (1 coupon)
6. Wedding (1 coupon)

Approx. 20 coupons!!

Though at times these coupons might be limited by gegraphical spread, but still its a step forward to entice the better half of our species to start surfing net regulary (while having AdoMado installed).

Looking forward to having a few beautiful and sexy users for AdoMado.

AdoMado Team

http://AdoMado.com

Related posts:

1. AdoMado… the Next Phase!! Hey everyone!! Last week we embarked on the next phase…
2. Why being filtered for adult content? Ever since we implemented content filtering mechanisms at AdoMado, our…

Related posts brought to you by Yet Another Related Posts Plugin.

Ever since we implemented content filtering mechanisms at AdoMado, our own site was being blocked – and this made me heck curious – why??

Today morning, using Rubular (which is an excellent online regex tool) – I discovered the culprit.
And it couldn’t have been more hilarious )

Fixing this… )

PS – a valid bug.

Related posts:

1. AdoMado Employees Get Apple Laptop, Each !! Everyone who works at AdoMado puts in there 100%, so…
2. Something for the Ladies At AdoMado, we are always trying to improve the skewed…
3. AdoMado… the Next Phase!! Hey everyone!! Last week we embarked on the next phase…

Related posts brought to you by Yet Another Related Posts Plugin.