Benchmarks Navegadore de Internet 2012 Las Webs usadas para el consumo de RAM , as como los tiempos de inicio en fro/caliente

y cierre son: Bandeja de Gmail, Bandeja de Mail Live (Hotmail), Muro de Facebook, YouTube (http://www.youtube.com/watch?v=nAHyGbOXoF4 en 360p), MARCA, portada de El Pas, la NASA, DevianArt, Play Store, Wikipedia (https://en.wikipedia.org/wiki/History_of_the_web_browser). Para los test de 20 pestaas, simplemente se han duplicado las 10 anteriores. Test: Rendimiento o Tiempo de Inicio en fro (1, 10 y 20 pestaas) Mejorado o Tiempo de Inicio en caliente (1, 10 y 20 pestaas Nuevo o Tiempo de Cierre (20 pestaas) Nuevo o Velocidad de carga de Webs con/sin Cach Nuevo o RAM (10 y 20 pginas) o CPU/GPU reproduciendo contenido 1080p (Flash y WebM) Mejorado JavaScript o Apple SunSpider (Versin 0.9.1) o Google V8 (Versin 7) o Mozilla Kraken (Versin 1.1) Canvas o Normal Mapped Photos o Canvas Performaance Test Nuevo o Matt Pelham VII Nuevo o Asteroids Grficos o Microsoft Tanque de peces (Modificado para 3.000 peces) o Microsoft Pecera (2.000 peces) o Microsoft Come-Cocos o Microsoft SpeedReading o Microsoft Psicodlico o Webvizbench WebGL o Tanque de Peces para WebGL (20.000 peces) Nuevo o Sistema Solar Nuevo Otros o Nuevo Peacekeeper o Google Spinning Balls (Garbage Collector) Nuevo Estndares o Test de Niels para HTML5 o Microsoft IE9 Center tests (HTML5, CSS3) Actualizado a la versin del 29 de febrero 2012 o Test de Khronos para WebGL (Versin 1.0.2)

Tiempo de Inicio en Fro y en Caliente Comenzamos con los tiempos de inicio del navegador para 1, 10 y 20 pestaas, siempre a cach vaco. No se trata de medir la velocidad de carga de las pginas (que se ver ms adelante), sino el tiempo de arranque y carga del navegador ante los 3 supuestos anteriores. Inicio en fo significa que el PC no tiene cacheado en RAM nada, el equipo es reiniciado por completo, se esperan 3 minutos para que se estabilice el sistema entero y se abre el navegador pertinente, restaurando la sesin de forma automtica (de 1, 10 o 20 pestaas). Inicio en caliente implica que el sistema ya ha abierto anteriormente el navegador y ha estado trabajando con l, y por tanto mantiene en RAM mucha de la carga anterior. El tiempo es medido desde que se ejecuta el navegador hasta que todas las pestaas han terminado de cargarse (que no quiere decir que todo el contenido en ellas se haya descargado):

Opera: Fall en la carga de algunas pestaas, siendo necesario refrescarlas posteriormente (no se contabiliz ese tiempo extra) Safari: Muy inestable, constantes cierres del espacio de trabajo del navegador (proceso webkit2webprocess.exe). Safari: Picos constantes de la CPU de hasta 30%

Tiempo de Cierre En esta ocasin se ha medido tambin el tiempo de respuesta del navegador a cerrar. En teora podramos pensar que estos tiempos son prcticamente inmediatos, pero no lo son. En muchas ocasiones el navegador se mantiene como proceso de fondo durante un largo perodo de tiempo incluso, lo cual evidentemente no es deseable. Los tiempos medidos son con 20 pestaas cargadas en los navegadores, contabilizando desde el momento en el que se enva la seal kill al proceso padre hasta que el rbol de procesos de este es totalmente finalizado, incluyendo el proceso padre evidentemente. Esto es importante sobre todo en Chrome o Internet Explorer, que al ser navegadores multiprocesos tienen unas dependencias mucho mayores al resto:

Velocidad de Carga de la Web con y sin cach Este test posee un doble propsito. Por un lado medir la velocidad con la que los navegadores son capaces de descargar por completo la Web desde los servidores externos, y por otro lado medir la eficiencia del Cach de estos, realizando el test con la cach del navegador activada y deshabilitada. Hay que tener en cuenta que lo que se mide no es el tiempo que tarda el navegador en comenzar a mostrar las pginas o cargarlas por completo, sino el tiempo que tarda el navegador en descargar y preparar TODOS los recursos de las web solicitadas. Es de esperar por tanto que los tiempos en las pginas con el contenido cacheado sea mucho menor. Cada Web fue abierta de forma aislada y se sumaron los tiempos de todas ellas:

Internet Explorer 10: Los resultados que aparecen con cach pertenecen a IE9, la Preview 2 de IE 10 parece tener la cach deshabilitada

Consumo de RAM Aunque a da de hoy la gran mayora de los sistemas actuales cuentan con cantidades ms que suficientes de RAM, contina siendo un recuro que siempre hay que vigilar y que optimizar al mximo. Adems, hay que entender que cada dato que es cargado en la RAM o procede del mismo proceso que lo genera o ha sido cargado desde el disco duro anteriormente, y teniendo en cuenta que el disco duro contina siendo a da de hoy el elemento ms lento del equipo, es algo a tener en cuenta. Los datos mostrados corresponden a la memoria Privada usada por el/los procesos, eso quiere decir que no es exactamente el 100% de la memoria RAM ocupada, ya que no se incluyen pequeos pedazos adicionales como por ejemplo el mapeo de archivos adicionales como puedan ser las fuentes, archivos de configuracin No obstante, esta Memoria Privada supone una precisin de ms del 95%, haciendo que sea ms que suficiente para nuestros propsitos:

Safari: Como ya se ha dicho, el proceso webkit2webprocess.exe produce una carga de la CPU de un 30% aproximadamente Opera: No logr estabilizar (dentro de lo normal) la RAM ocupada, provocando un crecimiento lineal en el consumo de esta mientras transcurra el tiempo. Sin duda alguna un leak de memoria ocasionado por alguna de las pestaas abiertas.

Reproduccin a 1080p Es evidente que la reproduccin de vdeo es crucial en los tiempos que corren en la web, un mundo que busca cada vez ms el mximo rendimiento con el mnimo consumo posible (lo que alarga las bateras de los dispositivos porttiles). La reproduccin de Vdeo contina a da de hoy siendo uno de los mayores comecome de bateras. De nuevo, en esta ocasin la comparativa es doble, ya que no solo compararemos la eficiencia en la reproduccin de un vdeo Full HD a travs de Flash, sino que haremos lo mismo a travs de WebM gracias a HTML5, as podremos comparar a grandes rasgos la eficiencia de un sistema o de otro. En la comparativa de hace seis meses los nicos navegadores con soporte WebM eran Chrome y Firefox, en cambio a da de hoy tanto Opera como Internet Explorer (por medio de un complemento) soportan tambin WebM, con lo que s me parece correcto comenzar a medir cada navegador frente a WebM, y como ya he dicho este ante Flash. El vdeo reproducido es el mismo que el de hace seis mese: We Are The World Haiti

Internet Explorer: Permite la reproduccin de WebM gracias a un complemento externo. Se pone por referencia, pero a efectos de conteo general se tratar como un no soportado Un error por mi parte en el cdigo de colores. Cada columna de cada navegador representa (en orden) lo que muestra la leyenda, aunque los colores para representar WebM sean los mismos que para Flash

SunSpider, V8 y Kraken Posiblemente los 3 benchmarks ms utilizados para medir el rendimiento de los motores JavaScript de los navegadores. Como ya he dicho en muchas ocasiones no soy fan de test sintticos, y mucho menos tests que han sido optimizados al mximo por todos los navegadores para obtener buenas puntuaciones. Quiero decir que TODOS los navegadores hacen algo as como trampas para aparentar ser veloces, cuando a lo mejor no lo son tantos. No quiere decir que sean totalmente intiles, ya que muchas optimizaciones son llevadas despus a los entornos reales, pero por regla general no son demasiado fiables. Esto lo veremos ms adelante cuando analicemos el rendimiento en Canvas, que a fin de cuenta son muy dependientes de JavaScript, y veremos como los resultados obtenidos aqu no siempre ejemplifican aplicaciones web con alta carga JavaScript:

Normal Mapped, Canvas Performance, VII y Asteroids HTML5 permite integrar dentro del navegador de forma simple contenidos complejos a travs de canvas. Bsicamente Canvas define un marco de ejecucin de cierto contenido (generado principalmente por JavaScript). Es por ello que en realidad podra verse Canvas como la aplicacin prctica del uso pesado de JavaScript. Esto ha permitido suprimir la necesidad de complementos para un gran sin fin de necesidades, con lo que tan solo con disponer de un navegador compatible podemos hacer correr la aplicacin sin importar nada ms. Normal Mapped es un test que aunque es claramente grfico posee una carga grfica mnima, siendo el mayor aporte JS, y por ello queda relegado a este grupo de test. Por otro lado, Canvas Performance, es un benchmark muy interesante de cara a que trata de medir el rendimiento no de JavaScript en realidad, sino del contenido ejecutado en Canvas de forma sinttica, al ms puro estilo de los test sintticos JavaScript. VII es una demo de un juego creado a modo de test para los navegadores que hace un uso bastante extenso no solo de JavaScript, en este caso de CSS, SVG y de la composicin de capas. Asteroids por otro lado es un test ya conocido, con fuerte dependencia JavaScript y grfica:

Opera:Graves problemas cuando VII superpone diferentes capas de texto, el framerate baja a la mitad de golpe

Tanque de peces (3.000 peces), Pecera (2.000 Peces) En esta entrega los peces vuelven al ataque, pero gracias a Opera ha sido necesario incrementar el nmero de Peces en ellos, ya que en ambos test Opera era capaz de llegar al tope de los 60 fps. Dos Test similares pero diferentes, orientados ambos al rendimiento grfico de Canvas puro y duro. Los dos fueron diseados para aprovecharse al mximo de la aceleracin hardware de contenido, y es por ello que Chrome y Safari fracasan estrepitosamente. Anteriormente vimos como Opera no dispona de esta cualidad, que ahora ha implementando con sus pros (gran rendimiento) y contras (uso extensivo de la GPU y el consiguiente consumo energtico), los cuales veremos en las conclusiones en detalle. Todos los test con fuerte contenido grfico acompaan igualmente la carga en la CPU y en la GPU, lo cual servir adems para comparar el consumo energtico de cada navegador

Safari: No posee Aceleracin por Hardware Chrome: Google tiene implementada a medio gas la aceleracin por Hardware, pero adems de ser muy inestable aun, es necesario activarla por medio de about:flags actualmente, con lo que en esta ocasin queda fuera.

Come-Cocos (Browse Hunt) Una vez ms, este test creado por Microsoft logra poner los pelos de punta al resto de los navegadores, siendo 6 meses despus imposible de acercarse a los 60 fps que logra Internet Explorer. Aun siendo un test fuertemente grfico, tanto Firefox como Opera estan lejos de alcanzarlo:

Letras (SpeedReading) Uno de los mejores test para comprender la importancia de la aceleracin grfica dentro de los navegadores. Pasamos de los 6 segundos en finalizar el test a ms de 2500 en el caso de Safari:

Psicodlico Otro test que se ha hecho muy extendido y famoso en toda la red por demostrar el potencial grfico actual de los navegadores. Existen varias versiones de este test, pero al final siempre es lo mismo: Una imagen que gira sobre si misma a la mxima velocidad posible:

Webvizbench Aunque no deja de ser un benchmark, es uno de los mejores ejemplos de canvas compuesto, con una alta carga JavaScript, grfica, CSS explota al mximo desde transiciones, composicin de capas, animaciones es de los test ms completos que veremos por aqui, y orientado siempre a aplicaciones prcticas que podran/pueden crearse y que antes eran totalmente impensables. Uno de mis test favoritos sin duda:

Tanque de Peces (50.000) y Sistema Solar, ambos para WebGL Aunque en la entrega anterior WebGL no lleg a puntuar realmente, en esta ocasin dado que Opera da soporte de forma oficial tambin, es coherente aadirlo. Aun se quedan fuera tanto Internet Explorer como Safari. Microsoft no est claro que vaya a implementarlo por ahora, no obstante para Safari es posible activarlo de forma experimental y tan solo en MAC OS. Ambos obtendrn por tanto un no soportado. Es interesante como los chicos de Mozilla tomaron el test original de Microsoft del tanque de peces (usado anteriormente con 3000 peces) y lo adaptaron a WebGL. Comprobamos como tenemos que elevar a la friolera de 50.000 peces para no alcanzar los 60 fps de tope. Si bajo la aceleracin por Hardware por contenido y capas 3.000 peces parecan ser el tope por ahora, el rendimiento por WebGL frente al test anterior es sorprendente:

Peacekeeper Test sinttico que mezcla varios elementos para medir el rendimiento de los navegadores. Personalmente me gustaba ms la versin anterior pero ya no es posible hacerla andar. Mezcla parte JS, trabajo con cadenas, grficos y sobre todo objetos DOM. Como ya dijimos tambin, ha sido un test muy criticado por explotar con fines mediticos la fortaleza y debilidades de los navegadores, un test muy parcial. Pero de nuevo, no deja de ser un buen indicador, muchas veces es necesario conocer los puntos fuertes y dbiles de cada navegador para poder mejorarlos. Lo nico que no queda claro del todo es si el echo de que el navegador pase o no pase ms test punta ms. Ms que nada porque el test en un momento dado intenta reproducir vdeo en diferentes codec por medio de html5, y si no lo logra no lo punta correctamente. Recordemos que el codec usado para el tag <video> de html5 no es una especificacin, que eso queda a discrecin del navegador. El test de niels pra HTML5 es mucho ms riguroso en este tipo de cuestiones, Peacekeeper no tendra incluir en sus test este apartado

Spinnig Balls Cualquier programa informtico generalmente requiere un buen gestor de memoria que est de forma asidua buscando y liberando cualquier trozo de RAM que ya no use. Esto es til por dos razones principalmente: Primero porque de lo contrario el consumo de RAM subira constantemente y terminara con consumir toda la existente, y segundo porque la ejecucin del programa sera cada vez ms lenta y los datos en RAM ms fraccionados. Esto como digo se evita reciclando la RAM cada cortos perodos de tiempo. Los navegadores pueden producir en cortos perodos de tiempo muchos objetos nuevos que se destruyen igualmente rpidos alguno de ellos, lo cual genera constantemente muchos trozos de RAM basura que es bueno ir liberando. La alternativa de no usar GC (Garbage Collection) no es viable. El problema de los recicladores es que dependiendo del sistema GC que estn usando pueden detener la ejecucin del proceso hasta que el reciclado se ha terminado. Esto en un navegador se traduce por ejemplo con una extraa pausa en un momento dado, un salto en u juego, un drop de FPS momentneo cuestiones que realmente no implican que el proceso se ejecute ms rpido o menos rpido, sino que se ejecute de forma fluida o no. Esto lo hemos visto en muchos test en los que algunos navegadores no es que obtengan bajos FPS, sino que aplicaciones que aun obteniendo altos FPS son totalmente imposibles de manejar dada las continuadas pausas. Este test mide este comportamiento. Genera muchos objetos constantemente y mide las pausas que se registran. Este test es muy muy sensible a cualquier otro proceso que se est ejecutando, as que ojo. Cada pausa que registra el programa la anota, y la mejor puntuacin es para aquel navegador que realiza menos pausas o pausas ms cortas. Es decir que un navegador que a lo mejor tienen 10 pausas de 5 ms y otro que posee 5 de 10 ms, el primero obtendr mejor resultado ya que la implicacin es menor y la ejecucin mucho ms fluida.

Internet Explorer 9: No es compatible con el test Firefox: El GC actual de Firefox no es todo lo estable que se podra esperar, aunque cuando funciona correctamente es el mejor de los navegadores.

Test de compatibilidad HTML5 de Niels A da de hoy pun buen navegador no solo es aquel que es el ms rpido, sino que tambin est en continuo desarrollo para adaptarse a los nuevos tiempos y a los nuevos estndares. El test de Niels es uno de los mejores identificativos para medir la compatibilidad con el futuro estandard HTML5. Repito, el test de Niels TAN SOLO mide especificaciones HTML5, no mide ningn otro estndar, y son muchos otros los que a da de hoy disponemos:

El test de Niels se basa actualmente sobre 500 puntos mximos.

Test de compatibilidad WebGL de Khronos Exactamente igual que testeamos poco a poco las especificaciones HTML5 que van formndose, hacemos lo mismo con las especificaciones de WebGL. WebGL es un estndar para permitir que el navegador pueda ejecutar grficos avanzados en l, es llevar la API OpenGL a los navegadores. Dos navegadores pueden ser compatibles con WebGL, pero si uno no es compatible en algunas cuestiones de WebGL el resultado puede ser simplemente que el contenido no se visualice o se visualice mal. Mientras buscaba algunos test WebGL interesantes, en muchos casos no todos los navegadores con soporte WebGL podran ejecutarlos correctamente

Internet Explorer y Safari: No son compatibles Chrome: Varios test de la suite producan un comportamiento totalmente anmalo de este, obligando a reiniciar Chrome. El resultado mostrado es eliminando los test que impedan su funcionamiento Firefox: Aunque pudo completar el test totalmente, uno de los test en particular (que tambin afectaba a Chrome) produca paralizaciones de todo el navegador en diferentes momentos. Al final no impidi en cambio terminar con todos los test sin producir un cierre forzado

IE Center Testing Microsoft posee desde hace ya tiempo un site con una tabla que muestra la compatibilidad de los diferentes navegadores frente a los nuevos estndares. Los test son los mismos solo que yo los aplico a mis versiones de los navegadores, mientras que Microsoft la aplica a su navegador en desarrollo y las versiones oficiales de la competencia (lo cual es injusto evidentemente). Tambin hay que entender que aunque la suite de test que expone Microsoft es bastante completa (siendo a mi gusto el test de compatibilidad mas completo que hay), es totalmente parcial y engaosa. Es decir, la suite de test creados por Microsoft para probar la compatibilidad de los navegadores se basa en exponer TODAS las compatibilidades que Microsoft sabe que Internet Explorer 10 ser compatible, con lo que cabe esperar que posiblemente Internet Explorer 10 cuando sea oficial obtenga un 100% en todos los test. En cambio, para muchas otras especificaciones y partes de especificaciones en las que Internet Explorer no es capaz de dar la talla, Microsoft simplemente no crea test para ellos. Es el caso de muchas especificaciones de HTML5 (que es mucho mejor identificativo el test de niels) o para WebGL. A esto habra que sumarle adems errores de los propios tests, es decir que Microsoft interpreta las especificaciones de un modo y la competencia de otro comportamiento que se ha visto en muchas ocasiones verificado. Todo esto se resume con que esta suite es crucial a da de hoy y un excelente trabajo por parte de Microsoft sin duda, pero que quizs tan solo cubre un 60% de un todo, siendo el 60% que cubre el que precisamente interesa a Microsoft por ser compatible con su navegador. Aun as el soporte para CSS, SVG y otras tecnologas es hasta bonito:

Los test estn actualizados con la ltima versin del IE Center de Microsoft, actualizada a 29/02/2012

Conclusiones Si valoramos cada navegador como se dijo al comienzo, los resultados seran por tanto los siguientes: Resultados Rendimiento JavaScript Canvas Grficos WebGL Otros Compatibilidad Estabilidad Total Rendimiento El rendimiento de un navegador no slo se resume en lo rpido que pueda ejecutar un cdigo en JavaScript o los fps que sea capaz de mostrar en cualquier aplicacin/juego. De echo, desde mi punto de vista posee un peso ms que importante a la hora de escoger uno u otro. Cuantas horas a la semana pasamos delante de un PC/dispositivo con el navegador abierto? Cada vez disponemos de dispositivos ms potentes, pero las pginas Web, las aplicaciones Web cada vez son ms complejas igualmente y requieren de esa potencia extra. Por tanto es de extrema importancia que el navegador no solo sea capaz de ejecutar una tarea lo ms rpida posible, sino que el propio navegador se comporte de forma gil y veloz en el sistema. Eso implica que tenga excelentes gestores de memorias propios, que pueda gestionar inteligentemente la carga de nuevos contenidos, reducir en la medida los accesos a disco, innovar en nuevos sistemas de almacenaje de datos para su rpido acceso y sinceramente esto es una tarea muy complicada. En cuanto a tiempos de inicio se refiere, sin duda alguna Chrome reina sobre la competencia siempre y cuando se estn abriendo al mismo tiempo mltiples pestaas. Este comportamiento evidencia la necesidad de que el navegadores sean poco a poco multiprocesados. Recordemos que aunque todos los navegadores a da de hoy sin multihilos, tan solo Internet Explorer y Chrome son multiprocesos. Esto les otorga entre otras cosas ser (al menos tericamente hablando) ms veloces y eficaces a la hora de manejar mltiples pestaas. El problema es que esto no es tan simple de realizar, sobre todo cuando el proyecto es de grandes proporciones. Eventualmente, Mozilla separar los procesos de las pestaas y llegar a ser una realidad el proyecto Electrolysis. Igualmente, antes o despus Opera y Safari tomarn caminos similares. El principal problema de abrir mltiples pestaas a la par es la sobrecarga en el navegador, independientemente de la velocidad con la que se cargue el navegador. En los navegadores no multiprocesados como Firefox, Opera o Safari la apertura mltiple de muchas pestaas podra provocar al usuario la sensacin de paralizacin/congelacin de este hasta que prcticamente todas las pestaas estuviesen cargadas, ya que desde el punto de vista del navegador tan solo estara llevando a cabo una misma tarea. Para Internet Explorer o Chrome este problema no lo tienen, cada pestaa tiene su propio espacio y sera el propio sistema operativo quien gestionara por medio de su planificador (Scheduler). Para tratar con ello, tanto Opera como Firefox usan por defecto la carga selectiva de pestaas, es decir, por defecto cuando se abren mltiples pestaas a la par tan solo se cargan aquella que est en primer plano. El efecto es inmediato, de poder tener el navegador paralizado durante mltiples segundos la navegacin es instantnea, y mientras se pueden ir cargando de fondo el resto de las pestaas. Por supuesto a la hora de medir los tiempos, este comportamiento se deshabilit para que todos los navegadores estuviesen en igualdad de condiciones. Firefox 14 x86 56 12 14 25 10 8 12 5 134 Chrome 19 48 12 17 14 8 9 11 5 115 IE 10/9 x86 34 7 16 24 0 2 6 3 90 Opera 12 19 9 6 22 6 7 10 2 74 Safari 5.1 35 5 7 7 0 4 3 1 58

Todo tiene pros y contras, y que una aplicacin sea multiprocesos implica inevitablemente otros efectos secundarios cuando no se cuidan demasiado, y que se evidencia en una sobrecarga adicional en la memoria RAM y en el tiempo necesario para finalizar por completo la aplicacin. De esta forma, efectivamente tanto Chrome como Internet Explorer son los que poseen un tiempo sensiblemente superior en cuanto a tiempo de cierre, siendo sus consumos de RAM significamente superiores que si los comparamos con el consumo de RAM de Firefox. Safari por su lado mostr un comportamiento ms intermedio y como sorpresa, Opera mostr un resultado terrible. En otro orden de cosas encontraramos sorpresivamente que Firefox es el mejor navegador a la hora de descargar una web no cacheada, y el segundo cuando s la tiene. Chrome le rozara los pies de cualquier modo siendo las diferencias mnimas, e Internet Explorer mostr un comportamiento bastante decente. Por ltimo, hay que destacar el rendimiento en la reproduccin de contenido en 1080p de los navegadores y de la mitificacin que otrora intent Steve Jobs en que Flash es la lacra para el rendimiento, la seguridad y el pasado. Para empezar Flash es mucho ms que un simple reproductor de vdeos, y para terminar es evidente que a da de hoy es de lejos la mejor opcin a la hora de reproducir cualquier contenido en HD. Si miramos los recursos usados por el equipo en la reproduccin de contenidos en Flash y contenidos en WebM, vemos que las diferencias son sorprendentes. Evidentemente estas grandes diferencias son principalmente por la aceleracin por Hardware con la que cuenta Flash y no WebM, pero es una cuestin de nmeros. Mientras que reproducir en el equipo de pruebas un vdeo 1080p en flash consuma en el peor de los navegadores un 13% de la CPU (menos de un 1% en los mejores casos) y un 8% la GPU (en el peor de los casos), WebM lleg a a necesitar en el mejor de los escenarios un 8% CPU/18% GPU, elevando la carga de la CPU en el caso de Opera hasta el 21% (y un 16% la GPU). Sea como sea a da de hoy la mejor opcin para la reproduccin de vdeos es Flash gracias al gran soporte que esta tecnologa posee en cuanto a aceleracin de hardware se refiere. Por supuesto, se podra usar otros codec como H264 para la reproduccin de vdeo por HTML5, y este poseera mejor soporte para aceleracin por hardware que WebM (y mayor calidad), pero h264 est fuertemente patentado. Aun as, el rendimiento sera inferior al mostrado por Flash. No estoy diciendo que el futuro del vdeo sea Flash, el que los navegadores posean capacidad para reproducir vdeo y audio a travs de ellos mismos es algo importantsimo y una herramienta muy potente. Pero todo requiere tiempo a veces mucho tiempo. El proyecto WebM no ser posible mientras que el soporte para este sea el que estamos viendo. Por otro lado, la imposicin de h264 como codec de vdeo junto a AAC como codec de audio tampoco parece ser una respuesta a corto plazo, aunque personalmente deseara que esta ltima opcin fuese la que se impusiese con el tiempo y que la MPEG LA abriese el codec para su uso en la Web. Seamos sensatos, soy defensor de los formatos libres y abiertos, pero el codec de vdeo VP8 (el usado en WebM) no es rival de h264, y adems este ltimo posee mucho mejor soporte Hardware. Veremos en el futuro como termina la cosa mientras tanto podemos ms que conformarnos y ser felices por el extraordinario rendimiento de Flash. JavaScript Los test sintticos JavaScript que ya conocen todos siguen siendo punto de referencia para muchos. Como ya dije me parece que son test tramposos que tan solo buscan la buena prensa de los medios. Seamos sensatos, cualquiera que eche un vistazo a los nmeros y luego a los entornos reales ve que existen diferencias cuanto menos graciosas. As por ejemplo supuestamente Internet Explorer mantiene el liderazgo en SunSpider, y en cambio posee la peor puntuacin en los otros dos benchmarks!! cuando adems se supone que Kraken es un derivado de SunSpider. O al revs, mientras que Chrome obtiene una puntuacin totalmente disparatada en su propio test V8 (el de Google), obtiene la penltima posicin en SunSpider. No hay que ser un genio para darse cuenta que todos los navegadores (sin excepcin) optimizan partes de su cdigo a sabiendas de estos test, con la inclusin de Fast Path y otros. Por supuesto que muchas de estas optimizaciones pueden ser llevadas a entornos reales, pero es evidente que

la mayora no, la mayora tan solo tienen utilidad en estos test, y por tanto su fiabilidad es ms que dudosa. De nuevo no quiere decir que sean totalmente intiles este tipo de test, y se aprende mucho de los motores JS de cada navegador, se pueden detectar puntos calientes en ellos, mejorar eso por supuesto!! pero estos test tienen sentido realmente cuando se comparan no navegadores Vs navegadores de la competencia, sino en todo caso las mejoras existentes en JavaScript entre las diversas versiones del mismo navegador. Respecto a la comparativa anterior, los resultados para SunSpider y Kraken son muy similares, pequeos cambios. En cuanto a V8 si hay cambios ms significativos, pero hay que tener en cuenta que V8 fue actualizado a su versin 7, mientras que el test anterior era la V6. Canvas He querido separar este apartado del de JavaScript, aunque en realidad estn muy relacionados uno con otros. En la comparativa anterior se usaban dos juegos de ejemplo que en esta ocasin han sido sustituidos por otros dos test. Canvas es una de la infinidad de especificaciones que poseer el estndar HTML5 y que se estn empezando a usar muy poco a poco. Como ya he dicho, Canvas define algo as como un espacio de trabajo en el que se ejecutar un cdigo principalmente en JavaScript, CSS con lo que es posible la creacin de aplicaciones Web complejas, y por supuesto juegos como Angry Bird y tantos otros. El rendimiento de estos marcos est ligado ntimamente con JavaScript, pero como veremos en el apartado grfico tambin de otros muchos factores. Es complicado medir este apartado dado que se puede crear un Canvas con el contenido ms vario pinto posible, y es ms que posible que en algunas aplicaciones domine un navegador y en otras domine otro. No obstante, cuando valoramos de forma general todos ellos (y siempre que no hagamos un uso relativamente extensivo grfico), Chrome e Internet Explorer son los lderes, estando Firefox relegado a una tercera posicin. Ms sorprendente es el caso de Opera, que aun cuando exhibe un buen comportamiento JavaScript (y como veremos ms adelante grfico) obtuvo la peor calificacin. Esto nos hace ver que un entorno real como una aplicacin o un juego HTML5 no es un test sinttico, y que un buen competidor como Opera que sobrepasaba tanto a Internet Explorer como a Safari en JavaScript y a Chrome y Safari en el apartado grfico, fracasa estrepitosamente aqu. Safari por su parte logra a duras penas quedar por encima de Opera. Grficos Hay que tener en cuenta antes de empezar, que aunque esta seccin se llame grficos no tiene nada que ver con la elavoracin de grficos complejos 3D ni nada por el estilo, sino test que pueden sacar un provecho enorme de la aceleracin hardware. As por ejemplo tenemos el test de SpeedReading que tan solo se vasa en un marcador veloz de letras, o psicodlico, que no deja de ser una imagen girando sobre s misma. En la comparativa anterior, el soporte de Chrome para aceleracin de vdeo estaba habilitado por defecto, y ya antes era inestable. En esta ocasin vemos que estando deshabilitado (que es como est por defecto) Chrome cae a posiciones inferiores. Aun as, aun de estar habilitado habra obtenido la misma puntuacin casi con toda seguridad, ya que en esta ocasin ha sido Opera quien por fin ha activado de forma oficial el soporte hardware de este. El otro gran avance que hay que citar es sin duda alguna los Drivers del sistema de nVidia y las actualizaciones de Microsoft de DirectWrite y Direct2D, los cuales han hecho que de forma generalizada se haya experimentado un incremento sustancial en el rendimiento. Ha sido muy interesante comprobar el rendimiento de Opera en esta comparativa grficamente hablando. Dado el comportamiento que mostr tanto en el test del Tanque de 3000 peces como en la pecera con 1500 peces, fue necesario incrementar el nmero de peces de estos para que Opera

no fuese capaz de llegar a los 60 fps. Aunque al final terminase en la tercera posicin, en realidad en los test en los que estuvo por debajo de Firefox o Internet Explorer no fue por demasiado. Opera sin duda alguna ha hecho un gran trabajo con el soporte hardware de su navegador, pero su visin fue totalmente diferente a la de Internet Explorer o Firefox. Tanto Internet Explorer como Firefox usan la API DirectWrite y Direct2D para la aceleracin hardware de contenido y de capas, mientras que Opera usa OpenGL para ambos. Como ya hemos dicho todo tiene sus pros y sus contras, y esto lo vemos muy bien reflejado adems en los consumos de CPU/GPU de dichos test. El adaptador de vdeo no se comporta igual si est ejecutando cdigo en DirectWrite que cdigo en OpenGL. Evidentemente (y como veremos ms adelante en WebGL) OpenGL est clasificado como una API completa de alto nivel, como pueda ser Direct3D, mientras que DirectWrite y Direct2D es una API 2D tan solo. orientada al bajo consumo y eficiencia. Esto tiene una repercusin directa en el adaptador de vdeo, y es que este junto a los Drivers otorgan siempre ms recursos a contenido que supuestamente es 3D. Es decir, la API DirectWrite/Direct2D est diseada precisamente para sobrecargar en lo menos posible al adaptador de vdeo, ya que se supone que el contenido que se va a visualizar o tratar es en 2D, y por tanto no requiere de unos recursos demasiado altos!! esta asuncin es totalmente sensata y es lgica: Si se requiere de unos recursos muy elevados ser porque se estar manejando grficos complejos en 3D, de lo contrario podemos trabajar a medio gas porque el contenido 2D es infinitamente menos exigente. Y si requerimos contenido 3D complejo para ello tenemos OpenGL/Direct3D Todo ello se resume en que Opera, que usa OpenGL como Backend, obtenga resultados superiores en algunos test, a expensas siempre de un consumo bastante superior tanto de CPU como especialmente de GPU. As en el test del tanque de 3000 peces la GPU eleva su uso al 61% en Opera, mientras que Firefox con la segunda mejor marca alcanza el 38%. Mucho ms exagerado lo vemos en el test de la Pecera con 2000 peces!! Opera logra la friolera de 52 fps, a expensas de requerir un 20% de CPU y poner a trabajar el adaptador de vdeo al mximo, a un 97%!! Firefox de nuevo con la segunda mejor marca logra los 31 fps, pero usando tan solo un 41% de la GPU. Tanto Internet Explorer como Firefox usan el mismo Backend usado de forma muy similar, aunque Firefox lo usa por regla general algo mejor (no demasiado). Chrome por su parte con el soporte experimental hace algo similar que Opera (y todos esperamos ver dentro de 6 meses que ya se encuentra activado). Safari por contrapartida se desconoce si en algn momento incorporar soporte hardware en su navegador cosa dudosa teniendo en cuenta la mala imagen que podra dar en la prensa que el navegador Safari tuviese un rendimiento superior en Windows que en MAC OS. Por ltimo decir que la ventaja de que Opera use OpenGL de backend, es que en teora debera de ser totalmente compatible con cualquier OS compatible con OpenGL (Linux, Windows XP, MAC OS), mientras que el camino tomado ahora mismo por Firefox e Internet Explorer requieren de DirectX 9+ (recomendando DirectX 10) y Windows Vista/7. El futuro parece ms o menos evidente. Firefox no solo tiene creado el backend de Direct2D/DirectDraw, sino que posee tambin un Backend OpenGL para Linux/MAC OS. As mismo con el tiempo Mozilla abandonar Direc2D/DirecDraw e implementar un Backend en Windows basado en Direc3D, con lo que se obtendr no solo un rendimiento superior, sino que ser ms compatible dentro de los diferentes adaptadores de vdeo y versiones de Windows. WebGL Dado que Opera se ha sumado por fin al carro de WebGL y que Safari posee en MAC OS soporte experimental para ello, me parece sensato comenzar a puntuar tambin WebGL. Aunque en el apartado anterior se ha hablado de forma extensa sobre la aceleracin de hardware y de contenido grfico, hay que saber diferenciar totalmente WebGL de ello. En el apartado anterior se mostraba la capacidad de los navegadores para acelerar gran parte del contenido en muchas

aplicaciones Web y juegos a travs de diferentes APIs, como por ejemplo una imagen girando velozmente sobre ella misma, transiciones rpidas aplicaciones o juegos que podemos encontrar cada vez ms en cualquier lado. No hablamos de apartado grfico anteriormente porque manejsemos grficos complejos, sino para especificar que son test que hacen uso extensivo del adaptador de vdeo. Pero WebGL es totalmente diferente, con WebGL s asumimos que vamos a trabajar (o al menos que podemos trabajar) con grficos complejos. WebGL se crea como iniciativa de poder renderizar en Canvas contenido 2D/3D complejo a travs de OpenGL. De prosperar y ser realmente eficiente (que es discutible dado la gran sobrecarga de JavaScript) podramos encontrar a medio plazo juegos con bastante potencial grfico ejecutado directamente en nuestro navegador. Como lado negativo se encuentra en que WebGL se basa evidentemente en JavaScript, y la sobrecarga de este lenguajes es muy alta. No podremos por tanto comparar jams una aplicacin/juego programada en C++ y OpenGL que programada en JavaScript y WebGL. Esta tecnologa jams ser un sustituto ojo, WebGL no llega para desbancar nada, sino para aadir algo que antes era imposible. Gracias a WebGL vimos el increble trabajo por parte de Google y Zigote con Body Browser, que es una aplicacin totalmente prctica, til y funcional. Realizar algo as sin WebGL sera imposible a da de hoy, se debera de instalar algn complemento en el navegador. No obstante aqu encontramos un escenario muy interesante si comparamos los datos obtenidos. Opera que obtena unos resultados increbles en algunos test anteriores, cuando se trata de usar WebGL no es capaz de alcanzar ni a Firefox ni a Chrome. Esto parece tener clara la explicacin: Opera usa OpenGL como backend tambin en WebGL, pero tanto Firefox como Chrome usan ANGLE. ANGLE es un proyecto impulsado/creado/mantenido por Chrome que bsicamente es una capa de software encima de DirectX 9.0c que traduce OpenGL 2.0. Dicho de otro modo, cuando Firefox o Chrome usan ANGLE todo el cdigo ejecutado en OpenGL a travs de WebGL es transformado a llamadas en Directx 9.0c. Soy defensor de OpenGL, sobre todo por su facilidad a la hora de programar con l, pero la API DirectX es sencillamente mejor y ms rpida. Incluso con ANGLE que tiene que hacer de traductor, el rendimiento a travs de este es superior. En Firefox existe la posibilidad no obstante de usar el soporte nativo OpenGL, pero cuando se opta por este modo, el rendimiento es algo inferior. Aun as, no se usa ANGLE por su rendimiento, ya que al final cuando se optimizase WebGL y el soporte nativo es de esperar que el rendimiento de este fuese superior. Se usa ANGLE porque el soporte para OpenGL vara mucho entre diferentes fabricantes. As por ejemplo, nVidia ofrece el mejor soporte para OpenGL disponible, siendo compatible desde su serie GX 400 con OpenGL 4.2.0. Pero este escenario es totalmente desastroso cuando miramos adaptadores de vdeo Intel, que poseen un soporte para OpenGL mucho ms pobre. ANGLE es una solucin muy eficaz ya que asegura que sea cual sea el fabricante o el adaptador de vdeo que se tenga instalado, mientras que este sea compatible con DirectX 9.0c podr ejecutar a la perfeccin contenido WebGL, y en muchos casos como vemos con un rendimiento superior. Por suerte, Intel est empezando a aplicarse el cuento y entregando controladores decentes para OpenGLen la actualidad, ahora mismo creo que ya soporta en Windows 7 hasta OpenGL 3.0. Recordar que estamos hablando en todo momento de Windows, en Linux o MAC OS no es posible bajo ningn pretexto el uso de la API DirectX, y OpenGL forma parte intrnseca de l. En el caso de Linux es posible usar OpenGL 4.2.0 (la especificacin ms alta actualmente) siempre y cuando el adaptador de vdeo lo permita, en el caso de MAC OS, este tan solo soporta OpenGL 2.0 y con algunas carencias. El test que ms nos llama la atencin es inmediatamente el tanque de 50.000 peces. Recordemos que realizamos el mismo test bajo HTML5 con 3000 peces, obteniendo Opera en el mejor de los casos cerca de 50 fps. En este caso tenemos el mismo tanque pero usando WebGL, y vemos que es necesario elevar a 50.000 peces para que Firefox no alcance los 60fps. Cualquiera podra decir que si disponemos de WebGL que sentido tiene el test anterior en el que el navegador no poda con 3000. Y volvemos a lo mismo, las peras se parecen a las manzanas en que las dos son frutas, pero

nada ms. Es ms que evidente que si cualquier test html5 se puede pasar a WebGL (con lo que debe de tener un fuerte componente grfico evidentemente) su rendimiento ser infinitamente superior. En parte es la misma explicacin por el cual Opera obtena tan buenos resultados anteriormente. En este caso Firefox y Chrome no hacen uso de Direc2D o DirectDraw, sino de Direct3D (recordemos que usa ANGLE). Aun cuando usasen OpenGL puro y duro, el rendimiento sera muy superior. Pero es lgico, son APIs totalmente diferentes orientadas a funciones totalmente diferentes. Direct2D/DirectDraw no estn pensadas para proporcionar un rendimiento de vrtigo exprimiendo la GPU. Estndares Actualmente parece que existen dos grandes frentes abiertos a la prensa. Si uno es el rendimiento en los test sintticos, el otro es el proclamar que su navegador es compatible con HTML5, o mejor dicho, pelearse por cual es ms compatible en este campo. Seores, HTML5 es muy importante en el futuro, pero de nuevo no es el nico estndar emergente estos das. Es ms, actualmente es infinitamente ms usado CSS 3.0 como estndar emergente que HTML5. Tan importante es lo uno como lo otro. De nuevo y como era de esperar, todos los navegadores han mejorado su compatibilidad con los estndares existentes, sobre todo en HTML5 como podemos ver en el test de Niels (no podemos compararlo con la comparativa anterior dado que el test de Niels est en constante cambio). Aun as, y pese que Microsoft asegura que en sus test Internet Explorer 10 es el ms compatible de cara a HTML5, es Chrome quien posee cierto liderazgo aqu. El problema de Chrome es que aunque es cierto que es ms compatible a efectos generales en HTML5 que el resto de los navegadores, no a efectos concretos. Es decir, Chrome implementa la mayora de funciones de HTML, pero de una forma bsica, y lo mismo le pasa con CSS y otras tecnologas. Opera en contrapartida se centra en menos variedad pero de una forma mucho ms profunda, intentando cumplri a rajatabla todas las especificaciones de cada seccin. Esto hace que en test generalistas como el de Niels Chrome obtenga muy buenos resultados y en otros ms especficos como la suite de IE obtenga resultados algo inferiores. Sobre la Suite de Microsoft poco podemos aadir, evidentemente es una suite totalmente engaosa para mostrar que Internet Explorer es el navegador ms compatible, y en cambio en el test de niels el resultado es deprimente. No obstante Microsoft sigue avanzando a pasos agigantados en cuanto a compatibilidad se refiere, su eterna lacra desde luego aun a da de hoy muchso webmaster necesitamos crear cdigo redundante y hacer trampas para que las web se visualicen correctamente en Internet Explorer, precisamente por no ceirse a los estndares. Sobre WebGL, tanto Firefox como Chrome continan aumentando su compatibilidad, aunque desde que Khronos publicase la nueva versin de sus test, ambos han tenido algunos problemas con algunos de ellos. Opera se ha subido al carro y no ha empezado con mal pie desde luego, es agradable ver como poco a poco los navegadores van sumndose a los estndares y apoyando lo que sin duda alguna podr ser de muchsima utilidad en el futuro. Y es evidente, hasta que no hay en el mercado un buen soporte los programadores y diseadores no pueden pillarse los dedos creando maravillas en la web que tan solo podrn ver dos o tres personas porque sus navegadores no son compatibles. Las cosas tienen que llegar poco a poco por las dos partes.. Aun se desconoce de forma clara si Microsoft implementar WebGL, parece ms o menos claro que antes o despus lo implementar, pero cada da que pasa se duda ms de que Internet Explorer 10 salga a la luz con soporte para ello. Microsoft ya dijo hace tiempo que su postura era dudosa dado a los posibles problemas de seguridad que podran derivar de WebGL, en cambio como hemos visto en Firefox o Chrome ambos fueron actualizados con las ltimas especificaciones para evitar este tipo de problemas y hasta la fecha no se ha detectado ningn fallo de seguridad producido por ello. Sera bueno ver que al final Internet Explorer 10 viese la luz con WebGL, y de echo estoy totalmente seguro que los chicos de Microsoft disponen en sus laboratorio versiones de Internet Explorer 10 con soporte para WebGL. Apple por su parte mantiene la misma poltica, las ltimas builds de WebKit poseen soporte, pero experimenta, deshabilitado por defecto y tan solo compatible con MAC OS.

Compilaciones x64 Sobre Internet Explorer 10 no podemos decir nada ya que aun no est disponible ninguna versin para Windows 7 nativa en 64 bits, aunque es evidente que cuando Internet Explorer 10 salga a la luz estar disponible tanto para Windows 7 como para Windows 8, tanto en 32 como en 64 bits. Esperemos que Microsoft por fin pueda habilitar sus mejoras en su motor JS en la versin de 64 bits, que como hemos visto siempre en Internet Explorer 9, est muy por atrs del resto. Firefox contina ofreciendo versiones diarias de 64 bits con un rendimiento muy similar a las versionese de 32 bits, manteniendo la estabilidad. De echo si miramos todos los test realizados, la versin de 32bits y la de 64 bits de Firefox estn casi siempre cara a cara. Aun as la versin de 64 bits no es oficial aun, y no parece que lo vaya a ser a corto plazo. Esto no quiere decir que no sea una versin totalmente funcional, en la que muchas veces su rendimiento es superior a las versiones de 32 bits, y ms seguras. Opera irrumpe con su versin de 64 bits. En el caso de Opera no son tan estables como las versiones de 64 bits de Firefox y estn menos optimizadas, pero parten desde una buena posicin. Sin duda alguna Opera ha dado un gran salto en esta ocasin en muchos aspectos, desde la salida de su versin de 64 bits, soporte para aceleracin hardware, soporte para WebGL no est mal en estos 6 meses desde luego, y aunque no es capaz de alcanzar a Chrome, Firefox o Internet Explorer, sin duda alguna estn haciendo un gran trabajo. Sobre Chrome y Safari por otro lado no hay indicio alguno de que una versin de 64 bits pueda ver la luz a corto plazo habr que esperar. Es de suponer que eventualmente Chrome sacar una, pero

Consumo energtico Como puede influir un navegador en el consumo energtico de un dispositivo? Pues es fcil, dependiendo en gran medida delos recursos que tenga que hacer uso de l. Para ello tan solo tenemos q observar la carga en la CPU/GPU del sistema para hacernos una idea. Cuanto menor sea la carga en ambos menor es el consumo, es evidente, pero no est tan claro cuando tenemos que pensar si es la GPU o la CPU quien prima sobre el consumo. Es decir, es mejor tener un consumo de un 10% CPU y 2% GPU o un 2 CPU y 7% GPU. Sera muy complicado llegar a una decisin unnime sin acudir a un tester de potencia y medirlo directamente, pero si ms o menos imaginarlo. Mirando las grficas, parece claro que el navegador ms eficiente energticamente hablando dependera dependiendo del contenido. En un escenario normal, el mejor resultado sera para Internet Explorer o Firefox, en cambio cuando se entrase en test ms complejos el ganador sera Safari (por la sencilla razn de que no usara la GPU y que no sera capaz de ejecutar correctamente el test). Opera en cambio obtendra el peor consumo de forma general, aunque puede obtener unos resultados increbles, elevar al 97% el uso de la GPU en el test de la pecera es demasiado.