Índice

  • Navegadores
  • Condiciones de las pruebas
  • Benchmarks (Nuevo: Inicio en caliente, Tiempo de cierre, Consumo, Caché…)
  • Conclusiones

 

Versiones de los navegadores

 

Navegadores:

 

Continuando con la tónica de las otras dos comparativas, y teniendo en cuenta que durante estos 6 meses ningún fabricante ha modificado de forma sustancial sus ciclos de actualizaciones, hoy volvemos de nuevo a la mesa de pruebas para enfrentar de nuevo a los navegadores que aun están por llegar. En alguna ocasión me han preguntado el motivo por el cual suelo hacer comparativas de navegadores que aun se encuentran en fase de desarrollo en vez de hacer comparaciones de las versiones oficiales. Esto lo he explicado en alguna otra ocasión, y son varias las razones:

a) Debido a los ciclos rápidos de Chrome y de Firefox, estos siempre tendrían grandes ventajas sobre Opera, IE o Safari, ya que estos últimos tan solo lanzan versiones oficiales cada bastante más tiempo. Comparar las últimas builds de cada navegador nos permite ser más imparciales (exceptuando Internet Explorer, ya que Microsoft no da acceso a las nightly Builds.

b) Los amantes del software (geeks y nerds entre otros) siempre deseamos probar y tener a mano lo último que se está cociendo, cambios que verán la luz de forma oficial para todo el público dentro de quizás unas semanas, unos meses o incluso un año.

Tanto para Firefox como para Safari se han tomado sus respectivas versiones nightly, ambos publican versiones nightly diadiamente. Para Chrome se ha tomado Chrome Canary, que aunque no se actualizan todos todos los días, sí prácticamente todos. Opera no publica versiones nightly tampoco, pero su versión de Opera en desarrollo es actualizado cada muy pocos días.

Internet Explorer no obstante es el único que se queda un poco atrás, ya que no podemos obtener versiones diarias ni muy actualizadas del desarrollo de Internet Explorer 10, y nos tenemos que conformar con la última versión de IE 10 que Microsoft sacó para Windows 7. Hay que tener en cuenta que esta versión de IE 10 no es un navegador completo, y por tanto los resultados obtenidos por él son cuanto menos discutibles. Esto hace además que no sea  posible realizar algunos test sobre él, por lo que se ha usado junto a él Internet Explorer 9. Cuando IE 10 no pueda ser usado en las pruebas, será usado IE9 y así quedará indicado.

Como en otras ocasiones, las versiones de 64 bits NO CONTARÁN en el tanteo final en modo alguno, y tan solo tendrán un valor presencial para comparar, puesto que ni todos los navegadores poseen versiones de 64 bits, ni ningún navegador posee una versión de 64 bits que real0mente funcione bien. No obstante, tenemos que añadir en esta ocasión Opera a los navegadores de 64 bits, siendo tan solo Safari y chrome los que por ahora no han abrazado esta arquitectura.

 Por cuarta vez, , la versión de Safari instalada está exenta de QuickTime como ya se ha explicado otras veces. En esta ocasión Apple no obliga instalarlo (un buen paso por su parte). Las razones son las de siempre, QT actúa de plugin para Safari para dotarlo de mayores prestaciones, y la idea es probar los navegadores no sus complementos. Sería igualmente injusto si no, instalar extensiones a otros navegadores para obtener mejores resultados.

Fue necesario deshabilitar DEP (en Windows) para los 3 procesos implicados en Safari, de lo contrario el navegador era bloqueado por este por motivos de seguridad.

 

Condiciones de las Pruebas

 

Sistema:

  • OS: Windows 7 Ultimate x64 SP1
  • CPU: Intel Core i7 920
  • RAM: 12GB DDR3 Triple canal
  • Video: nVidia GTX460 (Driver 296.10)
  • Resolución: 1920 x 1080 (navegador siempre maximizado)
  • Flash Player: 11,2,300,130 y 11,2,202,197

 

 Todos los navegadores son instalados de forma limpia en el mismo equipo, usando perfiles nuevos para todos ellos. El único complemento de partida que se instaló en todos los navegadores fue Adobe Flash Player, y en uno de los test para Firefox se instaló Firebug (para medir con precisión tiempos de carga, el resto usaron sus herramientas nativas).

Cada prueba en esta ocasión se ha ejecutado 5 veces en cada navegador, despreciando de ellos el mejor y el peor ciclo y haciendo media de los otros 3 resultantes. Esto se ha convertido en algo esencial debido a que muchos de los test son muy sensibles a cualquier cambio del equipo, desde un lectura en el disco duro o a algún proceso en segundo plano que pudiese interferir. Suprimiendo la mejor y la peor vuelta, se intenta evitar en lo posible estas deficiencias, sobre todo como digo en los test más sensibles.

Cada prueba puntuará de 1 a 5 (1 el peor resultado, 5 el mejor), reservando el cero para aquellas pruebas en las que el navegador no pueda realizarlas por deficiencias de este o simplemente produzca un fallo del navegador y sea incapaz de terminar la prueba. En caso de que dos navegadores obtengan el mismo resultado, a los dos se le asignará la misma puntuación, dejando la puntuación restante simplemente sin asignar. Como última prueba se hará simplemente una pequeña tabla a modo de “prueba de estabilidad” con los problemas experimentados con los navegadores a lo largo de las pruebas, y se puntuará cada navegador en función a esa estabilidad.

 

 Benchmarks

He reestructurado un poco mejor todos los test, se han modificado, añadido y eliminado otros. Hay que tener en cuenta que incluso muchos de los test que repiten, no pueden compararse con otras comparativas ni siquiera para ver las mejoras de una versión a otra, dado que los propios test sufren modificaciones por sus creadores, las web que se cargan cambian… etc etc etc.

Para ampliar cualquier imagen hacer clic en cualquiera de ellas.

Las Webs usadas para el consumo de RAM , así como los tiempos de inicio en frío/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 País”, la NASA, DevianArt, Play Store, Wikipedia (https://en.wikipedia.org/wiki/History_of_the_web_browser). Para los test de 20 pestañas, simplemente se han duplicado las 10 anteriores.

Test:

  • Rendimiento
    • Tiempo de Inicio en frío (1, 10 y 20 pestañas) – Mejorado
    • Tiempo de Inicio en caliente (1, 10 y 20 pestañas – Nuevo
    • Tiempo de Cierre (20 pestañas) – Nuevo
    • Velocidad de carga de Webs con/sin Caché – Nuevo
    • RAM (10 y 20 páginas)
    • CPU/GPU reproduciendo contenido 1080p (Flash y WebM) – Mejorado

 

 

 

 

 

 

 

 

Tiempo de Inicio en Frío y en Caliente

Comenzamos con los tiempos de inicio del navegador para 1, 10 y 20 pestañas, siempre a caché vacío. No se trata de medir la velocidad de carga de las páginas (que se verá más adelante), sino el tiempo de arranque y carga del navegador ante los 3 supuestos anteriores. Inicio en fío 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 sesión de forma automática (de 1, 10 o 20 pestañas). 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 pestañas han terminado de cargarse (que no quiere decir que todo el contenido en ellas se haya descargado):

 [singlepic id=7 w=350 h=229 float=left][singlepic id=3 w=350 h=229 float=center]

  • Opera: Falló en la carga de algunas pestañas, 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 ocasión se ha medido también el tiempo de respuesta del navegador a cerrar. En teoría podríamos pensar que estos tiempos son prácticamente inmediatos, pero no lo son. En muchas ocasiones el navegador se mantiene como proceso de fondo durante un largo período de tiempo incluso, lo cual evidentemente no es deseable. Los tiempos medidos son con 20 pestañas cargadas en los navegadores, contabilizando desde el momento en el que se envía la señal 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:

[singlepic id=5 w=700 h=458 float=center]

 

Velocidad de Carga de la Web con y sin caché

 Este test posee un doble propósito. 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 páginas 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 páginas con el contenido cacheado sea mucho menor. Cada Web fue abierta de forma aislada y se sumaron los tiempos de todas ellas:

[singlepic id=12 w=700 h=458 float=center]

  • 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 día de hoy la gran mayoría de los sistemas actuales cuentan con cantidades más que suficientes de RAM, continúa siendo un recuro que siempre hay que vigilar y que optimizar al máximo. Además, 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 continúa siendo a día de hoy el elemento más 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 pequeños “pedazos” adicionales como por ejemplo el mapeo de archivos adicionales como puedan ser las fuentes, archivos de configuración… No obstante, esta “Memoria Privada” supone una precisión de más del 95%, haciendo que sea más que suficiente para nuestros propósitos:

[singlepic id=16 w=700 h=458 float=center]

  • 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 transcurría el tiempo. Sin duda alguna un leak de memoria ocasionado por alguna de las pestañas abiertas.

 

Reproducción a 1080p

Es evidente que la reproducción de vídeo es crucial en los tiempos que corren en la web, un mundo que busca cada vez más el máximo rendimiento con el mínimo consumo posible (lo que alarga las baterías de los dispositivos portátiles). La reproducción de Vídeo continúa a día de hoy siendo uno de los mayores “comecome” de baterías. De nuevo, en esta ocasión la comparativa es doble, ya que no solo compararemos la eficiencia en la reproducción de un vídeo Full HD a través de Flash, sino que haremos lo mismo a través 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 día de hoy tanto Opera como Internet Explorer (por medio de un complemento) soportan también 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 vídeo reproducido es el mismo que el de hace seis mese: “We Are The World – Haiti”

[singlepic id=24 w=700 h=458 float=center]

  • Internet Explorer: Permite la reproducción 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 código 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 más utilizados para medir el rendimiento de los motores JavaScript de los navegadores. Como ya he dicho en muchas ocasiones no soy fan de test sintéticos, y mucho menos tests que han sido optimizados al máximo 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 inútiles, ya que muchas optimizaciones son llevadas después a los entornos reales, pero por regla general no son demasiado fiables. Esto lo veremos más 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:

[singlepic id=20 w=359 h=235 float=left][singlepic id=23 w=359 h=235 float=center]

[singlepic id=9 w=359 h=235 float=center]

 

 Normal Mapped, Canvas Performance, VII y Asteroids

HTML5 permite integrar dentro del navegador de forma simple contenidos complejos a través de canvas. Básicamente Canvas define un marco de ejecución de cierto contenido (generado principalmente por JavaScript). Es por ello que en realidad podría verse Canvas como la aplicación práctica 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 aplicación sin importar nada más.

Normal Mapped es un test que aunque es claramente gráfico posee una carga gráfica mínima, 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 sintética, al más puro estilo de los test sintéticos 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 composición de capas. Asteroids por otro lado es un test ya conocido, con fuerte dependencia JavaScript y gráfica:

[singlepic id=11 w=359 h=235 float=left][singlepic id=4 w=359 h=235 float=center]

[singlepic id=25 w=359 h=235 float=left][singlepic id=2 w=359 h=235 float=center]

  • 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 número 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 gráfico de Canvas puro y duro. Los dos fueron diseñados para aprovecharse al máximo de la aceleración hardware de contenido, y es por ello que Chrome y Safari fracasan estrepitosamente. Anteriormente vimos como Opera no disponía de esta cualidad, que ahora ha implementando con sus pros (gran rendimiento) y contras (uso extensivo de la GPU y el consiguiente consumo energético), los cuales veremos en las conclusiones en detalle.

Todos los test con fuerte contenido gráfico acompañan igualmente la carga en la CPU y en la GPU, lo cual servirá además para comparar el consumo energético de cada navegador

[singlepic id=21 w=359 h=235 float=left][singlepic id=27 w=359 h=235 float=center]

  • Safari: No posee Aceleración por Hardware
  • Chrome: Google tiene implementada a medio gas la aceleración por Hardware, pero además de ser muy inestable aun, es necesario activarla por medio de about:flags actualmente, con lo que en esta ocasión queda fuera.

 

“Come-Cocos” (Browse Hunt)

Una vez más, este test creado por Microsoft logra poner los pelos de punta al resto de los navegadores, siendo 6 meses después imposible de acercarse a los 60 fps que logra Internet Explorer. Aun siendo un test fuertemente gráfico, tanto Firefox como Opera estan lejos de alcanzarlo:

[singlepic id=6 w=700 h=458 float=center]

 

“Letras” (SpeedReading)

Uno de los mejores test para comprender la importancia de la aceleración gráfica dentro de los navegadores. Pasamos de los 6 segundos en finalizar el test a más de 2500 en el caso de Safari:

[singlepic id=18 w=700 h=458 float=center]

 

 Psicodélico

Otro test que se ha hecho muy extendido y famoso en toda la red por demostrar el potencial gráfico 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 máxima velocidad posible:

[singlepic id=15 w=700 h=458 float=center]

 

Webvizbench

Aunque no deja de ser un benchmark, es uno de los mejores ejemplos de canvas compuesto, con una alta carga JavaScript, gráfica, CSS… explota al máximo desde transiciones, composición de capas, animaciones… es de los test más completos que veremos por aqui, y orientado siempre a aplicaciones prácticas que podrían/pueden crearse y que antes eran totalmente impensables. Uno de mis test favoritos sin duda:

[singlepic id=26 w=700 h=458 float=]

 

Tanque de Peces (50.000) y Sistema Solar, ambos para WebGL

Aunque en la entrega anterior WebGL no llegó a puntuar realmente, en esta ocasión dado que Opera da soporte de forma oficial también, es coherente añadirlo. 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 obtendrán 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 aceleración por Hardware por contenido y capas 3.000 peces parecían ser el tope por ahora, el rendimiento por WebGL frente al test anterior es sorprendente:

[singlepic id=22 w=359 h=235 float=left][singlepic id=17 w=359 h=235 float=center]

 

Peacekeeper

Test sintético que mezcla varios elementos para medir el rendimiento de los navegadores. Personalmente me gustaba más la versión anterior pero ya no es posible hacerla andar. Mezcla parte JS, trabajo con cadenas, gráficos… y sobre todo objetos DOM. Como ya dijimos también, ha sido un test muy criticado por explotar con fines mediáticos 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 débiles 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 más test puntúa más. Más que nada porque el test en un momento dado intenta reproducir vídeo en diferentes codec por medio de html5, y si no lo logra no lo puntúa correctamente. Recordemos que el codec usado para el tag <video> de html5 no es una especificación, que eso queda a discreción del navegador. El test de niels pra HTML5 es mucho más riguroso en este tipo de cuestiones, Peacekeeper no tendría incluir en sus test este apartado

[singlepic id=13 w=700 h=458 float=center]

 

Spinnig Balls

Cualquier programa informático 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 subiría constantemente y terminaría con consumir toda la existente, y segundo porque la ejecución del programa sería cada vez más lenta y los datos en RAM más fraccionados. Esto como digo se evita “reciclando” la RAM cada cortos períodos de tiempo. Los navegadores pueden producir en cortos períodos de tiempo muchos objetos nuevos que se destruyen igualmente rápidos 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 estén usando pueden detener la ejecución del proceso hasta que el reciclado se ha terminado. Esto en un navegador se traduce por ejemplo con una extraña pausa en un momento dado, un salto en u juego, un drop de FPS momentáneo… cuestiones que realmente no implican que el proceso se ejecute más rápido o menos rápido, 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 puntuación es para aquel navegador que realiza menos pausas o pausas más 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 implicación es menor y la ejecución mucho más fluida.

[singlepic id=19 w=700 h=458 float=center]

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

 

Test de compatibilidad HTML5 de Niels

A día de hoy pun buen navegador no solo es aquel que es el más rápido, sino que también está en continuo desarrollo para adaptarse a los nuevos tiempos y a los nuevos estándares. 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 ningún otro estándar, y son muchos otros los que a día de hoy disponemos:

[singlepic id=10 w=700 h=458 float=center]

  • El test de Niels se basa actualmente sobre 500 puntos máximos.

 

Test de compatibilidad WebGL de Khronos

Exactamente igual que testeamos poco a poco las especificaciones HTML5 que van formándose, hacemos lo mismo con las especificaciones de WebGL. WebGL es un estándar para permitir que el navegador pueda ejecutar gráficos 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 podrían ejecutarlos correctamente

[singlepic id=1 w=700 h=458 float=]

  • Internet Explorer y Safari: No son compatibles
  • Chrome: Varios test de la suite producían un comportamiento totalmente anómalo de este, obligando a reiniciar Chrome. El resultado mostrado es eliminando los test que impedían su funcionamiento
  • Firefox: Aunque pudo completar el test totalmente, uno de los test en particular (que también afectaba a Chrome) producía 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 estándares. 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).

También 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 engañosa. 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 habría que sumarle además 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 día de hoy y un excelente trabajo por parte de Microsoft sin duda, pero que quizás 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 tecnologías es hasta bonito:

[singlepic id=8 w=700 h=458 float=center]

  • Mis test están actualizados con la última versión del IE Center de Microsoft, actualizada a 29/02/2012

 

 

Conclusiones

Si valoramos cada navegador como se dijo al comienzo, los resultados serían por tanto los siguientes:

Resultados Firefox 14 x86 Chrome 19 IE 10/9 x86
Opera 12
Safari 5.1
Rendimiento 56 48 34 19 35
JavaScript 12 12 7 9 5
Canvas 14 17 16 6 7
Gráficos 25 14 24 22 7
WebGL 10 8 0 6 0
Otros 8 9 2 7 4
Compatibilidad 12 11 6 10 3
Estabilidad 5 5 3 2 1
           
Total 134 115 90 74 58

 

  • Rendimiento

    El rendimiento de un navegador no sólo se resume en lo rápido que pueda ejecutar un código en JavaScript o los fps que sea capaz de mostrar en cualquier aplicación/juego. De echo, desde mi punto de vista posee un peso más 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 más potentes, pero las páginas Web, las aplicaciones Web… cada vez son más 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 más rápida 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 rápido 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 estén abriendo al mismo tiempo múltiples pestañas. Este comportamiento evidencia la necesidad de que el navegadores sean poco a poco multiprocesados. Recordemos que aunque todos los navegadores a día de hoy sin multihilos, tan solo Internet Explorer y Chrome son multiprocesos. Esto les otorga entre otras cosas ser (al menos teóricamente hablando) más veloces y eficaces a la hora de manejar múltiples pestañas. 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 pestañas y llegará a ser una realidad el proyecto Electrolysis. Igualmente, antes o después Opera y Safari tomarán caminos similares.

    El principal problema de abrir múltiples pestañas 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 múltiple de muchas pestañas podría provocar al usuario la sensación de paralización/congelación de este hasta que prácticamente todas las pestañas estuviesen cargadas, ya que desde el punto de vista del navegador tan solo estaría llevando a cabo una misma tarea. Para Internet Explorer o Chrome este problema no lo tienen, cada pestaña tiene su propio espacio y sería el propio sistema operativo quien gestionaría por medio de su planificador (Scheduler). Para tratar con ello, tanto Opera como Firefox usan por defecto la carga selectiva de pestañas, es decir, por defecto cuando se abren múltiples pestañas a la par tan solo se cargan aquella que esté en primer plano. El efecto es inmediato, de poder tener el navegador paralizado durante múltiples segundos la navegación es instantánea, y mientras se pueden ir cargando de fondo el resto de las pestañas. Por supuesto a la hora de medir los tiempos, este comportamiento se deshabilitó para que todos los navegadores estuviesen en igualdad de condiciones.

    Todo tiene pros y contras, y que una aplicación 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 aplicación. 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 más intermedio y como sorpresa, Opera mostró un resultado terrible.

    En otro orden de cosas encontraríamos 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 rozaría los pies de cualquier modo siendo las diferencias mínimas, e Internet Explorer mostró un comportamiento bastante decente.

    Por último, hay que destacar el rendimiento en la reproducción de contenido en 1080p de los navegadores y de la mitificación que otrora intentó Steve Jobs en que Flash es la lacra para el rendimiento, la seguridad y el pasado. Para empezar Flash es mucho más que un simple reproductor de vídeos, y para terminar es evidente que a día de hoy es de lejos la mejor opción a la hora de reproducir cualquier contenido en HD. Si miramos los recursos usados por el equipo en la reproducción de contenidos en Flash y contenidos en WebM, vemos que las diferencias son sorprendentes. Evidentemente estas grandes diferencias son principalmente por la aceleración por Hardware con la que cuenta Flash y no WebM, pero es una cuestión de números. Mientras que reproducir en el equipo de pruebas un vídeo 1080p en flash consumía 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 día de hoy la mejor opción para la reproducción de vídeos es Flash gracias al gran soporte que esta tecnología posee en cuanto a aceleración de hardware se refiere.

    Por supuesto, se podría usar otros codec como H264 para la reproducción de vídeo por HTML5, y este poseería mejor soporte para aceleración por hardware que WebM (y mayor calidad), pero h264 está fuertemente patentado. Aun así, el rendimiento sería inferior al mostrado por Flash.

    No estoy diciendo que el futuro del vídeo sea Flash, el que los navegadores posean capacidad para reproducir vídeo y audio a través de ellos mismos es algo importantísimo 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 imposición de h264 como codec  de vídeo junto a AAC como codec de audio tampoco parece ser una respuesta a corto plazo, aunque personalmente desearía que esta última opción 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 vídeo VP8 (el usado en WebM)  no es rival de h264, y además este último posee mucho mejor soporte Hardware. Veremos en el futuro como termina la cosa… mientras tanto podemos más que conformarnos y ser felices por el extraordinario rendimiento de Flash.

     

  • JavaScript

    Los test sintéticos 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 números 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 puntuación en los otros dos benchmarks!! cuando además se supone que Kraken es un derivado de SunSpider. O al revés, mientras que Chrome obtiene una puntuación totalmente disparatada en su propio test V8 (el de Google), obtiene la penúltima posición en SunSpider.

    No hay que ser un genio para darse cuenta que todos los navegadores (sin excepción) optimizan partes de su código a sabiendas de estos test, con la inclusión de Fast Path y otros. Por supuesto que muchas de estas optimizaciones pueden ser llevadas a entornos reales, pero es evidente que la mayoría no, la mayoría tan solo tienen utilidad en estos test, y por tanto su fiabilidad es más que dudosa.

    De nuevo no quiere decir que sean totalmente inútiles 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, pequeños cambios. En cuanto a V8 si hay cambios más significativos, pero hay que tener en cuenta que V8 fue actualizado a su versión 7, mientras que el test anterior era la V6.

 

  • Canvas

    He querido separar este apartado del de JavaScript, aunque en realidad están muy relacionados uno con otros. En la comparativa anterior se usaban dos juegos de ejemplo que en esta ocasión han sido sustituidos por otros dos test. Canvas es una de la infinidad de especificaciones que poseerá el estándar HTML5 y que se están 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 código principalmente en JavaScript, CSS…  con lo que es posible la creación 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 gráfico también de otros muchos factores.

    Es complicado medir este apartado dado que se puede crear un Canvas con el contenido más vario pinto posible, y es más 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 gráfico), Chrome e Internet Explorer son los líderes, estando Firefox relegado a una tercera posición. Más sorprendente es el caso de Opera, que aun cuando exhibe un buen comportamiento JavaScript (y como veremos más adelante gráfico) obtuvo la peor calificación. Esto nos hace ver que un entorno real como una aplicación o un juego HTML5 no es un test sintético, 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 gráfico, fracasa estrepitosamente aquí. Safari por su parte logra a duras penas quedar por encima de Opera.

 

  • Gráficos

    Hay que tener en cuenta antes de empezar, que aunque esta sección se llame “gráficos” no tiene nada que ver con la elavoración de gráficos complejos 3D ni nada por el estilo, sino test que pueden sacar un provecho enorme de la aceleración hardware. Así por ejemplo tenemos el test de SpeedReading que tan solo se vasa en un marcador veloz de letras, o psicodélico, que no deja de ser una imagen girando sobre sí misma.

    En la comparativa anterior, el soporte de Chrome para aceleración de vídeo estaba habilitado por defecto, y ya antes era inestable. En esta ocasión vemos que estando deshabilitado (que es como está por defecto) Chrome cae a posiciones inferiores. Aun así, aun de estar habilitado habría obtenido la misma puntuación casi con toda seguridad, ya que en esta ocasión 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 gráficamente 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 número de peces de estos para que Opera no fuese capaz de llegar a los 60 fps. Aunque al final terminase en la tercera posición, 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 visión fue totalmente diferente a la de Internet Explorer o Firefox. Tanto Internet Explorer como Firefox usan la API DirectWrite y Direct2D para la aceleración 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 además en los consumos de CPU/GPU de dichos test.

    El adaptador de vídeo no se comporta igual si está ejecutando código en DirectWrite que código en OpenGL. Evidentemente (y como veremos más 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 repercusión directa en el adaptador de vídeo, y es que este junto a los Drivers otorgan siempre más recursos a contenido que supuestamente es 3D. Es decir, la API DirectWrite/Direct2D está diseñada precisamente para sobrecargar en lo menos posible al adaptador de vídeo, 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 asunción es totalmente sensata y es lógica: “Si se requiere de unos recursos muy elevados será porque se estará manejando gráficos 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 más 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 vídeo al máximo, 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 algún momento incorporará soporte hardware en su navegador… cosa dudosa teniendo en cuenta la mala imagen que podría 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 teoría debería 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 más o menos evidente. Firefox no solo tiene creado el backend de Direct2D/DirectDraw, sino que posee también 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á más compatible dentro de los diferentes adaptadores de vídeo 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 también WebGL.

    Aunque en el apartado anterior se ha hablado de forma extensa sobre la aceleración de hardware y de contenido gráfico, 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 través de diferentes APIs, como por ejemplo una imagen girando velozmente sobre ella misma, transiciones rápidas… aplicaciones o juegos que podemos encontrar cada vez más en cualquier lado. No hablamos de apartado gráfico anteriormente porque manejásemos gráficos complejos, sino para especificar que son test que hacen uso extensivo del adaptador de vídeo.

    Pero WebGL es totalmente diferente, con WebGL sí asumimos que vamos a trabajar (o al menos que podemos trabajar) con gráficos complejos. WebGL se crea como iniciativa de poder renderizar en Canvas contenido 2D/3D complejo a través de OpenGL. De prosperar y ser realmente eficiente (que es discutible dado la gran sobrecarga de JavaScript) podríamos encontrar a medio plazo juegos con bastante potencial gráfico 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 jamás una aplicación/juego programada en C++ y OpenGL que programada en JavaScript y WebGL. Esta tecnología jamás será un sustituto ojo, WebGL no llega para desbancar nada, sino para añadir algo que antes era imposible.

    Gracias a WebGL vimos el increíble trabajo por parte de Google y Zigote con “Body Browser”, que es una aplicación totalmente práctica, útil y funcional. Realizar algo así sin WebGL sería imposible a día de hoy, se debería de instalar algún complemento en el navegador.

    No obstante aquí encontramos un escenario muy interesante si comparamos los datos obtenidos. Opera que obtenía unos resultados increíbles 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 explicación: Opera usa OpenGL como backend también en WebGL, pero tanto Firefox como Chrome usan ANGLE. ANGLE es un proyecto impulsado/creado/mantenido por Chrome que básicamente 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 código ejecutado en OpenGL a través 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 más rápida. Incluso con ANGLE que tiene que hacer de “traductor”, el rendimiento a través 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 varía 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 vídeo Intel, que poseen un soporte para OpenGL mucho más pobre. ANGLE es una solución muy eficaz ya que asegura que sea cual sea el fabricante o el adaptador de vídeo que se tenga instalado, mientras que este sea compatible con DirectX 9.0c podrá ejecutar a la perfección 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 ningún pretexto el uso de la API DirectX, y OpenGL forma parte intrínseca de él. En el caso de Linux es posible usar OpenGL 4.2.0 (la especificación más alta actualmente) siempre y cuando el adaptador de vídeo lo permita, en el caso de MAC OS, este tan solo soporta OpenGL 2.0 y con algunas carencias.

    El test que más nos llama la atención 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 podría decir que si disponemos de WebGL que sentido tiene el test anterior en el que el navegador no podía con 3000. Y volvemos a lo mismo, las peras se parecen a las manzanas en que las dos son frutas, pero nada más. Es más que evidente que si cualquier test html5 se puede pasar a WebGL (con lo que debe de tener un fuerte componente gráfico evidentemente) su rendimiento será infinitamente superior. En parte es la misma explicación por el cual Opera obtenía 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 sería muy superior. Pero es lógico, son APIs totalmente diferentes orientadas a funciones totalmente diferentes. Direct2D/DirectDraw no están pensadas para proporcionar un rendimiento de vértigo exprimiendo la GPU.

 

  • Estándares

    Actualmente parece que existen dos grandes frentes abiertos a la prensa. Si uno es el rendimiento en los test sintéticos, el otro es el proclamar que su navegador es compatible con HTML5, o mejor dicho, pelearse por cual es más compatible en este campo. Señores, HTML5 es muy importante en el futuro, pero de nuevo no es el único estándar emergente estos días. Es más, actualmente es infinitamente más usado CSS 3.0 como estándar 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 estándares 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 más compatible de cara a HTML5, es Chrome quien posee cierto liderazgo aquí. El problema de Chrome es que aunque es cierto que es más compatible a efectos generales en HTML5 que el resto de los navegadores, no a efectos concretos. Es decir, Chrome implementa la mayoría de funciones de HTML, pero de una forma básica, y lo mismo le pasa con CSS y otras tecnologías. Opera en contrapartida se centra en menos variedad pero de una forma mucho más profunda, intentando cumplri a rajatabla todas las especificaciones de cada sección. Esto hace que en test generalistas como el de Niels Chrome obtenga muy buenos resultados y en otros más específicos como la suite de IE obtenga resultados algo inferiores.

    Sobre la Suite de Microsoft poco podemos añadir, evidentemente es una suite totalmente engañosa para mostrar que Internet Explorer es el navegador más 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 día de hoy muchso webmaster necesitamos crear código redundante y hacer “trampas” para que las web se visualicen correctamente en Internet Explorer, precisamente por no ceñirse a los estándares.

    Sobre WebGL, tanto Firefox como Chrome continúan aumentando su compatibilidad, aunque desde que Khronos publicase la nueva versión 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 sumándose a los estándares y apoyando lo que sin duda alguna podrá ser de muchísima utilidad en el futuro. Y es evidente, hasta que no hay en el mercado un buen soporte los programadores y diseñadores no pueden pillarse los dedos creando maravillas en la web que tan solo podrán 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 más o menos claro que antes o después lo implementará, pero cada día que pasa se duda más 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 podrían 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 ningún fallo de seguridad producido por ello. Sería 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 política, 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 versión 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 versión de 64 bits, que como hemos visto siempre en Internet Explorer 9, está muy por atrás del resto.

    Firefox continúa 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 versión de 32bits y la de 64 bits de Firefox están casi siempre cara a cara. Aun así la versión 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 versión totalmente funcional, en la que muchas veces su rendimiento es superior a las versiones de 32 bits, y más seguras.

    Opera irrumpe con su versión de 64 bits. En el caso de Opera no son tan estables como las versiones de 64 bits de Firefox y están menos optimizadas, pero parten desde una buena posición. Sin duda alguna Opera ha dado un gran salto en esta ocasión en muchos aspectos, desde la salida de su versión de 64 bits, soporte para aceleración 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 están haciendo un gran trabajo.

    Sobre Chrome y Safari por otro lado no hay indicio alguno de que una versión de 64 bits pueda ver la luz a corto plazo… habrá que esperar. Es de suponer que eventualmente Chrome sacará una, pero…

 

  • Consumo energético

    ¿Como puede influir un navegador en el consumo energético de un dispositivo? Pues es fácil, 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. Sería muy complicado llegar a una decisión unánime sin acudir a un tester de potencia y medirlo directamente, pero si más o menos imaginarlo.

    Mirando las gráficas, parece claro que el navegador más eficiente energéticamente hablando dependería dependiendo del contenido. En un escenario normal, el mejor resultado sería para Internet Explorer o Firefox, en cambio cuando se entrase en test más complejos el ganador sería Safari (por la sencilla razón de que no usaría la GPU y que no sería capaz de ejecutar correctamente el test). Opera en cambio obtendría el peor consumo de forma general, aunque puede obtener unos resultados increíbles, elevar al 97% el uso de la GPU en el test de la pecera es demasiado.