November 24th, 2008
Steve Souders is currently doing more to improve the performance of web pages and web browsers than anyone else out there. When he worked at Yahoo! he was responsible for YSlow (a great tool for measuring ways to improve the performance of your site) and he wrote the book on improving page performance: High Performance Web Sites. Now he works for Google but much of what he's up to is the same: Making web pages load faster.
I've been really excited about one of his recent project releases: UA Profiler. The profiler is a tool that you can run in your browser to determine the status of a number of network-performance-specific features that tie heavily to browser page load performance.
Here's a look at the current breakdown:
We can see Firefox 3.1 taking a lead, fixing 9 out of 11 of the issues tested for. Firefox 3, Chrome, and Safari 4 all come after with 8 fixed. Firefox 2, Safari 3.1, and IE 8 next at 7. Those numbers help to give you an overall feel of the page load performance that you'll see in a browser. (Naturally these tests don't take any rendering or JavaScript performance numbers into account but network performance generally trumps their total runtime anyway.)
Information about network performance is important for two reasons:
- It informs browser vendors as to the quality of their browser. A browser fixing any of the points specified by the test will yield faster page loads.
- It informs web site developers as to the problems they should be taking into consideration when developing a site. For example if a browser they support doesn't handle simultaneous stylesheet downloading perhaps their page should be re-worked.
The tests themselves can be broken down into a couple categories (Steve explains them all, in detail in the FAQ):
Network Connections
Two big things are tested here: The number of simultaneous connections that can be opened to a hostname (sub-domains count as different hostnames) and how many connections can be opened to any number of hostnames, simultaneously. These numbers can give you a good indicator of how many parallel downloads can occur (most commonly seen for downloading multiple images, simultaneously).
Additionally there is a check to see if the browser supports Gzip compression. The results aren't too exciting here as all modern browsers support Gzip compression at this point.
Parallel Downloads
All browsers are capable of downloading images in parallel (multiple images downloading simultaneously) but what about other resources (like scripts or stylesheets)?
Unfortunately it's much harder to get scripts and stylesheets to load in parallel since their contents may dramatically change the rest of the page. The loading of these resources occur in three steps:
- Downloading (can be parallelized)
- Parsing
- Execution
The load order breaks down like so (sort of an advanced game of rock-paper-scissors): Scripts prevent other scripts from parsing and executing, stylesheets prevent scripts from parsing and executing.
It's been hard for browsers to implement the parallelization of script downloading since scripts are capable of changing the contents of the page - and possibly removing adding new scripts or stylesheets to the page. Because of this browsers are starting to get better at opportunistically looking ahead in the document and pre-loading stylesheets and scripts - even if their actual use may be delayed.
Changes in this area will yield some of the largest benefits to browser page load performance, going forward, as it's still one of the most untapped areas of improvement.
Caching
While all modern browsers support caching of resources, caching of page redirects is much less common. For example, consider the case where a user types in "http://google.com/" - Google redirects the user to "http://www.google.com/" but only a couple browsers cache that redirect as to not retry it later.
A similar case of redirect caching occurs for resources, for example with stylesheets, images, or scripts. Since these occur much more frequently it becomes that much more important for browsers to cache every action that they can.
Prefetching
This is part of the HTML 5 specification and allows for pages to specify resources which should be opportunistically downloaded in case they should be used in the future (the common example of image rollovers could be used here).
There's a full page describing how to use them on the Mozilla developer wiki but it isn't that hard to get started. It's as simple as including a new link element in the top of your site:
<link rel="prefetch" href="/images/big.jpeg">
And that resource will be downloaded preemptively.
Inline Images
The final case that the profiler tests for is the ability of a browser to support inline images using a data: URI. Data URIs give developers the ability to include the image data directly within the page itself. While this saves an extra HTTP request it's important to note that the resource will not be cached (at least not as external resource - it may be cached as part of the complete page). The use of this technique will vary on a case-by-case basis but having a browser support it is absolutely important.
Going forward it will become increasingly important to have publicly-visible tests like the UA Profiler that are able to encourage browser vendors to act quicker at implementing critical browser functionality. Anything that's able to, even indirectly, improve the performance of the browsing experience for users of the web is absolutely critical, in my book.
Tags: browser, performance, network
18 Comments on 'Browser Page Load Performance'
July 1st, 2005
I had a chance to play with a fun new social application today called Dinnerbuzz. The premise is simple: It's a social network for people to find new places to eat - and to mark off the ones that they've already visited. I signed up and started testing it out. There's only a handful of users from around the country on the site, and none from my city, Rochester, NY. So, coupled with the efforts of my girlfriend Julia we set about entering a number of new places into the database.
Adding a new restaurant to the database isn't 'that bad'. There's a simple form, you provide the name of the restaurant, it's relative location (you can even be vague, which is nice), tags, and a description. All of this is powered by the Yahoo Local API, making sure that all restaurants entered are correctly identified and labeled. If a restaurant is not in the API is has to be approved by an admin, which seems kind of silly for a user-submitted web site.
Now, it's time for some complaints: The tags are certainly interesting, in this context, but I'm not really sure if they work for restaurants. Some tags are immediate 'chinese', 'italian', 'pizza', etc. But how should you tag price ranges, food quality, or experience - it becomes incredibly confusing from person-to-person and daunting to manage within a single account. Should you say 'expensive' or '$20' - if you say 'nice' are you referring to the food or the service? I've found myself using the tag 'moderate' - but does it mean moderate price or moderate quality? Who knows! This may be one application to which tagging, of this kind, is not ideally suited.
I should warn you, however, that there are still a couple bugs in the system, and the GUI isn't completely flushed out yet. For example, there's no way to delete an entry once you've submitted it. (Update: This feature has since been added. Thanks Justin!) I went through and provided ratings for every restaurant that I had been to, including national chain franchises. In retrospect, I'd like to delete the national chain entries, as they're so commonplace that another review seems redundant. I'm going to try and limit myself to local restaurants and local chains. Also, whenever tags are listed, they're listed as 'Recent Tags', which is rather useless (In my opinion) and should be a delicious-like 'Popular Tags'.
Additionally, there doesn't seem to be any sort of 'friends' or 'contacts' feature - I would definitely like to be able to see where my friends are eating and what they think of those places - the results of which I would use in the future.
I think there's a lot of potential for this service, there's RSS everywhere which is nice because I've been looking for some way to pull my latest dining experiences into a feed - and this may be it. Considering that the service is still in its, relative, infancy I'm looking forward to seeing other users join and provide their input. It would be very cool to see other services tied in too, such as Flickr, Upcoming.org, and 43Places. So, on that note - here's my profile, now go and contribute!
Tags: food, restaurants, dining, social, network, web, app, local, yahoo, dinnerbuzz
5 Comments on 'Dinnerbuzz Review'
March 14th, 2005
Something that I've been tinkering around with the past couple of days is the concept of providing visual cues to associate a name with a face, so to speak. For example, I find it to be much easier, mentally, to make the connection between someones face and who they are then someone's cryptic username (which, in turn, is associated with someone's name, then associated to a face - a much, much slower process, for me, that results in a lot of dead ends). To combat this, I've been making a lot of changes to my personal data. The most notable of which is: Locating a headshot picture of all of your friends. In theory, I want to quickly and easily associate someone's online persona with their real life person. It's a challenge and I'm not yet sure how well it will go. However, in order to test it, the first step is to find as many friend headshots as possible. Here are a couple resources that I've used, thus far:
Now that you have a nice list of pictures for all of your friends, here is what you can do: Associate that picture with that person everywhere possible. The first thing that I did was to update the buddy icons for all of my AIM buddies. This gave me a highly usable visual buddy list to browse (also pictured above). The second step was to associate the images with all of my frequent email contacts. Thankfully, OSX makes this process terribly easy. I can take an email address/name from Mail.app, right-click, and add it to my address book. I can then edit the address book entry for that user and add their AIM buddy name. Now I've tackled two of my most frequently used forms of communication: Instant Messenger and Email, but that still leaves a large ocean uncharted: The web.
At this point in the game, I decided to go back to my old friend GreaseMonkey. Essentially, I wanted to write a script that would search through a page looking for certain names, nicknames, and usernames and insert an image to be associated with it. And so, that's what I did. Right now it's very rough around the edges and requires a lot of user customization.
- name2face - This script requires a lot of configuration. Please modify the data structure within the program to change which users you would like to match and display for, otherwise you'll just see a few of my friends, currently.
Ideally I'd like this plug-in to pull from some sort of a dynamic XML repository (possibly in FOAF format?) that could be updated easily. The results are very interesting. Browsing social networking sites, Gmail, and other forms of communication have taken on a whole new feel. I really feel that a service like this has a lot of potential and should be explored more fully, which I hope to do soon.
Tags: friends, greasemonkey, network, social, visual
27 Comments on 'Visual Friend Identification'
