Surfin' Safari

Optimizing Page Load Time (and a little about the Debug menu)

Posted by Maciej Stachowiak on Monday, October 30th, 2006 at 11:28 pm

We don’t usually just repost content from other blogs here. But a lot of web developers seem to read this site, and those of us who work on WebKit are totally into loading web pages as fast as possible. With that in mind, here’s a great article on Optimizing Page Load Time. I recommend reading and applying much of the advice here. However, I’ll note that we have experimented with using HTTP pipelining for Safari in the past, too many major servers gave garbage results in the face of it. While we may periodically re-evaluate this, we are not holding back on it out of spite or anything.

Another tip you might find handy as a web developer is the “Show Page Load Test Window” option in the Safari Debug menu. You can turn on the Debug menu by typing defaults write com.apple.Safari IncludeDebugMenu YES at a shell prompt, and then restarting Safari. This menu includes a number of rough debugging tools that we created mainly for browser testing, but you may find some of them handy for web development. The page load test in particular is interesting because it measures page load time in a more precise way than either onload timing or just using a stopwatch. If you change the “Suite” pop-up menu to “URL”, you can type the URL of your choice and get a fairly precise time for loading it. If you empty the cache first, you can get an uncached time.

I recommend trying this a couple of times as you test your site. We’ve found that it’s a lot easier to improve performance when you have a precise way to measure it.

15 Responses to “Optimizing Page Load Time (and a little about the Debug menu)”

  1. sulka Says:

    The Page Load Test would be pretty cool – if it fully worked.

    I just tried it with the release version (419.3) and today’s Nightly (rev 17472) and I’m getting inconsistent results on every page load. The amount of downloaded bytes varies wildly from negative amounts to ten times the actual download (first load for a page 55,1 MB, second load 11,1MB, then -42,7MB – clear cache before test enabled). The nodes value also seems to give a random number (first load: -13472 nodes, then 2837 for same page, then 278). Does the nodes refer to amount of DOM nodes? If so, that’s a nice load stat.

    The Clear Cache setting doesn’t seem to have any effect so I’m not sure what’s being downloaded and what’s not, the load times are also inconsistent although in line with how fast the page shows up.

    I tried hunting for bugs about this but my searches kept on finding some hundreds of bugs so not sure if I should report this. Using 10.4.8 on Powerbook G4.

  2. maciej Says:

    The nodes and memory amount refer to changes in memory being used by the browser. They don’t relate to DOM nodes or amount of data downloaded. Sorry if that’s confusing!

  3. ahruman Says:

    I got weird values too… but it did tell me Safari was leaking memory. :-)

  4. xenon Says:

    @sulka, the network will cause wide variance with the PLT. I recommend you download the site locally and disable the network and you will see very consistent times. Other things like Spotlight should be disabled to prevent outside slowdowns also.

  5. Mark Rowe Says:

    xenon, downloading the site locally defeats the purpose in testing page load times over the network, don’t you think? :-)

  6. Pingback from Faster Page Loading - Professional PHP:

    [...] speed. In fact the Safari browser blog endorses Aaron Hopkins article and mentions how to measure page loading times in Safari using the debug menu. On the Mozillia front, the Tamper Data extension generate [...]

  7. Thinine Says:

    Can’t you deal with bad responses when using HTTP pipelining? Just rerequest the page without using pipelining. Sure, slower for that page, but you get the speedup with all the rest. Or at least give us the ability to turn it on in WebKit/Safari.

  8. maciej Says:

    The problem is that you can’t tell when you are getting a bad response. The symptoms are things like a connection hang, or the results from multiple responses getting mixed together so you’ll get headers and data from more than one response mixed together. If it was possible to identify a bad response definitively we could do a retry thing.

  9. Pingback from Fading Roses & Raging Viruses » Optimizing Page Load Time:

    [...] Data extension can offer similar data in less easy to interpret form. And the Safari team offers a tip on a hidden feature in their browser that offers some timing data too. Or if you are familiar with the [...]

  10. Pingback from Fading Roses & Raging Viruses » Optimizing Page Load Time:

    [...] Data extension can offer similar data in less easy to interpret form. And the Safari team offers a tip on a hidden feature in their browser that offers some timing data too. Or if you are familiar with the [...]

  11. heckenpenner_rot Says:

    How do you guys manage connections? Is there some sort of connection pool that keeps existing connections alive? Do you open multiple connections to the same hostname?

  12. aaron42net Says:

    One interesting quirk of many modern browsers (including at least Firefox/2 and Safari/419.3) is that external javascript and CSS is fetched serially rather than making use of the 2 or more parallel connections available.

    As an example, Slashdot seems to load 5 external stylesheets and 12 external javascript URLs, while Digg loads 2 external stylesheets and 21 external javascript URLs. Loading these serially means at least 17 and 23 round-trips respectively between browser and server. At 100ms per round trip, this adds 1.7 or 2.3 seconds above any transfer times for the data. If Safari could spread these loads over 2 connections instead, these extra delays would be cut in half.

    I understand that both CSS and Javascript have to be applied/executed in a specific order. But how hard would it be to begin fetching them sooner?

    – Aaron

  13. Pingback from Sanal Bilgi Bankası » Blog Archive » Optimizing Page Load Time:

    [...] offer a similar graph if you make use of its hidden graphing feature. And the Safari team offers a tip on a hidden feature in their browser that offers some timing data too. Or if you are familiar with the [...]

  14. mdknapp Says:

    To enable the debug menu in Safari 3 for Windows:
    ===============================
    In the file:
    C:\Documents and Settings\USERNAME\Application Data\Apple Computer\Safari\Preferences

    Add the following:
    IncludeDebugMenu

  15. cyrilgodefroy Says:

    For those reading this post after June 2007, WebKit now has a wonderful Web Site Inspector. It’s available on Safari for Mac or PC. And apparently Safari now parallelizes the download of css files, maybe even js. Maybe another reason it’s faster than some other browsers?