performance – Page 5 – The Page Not Found Blog

Major public web sites miss the mark on using advanced web technology

As a developer I notice things about web sites that the average person wouldn’t think twice about. I also know that the level of technology that’s available to build user interfaces is well beyond what we had in the early 2000’s. And, the ability to build amazing, user-centric interfaces is as easy as ever. But, I’m always perplexed that most major web sites today incorporate very little of this technology in their full functionality web pages.

So, I’ve been doing an informal survey for the past month and my list includes major news sites, airline web sites and retailers. The vast majority of them aren’t much easier to use than they were five years ago with a great a selection of hyperlinks, tabs and full page refreshes. For the fun of it I decided to travel back in time using an internet time machine call the Wayback Machine and compare some of these sites to their predecessors. I challenge you to do the same.

I have a few suspicions as to why this is happening, or not happening as the case may be. First, plug-in based technology such as Adobe Flex and Microsoft Silverlight typically require some amount of time to load the initial payload into the browser. Sometimes you can create highly optimized or lazy-load packages, but it challenging. It’s rare to find one of these apps that load in the sub-second timeframe required in today’s hyper-competitive environment. The general impression is that the longer your page takes to load, the fewer the visitors you will have. So most major websites code is mostly made up of HTML, JavaScript, jQuery and CSS which most browsers have gotten really, really good at parsing extremely fast.

Second, it’s challenging to build Flex and Silverlight websites so that web crawlers can read text-based content. This seems fairly academic. If you can’t effectively index the content of your site, then potential visitors can’t search it via external search engines such as Bing and Google. Period.

These two items alone may explain why visually spectacular interfaces are limited to small portions of most public websites such as video plug-ins, or just specific sections of a much larger website. Where these more advanced interfaces typically reside are in back office applications where functionality trumps the need for millisecond application load times. There are some very cool exceptions for consumer apps such as the end-user experiences shown Mini Cooper’s build your own car online website. Yet, unfortunately for us as consumers, these are few and far between as consumer companies cater to the vast hunger for ever faster page load times.

The good news for advanced web technology in consumer apps is I’m seeing a large opening with mobile deployments. The plug-in technologies now have the capability to allow you to deliver visually enticing experiences across a wide array of devices. And this can be done, for the most part, without the tedium of worrying about all the vast nuances of different browser types and versions. Plus there is a bonus: the application is manually loaded and ready to go on your device minus the on-device load time when you turn on the app. I’m seeing some really innovative uses of the technology in what I call focused solutions, or applications built for a very specific purpose. Unfortunately most are in commercial beta and I can’t link to them. But, you’ll see them soon in an online marketplace right at your fingertips.

References:

Mobile Development with Adobe Flex 4.5

Silverlight for Windows Phone

Flex.org Showcase

Study: Consumers abandon slow loading websites (April 2010)

Let’s make the web faster (Google, May 2010)

Improving Browser performance and stability – will web workers help?

The single-threaded nature of JavaScript is an old tradition that needs to go away. It was great in the wild-west, internet days of the 20^th century. But, today we have more complex needs that are being driven by the advancements that are happening around good old JavaScript as we know it, such as…on-going advancements in HTML 5.

The reason I bring this up is because I’ve been watching the discussion on Web Workers as it has evolved. It’s a brave attempt to bring a standard for implementing some sanity on this ancient notion of single threading. Now, I do want to say that this post isn’t about debating the merits of web workers, per se. It’s about giving developers better tools on which to build web applications for end users. I’ll be the first to agree that many developers (but not all!), for a variety of reasons, build apps like factories, but without many quality checks.

One argument the pro-single threaded parties claim is that doing away with single-threading will make things even more complicated for the companies that develop browsers and the developers that build apps on them. And, in effect, you’d be giving them (web app developers) free license to create even more terribly built web pages that crash browsers. For brevity sake, I’m only picking this one out of many possible arguments, as the one that comes up most often in discussions.

I also don’t ever recall seeing a browser vendor themselves saying something like this publicly, but it’s possible. This is a very weak argument that won’t stand the test of time. Sure, as we build more complex apps then there will be more of both good and bad apps. That’s just the way things work. There’s no way we would ever have a single authority that reviews all web apps before they are published. Perhaps, similar to what Apple does with iPhone apps. Not only would it be impractical, but it certainly seems like it goes against the spirit of the internet and WWW.

I fall into the camp of evolving the tools to better to fit the ever-changing and growing needs of the end users. End users don’t understand the limitations of the browser technology. They don’t need to and shouldn’t be expected to. All they know is that they want to see ever more visually stunning applications that run well and don’t crash all the time.

Developer tools and technology are much, much more advanced now than when the venerable Mosaic Web Browser hit the scene back in 1993. As an example, all eyes are on HTML 5 (more on that at a later date), and certainly we have the well-known browser plug-ins: Flash and Silverlight, and each has their own development kits. These technologies enable the building of some of the most eye-catching websites, and they really opened people’s eyes on what the web experience should be more like.

Now, I am eyes-wide-open about this. There are some well-documented, but not well understood existing limitations related to the web surfing/development experience as I blogged about here. But, merely saying things should not change because it will become too complicated isn’t a good enough reason to, well…not change. There are lots of smart people out there that love solving these types of problems.

So, I have a few suggestions of my own for the browser vendors and others to debate and work on. I think web workers are huge step in the right direction. But I also think there’s some other more strategic things that browser vendors could be doing that I think would also help. To me these are just as important as evolving the web standards, perhaps even more so. This is about browser vendors officially providing guidelines for us on how to do our job better:

Best Practices Document. All the major vendors should publish web development best practices for HTML and JavaScript development. And, I’m not talking about the W3C standard. That is what’s expect, but not actually what’s implemented. For example, I did a quick search of “web development best practices” using Google and Bing and the very first result I found was a short, not-really-so-helpful article on the Apple web site that was written in 2008!
Online HTML/JavaScript Validation engine(s). Each browser vendor should publish their own online HTML/JavaScript validation engine. Or better yet would be if someone builds one site that checks all major browsers in one shot and provides actionable feedback. I’m aware of other types of validators such as this one by W3C for HTML and the like. But, in general right now it’s just a hodgepodge of 3-rd party tools and guesswork as to whether a web app is working right. And, if you are like me and running the web debugger all the time, you’d know how many broken web pages there really are.

References:

Web Workers – Living Standard Document.

The browser as an operating system

Having a basic understanding of how our web applications affect browser performance is the key to determining whether the apps you build will be great, and which apps will be a miserable experience for your users. You can have the worlds’ best looking app with the nicest user-interface ever, but if it runs horribly on most visitors machines or phones then you’ve done your end users a massive disservice.

I contend that the browser as a web application programming environment should be treated as its own operating system with its own well defined dependencies. If you have a basic understanding of how these dependencies work, you’ll be able to build better, more stable, faster applications.

We are constrained in what we can build because browsers provide a finite environment in which to play in. To make things even more fun and challenging, in just the last five years we have gained access to some very powerful tools to build even more complex applications, such as Microsoft’s Silverlight API, and Adobe’s Flex/ActionScript API. Now we can build applications with very rich graphics in days or weeks that would have taken many months or even years before these tools became available. And, web applications until only recently gained the ability to semi-directly interact with the operating system to perform operations such as save or retrieve files from local hard drives. In the ‘dark ages’ we had to bounce files off a proxy server before being able to download them to the local machine. How we interact with the local machine is ultimately controlled by what the browser will allow.

The browser sandbox

Browsers provide us with a well-defined sandbox in which our apps can run, and from a developer’s perspective it includes the following:

A JavaScript engine
An HTML parser
User Interface rendering engine
Add-ins/Plug-ins (e.g. Flash Player, Silverlight, etc)
Cache space (includes cookies and local stores like in FlashPlayer)
Access to the internet
Access to local resources

It’s also important note, and if you’ve been building web apps for a while now you’ll know, that browser vendors don’t implement the various proposed standards exactly the same. For example, Internet Explorer may display a certain CSS tag different. Here’s an interesting comparison chart.

What about hardware?

I’m also not saying we don’t need to pay attention to the underlying operating system. In fact, we absolutely do need to pay attention to the following. However, we interact with them only indirectly, and because of that we tend to forget just how important they are:

CPU
Memory
Graphics card
Internet connection

Mobile devices are a great example. Mobile devices are getting more powerful all the time, but when they try and chug through a fully decked out web page, it takes them longer than a typical desktop or laptop. I’ve had developers tell me an app that’s running slow on everyone else’s machine was running just fine on theirs. What the developer forgot was he had the latest, greatest, hottest laptop out there with 8 GB’s of memory and an excellent internet connection! By way of example, I posted a screenshot at the bottom of this post of another website that even my quad-core laptop used between 50 – 80% of its resources to load the page.

Simple Tests

Here are some simple tests to tell if you web app is a good one that will meet the needs of your end users:

How much CPU does it consume? Test it on a moderately configured machine, typical of what your users might have.
How much memory does it use? And, how much memory over time? Browsers can be notoriously leaky, but your program may be contributing to it.
Is everything in the correct locations in the user interface at various common browser sizes? (e.g. 1024×768, 1280×800, etc.)
Does it cause temporary slowdowns or lockups?
Does it crash the browser or browser panel?
Does key functionality and layout work consistently across the major browsers?
Does your app work consistently across all the devices you wish to support, including mobile?

A Few References

Here are a few articles and websites for that are handy to have as references:

https://www.w3.org/

https://wiki.mozilla.org/Main_Page

https://www.w3.org/TR/CSS2/cover.html#minitoc

https://taligarsiel.com/Projects/howbrowserswork1.htm

https://ejohn.org/blog/how-javascript-timers-work/

https://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html

https://hacks.mozilla.org/2010/05/firefox-4-the-html5-parser-inline-svg-speed-and-more/