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

No related posts.

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

No related posts.

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

I simply couldn’t resist myself from capturing the screen shots of the brand new Addon Manager being developed for Firefox 4 (3.7a5pre). The new UI is slick and feels more like a part of the browser.

Here are is a quick screen shot of the Themes section.

The Addons section

It seems like this is work in progress – “Get more addons” is still being developed.

The Firefox version I am running (Know more) (Download link) (AdoMado)

No related posts.

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

So if you are in a same situation as mine, you probably…

• Are on an MNC’s intranet which is being simultaneously used by a ton of other souls
• Get pathetic internet speeds, at times – measurable sometimes in BYTES!
• Even “git pull” takes like ages to complete…
• Any connection to Twitter is severed before it even sees light of the day!

The solution to all these worries is simpler than you think.

We can create an SSH tunnel to a *much* faster server and push our internet traffic over it. If the server is local, this will work even better – as your SSH on local LAN connections would be definitely faster than that on real WWW.

Follow http://wiki.freaks-unidos.net/weblogs/azul/firefox-ssh-tunnel and create a tunnel on any port. Lets call it $PORT
Basically, you need to run…

ssh -fND localhost:$PORT username@some-fast-server.com

Install tsocks – its a Transparent SOCKS Proxying Library which uses the magic of LD_PRELOAD and patches the connect() call to appropriately use a pre-configured proxy (via /etc/tsocks.conf). Hence any call like…

git pull

becomes

tsocks git pull

Your /etc/tsocks.conf looks something like this (after removing all the comments)

#Define a local network for which tsocks won’t patch the connect() call
local = 192.168.0.0/255.255.0.0

path {
reaches = 0.0.0.0/0.0.0.0
server = 127.0.0.1
server_type = 5
server_port = $PORT
}
server = 127.0.0.1
server_type = 5
server_port = $PORT

Replace the $PORT by the port you selected when creating the SSH tunnel. Server remains 127.0.0.1 as your tunnel exists on your own machine.

To configure your Firefox to use this new tunnel, goto Edit > Preferences > Advanced > Network Tab > Settings and make it look like

Add URL’s and IP ranges to “No Proxy for” field to exempt them from using the SSH tunnel.

That’s it. Click OK and you are ready to rock!

No related posts.

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

Okay, to start off – I really wanted Firefox to come on the top… I’ve been a dedicated firefox user ever since and simply love the product. The fact that it has addons for any conceivable functionality – makes it r0ck even more!

However, to my surprise Google’s Chrome beats it hands down when it comes to speed of the javascript engine each of the browser deploys. Google has V8 tucked under Chrome’s (v4.0.213.1) belt, while my shiny new (nightly updated) Mozilla Firefox Minefield 3.7a1pre has TraceMonkey.

So why am I this sad today? Well… check this out…

Peacekeeper JS test – Chrome was nearly 59% faster here!

SunSpider test – Chrome was almost 76% faster

Chrome vs Firefox – SunSpider test, merged view.

I purposely ran the tests in side-by-side browser windows, launching Firefox tests just about a second before the Chrome’s tests – and to my surprise, I could actually (visually) see Chrome finishing faster – it was that fast!
Afterall… 59% or 76% actually does seems a pretty huge boost, whatever functionality it might be in.

Here are by browser versions… (both are stock builds as provided by repositories/online).

and  

Well… to me, this is healthy competition. Talk about the times when Chrome wasn’t there, Firefox used to make IE look timid. Come Chrome and now Firefox is doing the catch-up. Whoever wins, we – the end users – get the best of all the worlds.

That is like – have your cake & eat it too

However, I seriously hope that by the time Firefox 4.0 launches, its javascript engine is at par with Google Chrome’s.
And by the time Google Chrome matures, I wish it should start sporting the same plethora of addons as does Firefox.

From UI’s perspective, Chrome also packs an extra bit of punch, which I really like and would like to blog about. But thats for a later post.

No related posts.

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

Using Minefield – the nightly firefox build – and yet want to use all the available extensions? Even those which are made for FF versions upto 3.5*?

Well… The hack is pretty simple. Seems like Mozilla Addons website checks for the User Agent string in request headers to determine if its going to show you a “Add to Firefox” or the “Sorry” butons.

or

Perform the following

1. Follow http://kb.mozillazine.org/Extensions.checkCompatibility and disable compatibility checks done by FF when installing new addons.
2. Download and install the User Agent Switcher addon from https://addons.mozilla.org/en-US/firefox/downloads/latest/59/addon-59-latest.xpi and restart Firefox.
3. Use the User Agent Switcher extension to create a new user agent string – you can pick up one for Firefox 3.5 from http://www.useragentstring.com/pages/Firefox/
4. Whenever you need to install any addon from Mozilla Addons, just select the new User Agent string from the User Agent Switcher menu in the Tools menu and reload the Mozilla Addons page.
5. Enjoy

Firefox 3.53 User Agent string

Installing an addon which is meant for Firefox 3.5* on Firefox 3.7a1pre

NOTE: Performing the above hack can crash your firefox profile. This information is released for academic purpose only. I cannot be held responsible for any data loss whatsoever. Use at your own risk.

No related posts.

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