We currently haven’t the templates connected to the CMS yet, but the raw time is currently between 700 and 900ms. Maybe it can be justified because the layout isn’t Web 1.0 style (i.e. many round corners, shadows, etc.).

What puzzled me was the “loading time of JavaScript was around 300ms”, see this picture:

That’s quite a long time. It may is not that good visible from the chart, but nearly everything following the JavaScript is hold until it is read, which delays the complete loading of the rest of the page.

Since behind the scenes the actual request is in reality using Minify, it’s not just plain serving (but for this scenario the JavaScript has already been cached).

So I took a look just at the JavaScript loading, see this:

What’s that? Roughly 30ms vs 300ms?

The only realistic guess I’ve at the moment is: parsing the JavaScript.

This single request loads the following libraries:

• behaviour
• prototype
• scriptaculous (+effects)
• yui: yahoo-dom-event
• yui: container_core
• yui: menu.js
• our own small JavaScript parts

Maybe I’m too optimistic but it hit me a bit that JavaScript parsing still does take so long. Given that the JavaScript is cached (ideally) things such a huge problem, but still. It was frustrating that I could trim down the >1s request to ~700ms but not further and for most of the part just because it takes as long as it needs it.

My selector looked like .menu and unfortunately it also did match div class="menu-selector" in my code. This is because a dash also counts as word boundary when using Javascript \b pattern.

I modified the class matching regular expression do the following

'(^|\s)' + className + '($|\s)'

and this did work very well for me.

I’m currently trying to contact Simon Willison about his opinion whether this change is a good idea or not, I’ll update this post once I’ve received feedback.