Monday, June 7th, 2010

Safari 5: Features, Performance, Standards

Category: Browsers, WebKit

>Safari 5 got out of the gate a touch early as the PR team shot their new release out before anything else was out there:

“Safari continues to lead the pack in performance, innovation and standards support,” said Philip Schiller, Apple’s senior vice president of Worldwide Product Marketing. “Safari now runs on over 200 million devices worldwide and its open source WebKit engine runs on over 500 million devices.”

Safari Reader makes it easy to read single and multipage articles on the web by presenting them in a new, scrollable view without any additional content or clutter. When Safari 5 detects an article, users can click on the Reader icon in the Smart Address Field to display the entire article for clear, uninterrupted reading with options to enlarge, print or send via email.

Powered by the Nitro JavaScript engine, Safari 5 on the Mac runs JavaScript 30 percent faster than Safari 4, three percent faster than Chrome 5.0, and over twice as fast as Firefox 3.6.* Safari 5 loads new webpages faster using Domain Name System (DNS) prefetching, and improves the caching of previously viewed pages to return to them more quickly.

Safari 5 adds more than a dozen powerful HTML5 features that allow web developers to create media-rich experiences, including full screen playback and closed captions for HTML5 video. Other new HTML5 features in Safari 5 include HTML5 Geolocation, HTML5 sectioning elements, HTML5 draggable attribute, HTML5 forms validation, HTML5 Ruby, HTML5 AJAX History, EventSource and WebSocket.

The new, free Safari Developer Program allows developers to customize and enhance Safari 5 with extensions based on standard web technologies like HTML5, CSS3 and JavaScript. The Extension Builder, new in Safari 5, simplifies the development, installation and packaging of extensions. For enhanced security and stability, Safari Extensions are sandboxed, signed with a digital certificate from Apple and run solely in the browser.

Some great features in there. Let’s get into some details:

Performance

Sam Pullara quickly ran Sun Spider on Chrome 6.0.422.0 and Safari 5 and the result is very close to a dead heat:

Safari 5 Total:         279.2ms +/- 1.9%     | Chrome 6 Total:      274.6ms +/- 6.2%
-------------------------------------------- | --------------------------------------------
  3d:                    36.0ms +/- 2.4%     |   3d:                   43.6ms +/- 18.0%
    cube:                12.8ms +/- 4.3%     |     cube:               16.0ms +/- 11.0%
    morph:               10.6ms +/- 6.4%     |     morph:              14.6ms +/- 32.2%
    raytrace:            12.6ms +/- 5.4%     |     raytrace:           13.0ms +/- 11.7%
                                             |
  access:                32.2ms +/- 5.0%     |   access:               30.6ms +/- 11.0%
    binary-trees:         5.4ms +/- 12.6%    |     binary-trees:        1.4ms +/- 48.6%
    fannkuch:            12.8ms +/- 4.3%     |     fannkuch:           12.2ms +/- 4.6%
    nbody:                8.6ms +/- 7.9%     |     nbody:              13.8ms +/- 17.3%
    nsieve:               5.4ms +/- 20.6%    |     nsieve:              3.2ms +/- 17.4%
                                             |
  bitops:                17.6ms +/- 13.8%    |   bitops:               22.6ms +/- 6.3%
    3bit-bits-in-byte:    2.4ms +/- 28.4%    |     3bit-bits-in-byte:   1.6ms +/- 42.6%
    bits-in-byte:         5.2ms +/- 10.7%    |     bits-in-byte:        5.8ms +/- 9.6%
    bitwise-and:          4.0ms +/- 69.5%    |     bitwise-and:         7.0ms +/- 0.0%
    nsieve-bits:          6.0ms +/- 0.0%     |     nsieve-bits:         8.2ms +/- 6.8%
                                             |
  controlflow:            2.8ms +/- 19.9%    |   controlflow:           2.4ms +/- 28.4%
    recursive:            2.8ms +/- 19.9%    |     recursive:           2.4ms +/- 28.4%
                                             |
  crypto:                16.6ms +/- 4.1%     |   crypto:               19.0ms +/- 9.3%
    aes:                  9.6ms +/- 7.1%     |     aes:                 7.6ms +/- 14.6%
    md5:                  4.0ms +/- 0.0%     |     md5:                 5.6ms +/- 12.2%
    sha1:                 3.0ms +/- 0.0%     |     sha1:                5.8ms +/- 9.6%
                                             |
  date:                  34.6ms +/- 2.0%     |   date:                 28.2ms +/- 7.2%
    format-tofte:        20.0ms +/- 0.0%     |     format-tofte:       13.4ms +/- 8.3%
    format-xparb:        14.6ms +/- 4.7%     |     format-xparb:       14.8ms +/- 7.0%
                                             |
  math:                  26.2ms +/- 4.0%     |   math:                 29.4ms +/- 8.8%
    cordic:               7.6ms +/- 9.0%     |     cordic:              9.4ms +/- 25.8%
    partial-sums:        13.0ms +/- 0.0%     |     partial-sums:       15.2ms +/- 10.7%
    spectral-norm:        5.6ms +/- 12.2%    |     spectral-norm:       4.8ms +/- 11.6%
                                             |
  regexp:                12.8ms +/- 4.3%     |   regexp:               16.0ms +/- 0.0%
    dna:                 12.8ms +/- 4.3%     |     dna:                16.0ms +/- 0.0%
                                             |
  string:               100.4ms +/- 1.4%     |   string:               82.8ms +/- 2.0%
    base64:              11.6ms +/- 5.9%     |     base64:              6.6ms +/- 10.3%
    fasta:               14.0ms +/- 0.0%     |     fasta:              12.0ms +/- 0.0%
    tagcloud:            23.0ms +/- 0.0%     |     tagcloud:           23.8ms +/- 5.7%
    unpack-code:         35.2ms +/- 3.0%     |     unpack-code:        29.0ms +/- 0.0%
    validate-input:      16.6ms +/- 4.1%     |     validate-input:     11.4ms +/- 6.0%

Standards

Now, lets look at how they size up in BrowserScope:

Topic Chrome Safari
Security 12/13 10/13
Rich Text 129/149 129/149
Selectors API 99.3% 99.3%
Network 9/16 10/16
Acid3 100/100 100/100

Incredibly close. Not that it should be a shock, since both parties are using WebKit under the hood (although the JS engines are totally different, and many other differences!)

Extensions

Panic were up on stage showing off Code Notes, a nice example of extensions for Safari:

The Coda Notes extension is built entirely in JavaScript, HTML, and CSS; the extension bar is basically an HTML file, and the page-flip effect is accomplished using a CSS transform. We draw on a transparent canvas element injected over the target page. Live text editing is done by setting the contentEditable attribute on the body of the page, thus turning Safari into an editor.

Great to see the new extension mechanisms on the Web are all of the Web (Chrome, Safari, Jetpack). Very cool indeed.

Related Content:

Posted by Dion Almaer at 8:15 pm
9 Comments

+----
1 rating from 1 votes

9 Comments »

Comments feed TrackBack URI

That’s weird. I get 100/100 on the Acid3 test in Safari 5.

Comment by devongovett — June 7, 2010

Well I don’t know what computer you are running, but I got around 100ms less on SunSpider test with Chrome. But it is great to see JavaScript fast on all browsers! Before V8, no1 really cared, but now, everyone does!

Some HTML5 features are not fully working, such as GeoLocation, it says it exists, but it never returns any lat/long.

Comment by MohamedMansour — June 7, 2010

Having spent the last two days trying to emulate CSS3 features in IE (rgba, box-shadow, etc), I can just dream of a world in which most users run WebKit. For that alone I want Apple and Google to succeed, regardless of being overpriced or privacy-busters.

Comment by BonoboBoner — June 8, 2010

For enhanced security and stability, Safari Extensions are sandboxed, signed with a digital certificate from Apple and run solely in the browser.

Err, so all extensions will have to be approved by Apple (like the App Store, which makes me suspect we have to pay before we can submit them) and they won’t be able to do anything with the file system.

Sigh. A little more freedom please?

Comment by dorward — June 8, 2010

Performance comparisons are lame as long as they don’t compare against the leader of the pack – and that’s currently Opera.

Comment by wortwart — June 8, 2010

I obtain a minimally different result with Safari 5 on Snow Leopard: Acid3 is 100/100. It’s also 100% on http://acid3.acidtests.org/

Safari 5.0 85/100 10/13 129/149 99.3% 10/16 100/100

Comment by zhell — June 8, 2010

Great write up! Awesome to see these browsers so close. I’m interested to see where Apple takes these extensions. I could see Apple creating an “Extension Store” similar to Google Web App Store. Maybe we could even write extensions that could/would look & function natively on iOS devices! How cool would it be to create apps for iTV (my prediction for the name Apple will give the next iteration of the Apple TV), iPhone/iPod Touch, and iPad by writing Extensions?!

Comment by wantar — June 8, 2010

Ported a Chrome extension to Safari extension. It works well and event works on PC!

Comment by learnr — June 8, 2010

I love most of the work the Safari and WebKit teams are doing, but there are things that have kept me from upgrading for a while, mostly due to a couple of really stupid UI mistakes, one of which belongs in the UI Hall of Shame of yore.

By far the worst offender is their tab implementation. Top tabs I could take or leave (although the UI I’ve stuck with is that of the Safari 4 Public Beta, which had top tabs), but there is no excuse for the implementation they released with Safari 4 (and evidently kept with Safari 5). This implementation seems pretty innocuous and looks nice enough, until you open more tabs than can be fit in the window. At this point, any overflow tabs visibly rotate into position N (where N is the number of visible tabs possible). So (for N = 10) if you open 11 tabs, you’ll see tabs 1–10, unless you view tab 11, in which case you’ll see tabs 1–9,11. If you open 20 tabs then view tab 20, you’ll see 1–9,20. If you view tab 15, you’ll see 1-9,15. This is a usability nightmare.

At the risk of sounding personal and petty, I think this is probably something ordered from on high (The Steve™). Apple designers know better than to make mistakes like this, and by and large their UI choices are pretty solid. That it survived into Safari 5 is just sad.

Comment by eyelidlessness — June 9, 2010

Leave a comment

You must be logged in to post a comment.