Ochrona wtyczek: izolowane procesy
Dość długo przeglądarka i jej wtyczki pracowały w tych samych procesach. To lekkomyślność, bo tym samym wszystkie elementy współdzielą ten sam obszar pamięci RAM – luka bezpieczeństwa w jednym z nich zagraża stabilności całej przeglądarki. Problem narasta, gdy do dziur w przeglądarkach dołoży się luki występujące w bardzo podatnych na nie wtyczkach, takich jak Flash Player, PDF Reader i QuickTime.
W Chrome’ie Google wyeliminował ten słaby punkt, traktując każdą nowo uruchomioną
kartę czy okno jako oddzielny proces. Zawieszenie się jednej z otwartych stron nie blokuje całej przeglądarki. Kiedy okazuje się, że jedna z kart ma ponadprzeciętne zapotrzebowanie
na zasoby komputera, użytkownik może ją zamknąć za pomocą Chrome Task Managera. Ponadto przeglądarka traktuje uruchomione wtyczki również jako niezależne procesy. Tę samą zasadę wykorzystał Apple w WebKit2. Ponieważ jest on niekompatybilny z poprzednikiem, to działa dopiero w Safari od wersji 5.
Firefox, począwszy od wersji 3.64, uruchamia wtyczki w zewnętrznym procesie. Komunikacja pomiędzy silnikiem przeglądarki a na przykład odtwarzaniem elementów flash odbywa się przez wtyczkę API. Firefox nie izoluje więc pojedynczych kart. Ten rodzaj ochrony pojawi się dopiero w czwartej wersji przeglądarki.
JavaScript: optymalizacja dla wielordzeniowości
Im intensywniej twórcy stron stawiają na wygląd i rozbudowane funkcje Web 2.0, tym więcej obiektów JavaScript musi przetworzyć przeglądarka. Za wykonanie funkcji JavaScript odpowiada interpreter, który analizuje kod i wykonuje działania. Metoda ma tę zaletę, że interpreter pracuje na każdej platformie niezależnie od typu procesora, ale jest też bardzo powolna. Dobrym przykładem jest Internet Explorer 8.
Inne przeglądarki, aby ominąć ten problem i zwiększyć wydajność, przetwarzają w czasie pracy często używane fragmenty kodu (np. pętle) na kod przemaszynowy. Oprócz tego przy ponownym otwarciu przeglądarki wcześniej skompilowane części kodu mogą zostać załadowane do pamięci RAM. W tym celu od wersji 3.1 Firefox implementuje do interpretera kompilator JIT (Just-in-Time). To właśnie jeden z powodów dlaczego od tego czasu jest on wielokrotnie szybszy niż IE8.
Współczesne silniki najszybszych przeglądarek, takich jak Chrome czy Opera, kompilują jeszcze więcej: tłumaczą kompletne funkcje JavaScript i włączają w to kody, takie jak rozwijane menu czy przegląd otwartych kart, które wykonają dopiero później. Ta metoda przynosi największe efekty tylko wtedy, kiedy kompilacja i wykonanie JavaScript przebiegają równolegle w dwóch rdzeniach. Nowoczesny sprzęt bez problemu spełnia ten warunek, bo nawet stary procesor Pentium 4 wykonuje obliczenia na dwóch wirtualnych rdzeniach.
W porównaniu z aktualną wersją Firefoksa, przeglądarki Chrome i Opera przetwarzają JavaScript dwa razy szybciej. Również IE9 i Firefox 4 zmierzają w tym kierunku.
Siła procesora graficznego: szybsze wyświetlanie
Po wykonaniu kodu strony kolejnym etapem jest jego graficzne przedstawienie na ekranie.
W Windows przeglądarka wysyła wyliczony kod do Graphics Device Interface (GDI). GDI, oprócz wyświetlania grafiki rastrowej takiej jak JPEG-i, odpowiada również za rysowanie linii i krzywych oraz renderowanie czcionek. Jednak GDI wykorzystuje do tego procesor, chociaż karta graficzna poradziłaby sobie z tym o wiele szybciej. Dlatego Microsoft wprowadził do Direct2D i DirectWrite dwa nowe interfejsy, które przydają się do przetwarzania grafik wektorowych i tekstów. Dzięki temu wyświetlanie animowanych grafik i pisma odbywa się szybciej i płynniej.
Dotychczas tylko wersje preview Internet Explorera 9 oraz alfa Firefoksa 3.7 wykorzystują
procesor graficzny, ale inni producenci również nie przejdą obok tego obojętnie – szansa na wzrost wydajności jest zbyt duża. Chociaż implementacja w Firefoksie nie jest jeszcze gotowa, to przeglądarka już teraz wyświetla wiele stron dwa razy szybciej. Ta metoda działa jednak tylko z kartą graficzną DirectX9 pod Vistą i Windows 7. Pomijając Microsoft, jest to spory problem dla programistów przeglądarek, bo ich aplikacje mają też pracować na innych platformach.
Żadnych kłopotów nie powinno im sprawić natomiast zaimplementowanie technologii WebGL, która zapewnia wyświetlanie 3D, np. gier komputerowych, bezpośrednio w przeglądarce. Warunkiem, jaki musi być spełniony, żeby przeglądarka mogła obsługiwać WebGL, jest karta graficzna zgodna z OpenGL 2.0. W przeciwieństwie do DirectX OpenGL działa również pod systemami MacOS X i Linux. Wszystkie przeglądarki oprócz Internet Explorera mają już wbudowaną wersję preview tej technologii. Microsoft na razie nie planuje wprowadzenia do IE9 WebGL-a, motywując to tym, że ta technologia nie jest częścią nowego sieciowego standardu HTML 5. Czas pokaże, czy Microsoft to wytrzyma, bo dopiero z WebGL i standardem HTML 5 po raz pierwszy Internet 3D otrzymuje swoją realną szansę. Również pozostałe technologie przyspieszania przeglądarek stanowią ważną podstawę prawidłowej pracy kolorowego i interaktywnego HTML 5.
