Category: Browsers

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:

  1. How much CPU does it consume? Test it on a moderately configured machine, typical of what your users might have.
  2. 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.
  3. Is everything in the correct locations in the user interface at various common browser sizes? (e.g. 1024×768, 1280×800, etc.)
  4. Does it cause temporary slowdowns or lockups?
  5. Does it crash the browser or browser panel?
  6. Does key functionality and layout work consistently across the major browsers?
  7. 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/

CPU Usage loading web site with quad-core laptop
Loading an unnamed website using a quad-core laptop

From 56K Baud to FiOS – how far have really come?

While searching for a connector in some boxes of long forgotten electronics detritus, I came across a 56K PC Card modem from 3Com. I immediately grabbed the card and thumbed it over in my hands and wondered how far have we really come since then? For those of you that never had dial-up access to the internet, this was the hottest ticket back in the ancient days of 1999. 56K was smoking back then! My conclusion: we’ve come far, but we also have taken many steps backwards. We have, in many respects, become victims of our own success.

Let me explain. Yes, first let me acknowledge that there are companies like Verizon that sell FiOS with download speeds of 15Mb/second or greater depending on how much money you want to pay. And, there are plenty of DSL and Cable internet vendors that offer 3MB/second (or more) download speeds. Oh, and I can’t forget the promise of 4G cell phone speeds.

But, reality is a far, far different animal than promises. There are plenty of times when you may not get anywhere near the download speeds promised due to a variety of technical issues. In my experience, it’s actually rare that I get to benefit the full capabilities of the cutting edge, 21st Century internet technology at my disposal. For example, if you have a 15Mb/second FiOS connection it doesn’t guarantee that every website you go to will download at 15Mb/second everytime. That’s a fact.

On any given day, we are all dependent on many factors that affect internet download speeds. The list is huge and is by no means limited to the following. Let me roughly say that all these items affect how fast something will download:

  • Number of users hitting a particular website
  • That websites hardware and bandwidth capabilities
  • General internet backbone traffic
  • Your own internet/cable modem
  • General packet collisions/losses/overhead
  • The wire or wireless connection you are using
  • Your own network card or wireless card on your computer.
  • Background processes running on your computer
  • Cell phone tower signal strength and number of users
  • And so, so many more…

I could go on for several pages, but you get the idea. Since I’m a web application developer, I have to pay attention to how fast pages load. And I often monitor and test internet connections to try and figure out where the performance problems are. Perhaps, this makes me more sensitive and less patient when I don’t receive the full benefit of the connection to the internet when it’s offered to me at my home, at work, or when traveling and using a conference or hotel wireless connection.

This is the internet age right? I have come to expect instantaneous downloads and hiccup free streaming video, but it’s very rare that I can watch a YouTube video without it stuttering and pausing to re-buffer every 15 seconds. Or, how many of you have continuously fast access to the internet via your AT&T iPhone? If you never have any problems you’re either lucky and live in a less congested area, or you aren’t a power user and are okay with downloads occasionally taking longer than expected.

There’s an immutable law that we always forget about it and it says “bandwidth is finite”.  We are very capable of building applications that consume more and more bandwidth every day.  There are millions of videos added to the interent every hour and ever larger files being downloaded. And, as tens of millions of more people buy smarthpones, they too are continuously consuming internet bandwidth 24 hours a day. And, so on and so forth the argument goes on.

In conclusion, as web developers we can do our part for improving people’s internet experience by optimize your web applications as much as possible. Make your web applications file sizes as small as possible, use lazy loading, run code optimizers, consider binary formats for moving large data back and forth, and optimize images were possible. In the end, we will all benefit from a better internet experience.

IE 8 Developer Tools – A great step in the right direction.

Even though IE 8 Developer Tools have been around for a while, since Internet Explorer 8 Beta 1 (circa 2008), there are still a lot of developers out there who aren’t familiar with it. And, it’s well worth the time learning about it. Some of you may be wondering who develops against IE? Well, before I dive into the details, I wanted to say a word about that. According to w3schools as of October 2010, IE represents 29% of all browsers, and IE 8 browsers make up more than half of that number.

You should research your own website stats, and companies such as w3counter provide developer tools for that. In general, it’s fair to say that most consumer sites get a lot of IE-based traffic, and testing your app against IE is a good idea. If you don’t, there’s a strong chance you’ll frustrate a bunch of potential users and they may not come back, ever. If you run an internal site for an organization then you may have more control over which browsers (and browser versions) are used, and your life is probably easier than the rest of us.

I know I personally didn’t like testing against IE because with IE 6 and 7 the tools were pretty much non-existent and extremely unfriendly to web developers. I have to say that IE 8 made a huge step forward in my eyes when they included Developer Tools. Sure I have plenty of gripes, but all-in-all my job got much easier. Instead of blindly making changes and then reloading the page to see the results, I now do the majority of my testing and prototyping right in the Developer Tools.

Here just a few of the tools I find particularly useful:

  • Built-in Script debugger. Yep, it includes console, breakpoints, locals, watch and call stack.
  • Edit on-the-fly.
  • Inspect CSS.
  • Select element by click (Ctrl + B).
  • Clear cookies for domain
  • Tools > Resize (on-the-fly)
  • Show ruler.
  • Save HTML or CSS changes to a file.

I still have a wish list of things I’d like to see added, here’s my top five:

  1. Built-in HTTP transaction viewer. I mean they have Fiddler, why not bolt key pieces of it into the browser tools rather than having to launch Fiddler separately?
  2. DOM attribute inspector for those times when you have to dig deep; for example, when there are differences between content attributes and DOM attributes.
  3. Cookie Manager – including the ability to inspect/delete individual cookies.
  4. Automatically associate a selected element with its DOM index. Don’t make me have to hunt for it in a different view and then compare.
  5. Continuous hover and select item on page, without needing to click Ctrl + B every time. Sometimes I want to scan multiple items quickly.

So that’s it. This tool should save you a ton of time. Are there any items that are your favorites, and what do you want added to the wish list?