SunSpider a przeglądarki: aktualne wyniki

Postanowiłem przetestować gorące jeszcze Safari 4, ogłoszone wczoraj jako finalne, wraz z odpowiadającymi mu przeglądarkami, a mianowicie: Operą 10 (pierwsza beta), Firefoksem 3.5 (czwarta beta) i Chrome 2.0 (wersja stabilna) oraz: Chrome 3.0 (beta), Firefox 3.5 Preview. Posłużyłem się testem SunSpider.

Wymieszanie wersji stabilnych i testowych było świadome – uważam, że przeglądarki są na zbliżonym etapie rozwoju pod względem technologicznym (w tym przypadku funkcjonalność, rzecz jasna, nie ma większego znaczenia). Byłem natomiast ciekaw, czy rzeczywiście Safari 4 prześcignie pozostałe czołowe przeglądarki. Zapewnia o tym Apple opublikowanymi przez siebie diagramami. Moją wątpliwość wzbudził brak Opery (nie ma nawet stabilnej dziewiątki).

Część moich przypuszczeń się potwierdziła. Wyniki różnią się od tych podanych przez Apple, co w zasadzie nie jest żadną sensacją – zapewne w różnych środowiskach wyniki będą odmienne. Zaskoczył mnie natomiast słaby wynik Opery w porównaniu do pozostałych przeglądarek. Zresztą, zobaczcie sami:

Wynik testu SunSpider (Windows)

Platforma testowa to Windows Vista Service Pack 2, zwirtualizowana dla zapewnienia możliwie równych szans. Procesor, bo to właściwie ma największe znaczenie – AMD Athlon 64 X2 6000+. Przydzielona pamięć operacyjna: 512 MB (i wystarczyło w zupełności – to tak swoją drogą). Każda z przeglądarek testowana była na nowo utworzonym profilu.

Szczegółowe wyniki testu, dla zainteresowanych:

Jeszcze słówko na temat subiektywnej oceny szybkości renderowania XHTML i CSS, a właściwie wyświetlania stron w ogóle. Co ciekawe, najszybsza pod tym względem wydaje mi się Opera 10, tuż za nią Chrome 2.0. Safari 4 i Firefox 3.5 zdają się być lekko w tyle. I to żadne odkrycie – w końcu JavaScript to tylko jedna z wielu technologii. Słowem: nuuuda ;-)

Dla porównania wyniki z Mac OS X 10.5.7:

Wynik testu SunSpider (Mac OS)

Wpis zaktualizowany o wynik Google Chrome 3 beta. Co ciekawe, Chrome 3 wypadł gorzej niż jego poprzednia (stabilna) wersja. I jeszcze jedno – Opera 9 jest uwzględniona na diagramach od Apple. Wybaczcie pomyłkę.

Kolejna aktualizacja: dodany wynik Firefoksa 3.5 Preview oraz kilka wyników na Maku (dzięki, Riddle).

Komentarze

  1. Paolo pisze:

    Wasacz a używałeś może przeglądarki Flock (z tego co wiem to nie ma wersji PL)?

  2. PACH pisze:

    IMHO "szybkości renderowania XHTML i CSS" jest najważniejsza, bo kto dziś korzysta z js? ;)

  3. Branch Predictor pisze:

    Ogólnie ostatnie działania twórców Opery są conajmniej dziwne. Słaby marketing, zmiana nastawienia z "fastest" na "bloatest", i jeszcze obiecują, że odpowiednik TraceMonkey będzie najwcześniej w jedenastce.
    Nie podoba mi się to ani trochę, co prawda obecna beta Opery 10 jest szybsza od 9.64, ale nie tyle, by robić z tego powodu wielkie halo.
    Swoją drogą, niedawno badałem wydajność (PeaceKeeperem) FailFoxa 3.5b4 i Opery 10 (ostatniej bety) - Opera 10 jest o 1/6 szybsza od FF z wyłączonym TraceMonkey, i o 1/6 wolniejsza z włączonym. Także coś to daje, najwyraźniej. Dziwi mnie, że na pomysł z "kompilowaniem" JavaScriptu musieliśmy czekać aż do pojawienia się Google Chrome.

  4. Michał Górny pisze:

    E, o jakiej „wirtualizacji” mówimy? Bo ja tu nie znam żadnej, która miałaby zapewnić „równe szanse”. Wręcz przeciwnie — zwiększa wpływ przypadku na wyniki.

    @Paolo: Flock czasem nie jest na gecko?

  5. AdamK pisze:

    Możnaby do testu dołożyć bete/dev Chrome?

  6. Wasacz pisze:

    Paolo: Nie korzystałem, nie widzę sensu. W środku jest Gecko.

    Branch Predictor: zgadzam się całkowicie, JavaScript w Operze – jak widać – zaczyna zostawać w tyle. „Bloatu” jeszcze nie ma, ale mam podobne wrażenie ;|

    Michał: Nie widzę sensu w zabawie z tworzeniem czystych profili, bo z części przeglądarek korzystam normalnie. Wirtualny system jest natomiast czysty.

    Adam: Można, poczekaj na aktualizację wpisu ;)

  7. Hoppke pisze:

    Z ciekawości odpaliłem testy na swojej (natywnej) Win 7 64bit. U mnie Opera jeszcze bardziej odstaje od reszty stawki :(
    (6879.4 Opera vs. 1152.4 Chrome). Niestety zaczyna to też być już zauważalne gołym okiem w niektórych aplikacjach javascriptowych.

  8. KORraN pisze:

    No więc właśnie... Żeby Opera dorobiła się nowego silnika JS to byłaby niemal przeglądarką idealną. A skoro Carakan jest przewidywany dla wersji 11 to podejrzewam, że Google do tego czasu poprawi bardziej denerwujące bugi w Chrome i pewnie na niego się przesiądę...

    Denerwuje mnie też, że czasami Opera nie ładuje do końca obrazków, np. w pasku pojawia się "Elementy: 55/56" i tak stoi w nieskończoność. Ale to już tak bardziej offtopicowo :P

  9. teachmeter pisze:

    No JS jest coraz ważniejszy tym bardziej ze tendencja do Jquery i tego typu ramek jest.

  10. riddle pisze:

    (Komentarz zmodyfikowany 10.06.2009 o 13:54)

    To samo na Maku (Mac OS X 10.5.7):

    • Safari 4.0: 638.0ms ±2.9%
    • Google Chrome 3.0.182.5: 728.8ms ±5.1%
    • Firefox 3.5 Beta 4: 1194.8ms ±1.2%
    • Opera 10 Beta: 4909.6ms ±3.7%

    Więc wydaje mi się, że Apple mógł mieć rację, natomiast podawać wyniki tylko ze swoich komputerów. A IE pewnie na VMware/Parallels.

    Swoją drogą, te wyniki i tak są cudowne – popatrzcie tylko na to co się wydarzyło w ciągu ostatniego roku w kwestii JavaScript i wydajności webappów.

  11. tolep pisze:

    A najśmieszniejsze jest, że najlepszym benchmarkiem jest ten zaproponowany przez... Microsoft, kilka tygodni temu. Chodziło o szybkość wczytywania kilkudziesięciu bodajże najpopularniejszych stron w internecie. To, a nie jakieś tam acidy i sunspidery, jest właśnie świat realny :)

  12. Michał Górny pisze:

    @tolep: Taki test nie ma szansy oddać realnych wyników. Najpopularniejsze strony mają do siebie to, że często uzależniają treść od UA, a w Operze np dodatkowo browser.js może próbować je naprawiać.

  13. floorek pisze:

    Warto zrobić test na dostępnym już Firefoksie 3.5 Preview. Wypada znacznie lepiej niż beta 4.

  14. Wasacz pisze:

    Hm, u mnie Safari na fizycznej maszynie wypada gorzej niż na wirtualnej, ciekawe… Zresztą podobnie pozostałe przeglądarki.

    Riddle, masz coś przeciwko, żebym zaktualizował wykres o twoje wyniki?

  15. Riddle pisze:

    Proszę bardzo. :P

  16. Wasacz pisze:

    floorek: faktycznie, Preview sprawuje się znacznie lepiej ;)

    Wpis zaktualizowany, btw.

  17. tolep pisze:

    @12. Michał Górny
    To jak najbardziej są realne wyniki. Niekoniecznie obiektywne i niekoniecznie uczciwe, ale z punktu widzenia ZU (a każdy z nas przez większość czasu jest nikim innym, jak właśnie ZU) jedyne realne.

  18. Michał Górny pisze:

    @tolep: Z punktu widzenia ZU szybsza jest przeglądarka, która po cichu długo będzie pobierać wszystko i na końcu pokaże gotowy wynik niż taka, która będzie pokazywać na bieżąco pobrane już elementy. Oczywiście, zakładając brak widocznych opóźnień ze względu na przerysowywanie okna.

  19. Branch Predictor pisze:

    Chyba właśnie odwrotnie...

  20. gandalf pisze:

    Polecam duzo bardziej rozbudowany zestaw testow od Resiga - dromaeo.com

    Tutaj wyniki na moim macu (ten numerek to Fx nightly z dzisiaj, do tego webkit z dzisiaj, Fx 3.5 i Opera 10 ostatni build)

    http://dromaeo.com/?id=67660,67654,67649,67665

  21. Wasacz pisze:

    tolep, Michał, Górny, Branch Predictor: również wydaje mi się, że jest odwrotnie niż napisał Michał (;

    gandalf: Dzięki za informację (przyda się na przyszłość) i wyniki. Jeśli się nie mylę, ten zestaw opiera się na SunSpiderze. WebKit nadal na czele. Firefox się rozpędza z kompilacji na kompilację ;-)

  22. Michał Górny pisze:

    @Wasacz: Łiii, zostałem podwójnie wymieniony!

    A w temacie, pozostanę przy swoim zdaniu. Moim zdaniem bowiem względne odczucie szybkości jest większe, kiedy np. ładowany obrazek pojawia się od razu w całości, niż kiedy użytkownik widzi, jak się rysuje od góry do dołu. I podobnie z innymi elementami strony.

    Zresztą, dlaczego do dziś przeglądarki inne niż Opera nie dorobiły się jakichkolwiek sensownych wskaźników postępu? Dlaczego tylko Opera pokazuje faktyczny czas? Ilu z Was otwiera strony patrząc na stoper?

    Nie ma czasu, pasek postępuje działa skokowo (o ile w ogóle jest), a strona pojawia się skokowo — i właściwie tylko te „skoki” podczas ładowania stają się dla użytkownika miarą czasu. Tym samym, im mniej skoków — tym szybciej załadowana strona.

    Oczywiście, nie należy tu przesadzać, bo wiadomo, że upływ kilku sekund przed pojawieniem się czegokolwiek zauważy użytkownik. Jednak przy tak małych okresach czasu, jak przy ładowaniu typowej strony, nie ma to większego znaczenia.

  23. Wasacz pisze:

    Michał, Górny: wybacz ;D

    Zresztą, dlaczego do dziś przeglądarki inne niż Opera nie dorobiły się jakichkolwiek sensownych wskaźników postępu? (…) Ilu z Was otwiera strony patrząc na stoper?

    Albo ja czegoś nie rozumiem, albo ty sobie przeczysz ;)

    W Operze przecież można wybrać taki pasek postępu, jaki się komu podoba.

  24. Riddle pisze:

    Safari 3 miało świetny pasek postępu, może nie tak dokładny jak Opera, ale zapełniający się pasek adresu był swego rodzaju progress barem. Teraz jest binarny wskaźnik. Trochę szkoda.

  25. Wasacz pisze:

    Riddle: Ten nowy nie wygląda źle.

  26. Michał Górny pisze:

    @Wasacz: To odnosiło się do tego, że użytkownik typowej przeglądarki internetowej nie ma żadnego odniesienia do upływu czasu podczas ładowania strony.

Dodaj komentarz

Proszę, formatuj komentarz za pomocą Markdown.

Wymagane pola zaznaczone są znakiem gwiazdki – „*


Obrazek z kodem

*