Archivo de la categoría ‘Web’

La fiabilidad de las encuestas, votaciones… realizadas en la red, y lo fácil que puede resultar manipularlas

 

 

Inicio Fin (10 minutos después)
Opción 1º: 43.6%  20.7%
Opción 2º: 10.1%  4.8%
Opción 3º: 17.4%  8.2%
Opción 4º: 17.5%  8.3%
Opción 5º: 11.4%  58.1%
Número de Votos: 2506  5462

 

Raro es el día que nada más abrir Thunderbird no recibo en las suscripciones RSS algún resultado nuevo de alguna encuesta, votación o gráfica basada en las supuestas respuestas de los cientos y miles de usuarios que supuestamente votan en ellas para dejar su opinión: Cuestiones políticas, preferencias de consumo, concursos, sondeos… raro es el periódico o site más o menos conocido que no tiene una encuesta o recoge datos semanalmente, para luego exhibirlos igualmente en los periódicos, o en publicaciones de toda índole.

La pregunta que uno debería de hacerse es simple: ¿Como de fiables son estos datos? Y la respuesta es aun más simple: No lo son, y eso es lo gracioso. Esto no quiere decir que cualquier gráfica, resultado de encuentras o votaciones sea mentira o los datos no seas ciertos, significa que a día de hoy tomar por cierto esos datos simplemente porque cualquiera los exponga sería poco inteligente.

En este caso me he cebado/centrado en particular con un servicio de encuestas llamado tusencuestas.com que usan no pocas webs, que usan simplemente para plasmar unos resultados, confeccionar estadísticas y otros. Al igual que este sistema, existen muchos similares, algunos más seguros, otros menos. Esto no quiere decir que TODOS los sistemas sean susceptibles de manipular, aunque tampoco quiere decir lo contrario. Primero un poco de literatura y después veamos el caso práctico… quien quiera saltarse el bla bla bla puede irse más abajo directamente y ver lo que sucedió con tusencuestas.com

 

Lo peor de todo, además, es que detrás de esos datos muchas veces se puede encontrar no solo una duda sobre su fiabilidad, sino que son múltiples las cuestiones que nos pueden llegar a pensar que eso datos dictan mucho de ser ciertos. Hay que tener cuidado cuando se habla de manipulación de datos, dado que muchas veces no son manipulados directamente, pero hay muchas formas de manipular la información. Veamos algunos ejemplos:

 -“Lugar” en que se recogen los datos: Esto es simple, si por ejemplo aparece una encuesta o una gráfica aparece en un diario con fuertes tendencias políticas, los datos recogidos serán en su inmensa mayoría provenientes de lectores con la misma ideología política, y por tanto los resultados serían evidentes. Si la misma encuesta o los mismos datos fuesen recogidos en otro diario con fuerte tendencia política contraria, los resultados serían totalmente opuestos. Este sistema se usa de forma extensiva todos los días.  Personalmente, creo que cualquier encuesta o recogida de datos realizada por cualquier medio partidista o a fin a cualquier tipo ideología (religiosa, política, clase social…) carece totalmente de valor por lo mismo. Extrapolado a la tecnología sucede exactamente lo mismo, si entras en un foro a fin a Microsoft y pusieses una encuesta sobre lo bueno o malo que es Windows saldría que es bueno por una amplia mayoría, si lo haces en un site fin a Apple dirá que MAC OS.

-Confianza en el autor de dichos datos: Más simple aun, damos por echo que dicha recogida de datos tiene detrás a una persona de la cual hay que fiarse, que no haya modificado los datos ni vaya a hacerlo. Por supuesto no digo que lo haga, digo que podría hacerlo.

-Manipulación por parte de los propios usuarios: Incluso cuando se pongan las mejores intenciones en la fiabilidad de dichos datos, si no se usa un sistema decente para la recogida de dichos datos estos de nuevo no pueden tener ningún tipo de validez, y esto es culpa tanto de los propios usuarios como quien está detrás de todo ello.

 

Aquí no podemos señalar con el dedo o asegurar sin pruebas quienes inventan resultados o los manipulan, pero sí podemos ver lo simple que puede resultar para un usuario la modificación de estos, y si cualquier usuario muchas veces puede hacerlo, prueba irrefutable de la validez cero de este tipo de sistemas, sobretodo repito cuando no se es nada riguroso.

El principal problema, quitando por supuesto la honradez del equipo/persona que esté detrás de esa recogida de datos, son los sistemas usados para tales recogidas de datos. Muchas veces los propios equipos/personas encargadas en esa recogida de datos usan métodos consabidamente “manipulables” a fin de que los resultados sean aun más impactantes cuando son mostrados. Y es gracioso, puesto que lo único que debe de hacer un buen sistema de recogida de datos de este tipo es: Un solo submit/voto/estadística/comentario… por persona física. Y señores, uno es uno, no son dos ni tres, es uno ¿Es que acaso en las elecciones generales nos permiten votar más de una vez?

El mundo de la informática está sujeto de la picaresca humana, y seamos franco, en España tenemos mucha de esa. Y es que he llegado a encontrar encuestas incluso en periódicos (en sus ediciones digitales evidentemente) de primera línea en las que con tan solo seleccionar la opción indicada y darle a enviar se contabilizaba automáticamente un voto, sin importar cuantas veces lo hicieses. Es decir, un solo usuario podría en 3 minutos realizar cuantas… 100 votaciones? 300? Y eso sucede (al menos ha sucedido) como digo en medios principales de nuestro país, que días más tarde salen en portadas, noticiarios, radio… jactándose unos y otros de los resultados tan dispares que aparecen.

Existen muy variados sistemas para impedir este comportamiento por parte del usuario (impedir hacer trampas):

-Uso del DNI-e: Sería un sistema viable, seguro y riguroso, casi totalmente imposible de manipular. El problema es que el usuario tendría que molestarse más de lo debido para enviar la información (tener el DNI-e, un lector…)

-Introducción del DNI: Podríamos sortearlo introduciendo un DNI falso, en el mejor de los casos el site verifica el número frente a la letra, y para ello tan solo tendríamos que introducir cualquier número de 8 cifras y calcular la letra de este. Este sistema no sirve.

-El uso de Cookies: La mayoría sabemos que es una Cookie en el navegador, una práctica muy habitual es marcar el equipo del usuario con una cookie que registra la introducción de los datos e impide volver a repetirlo… el problema es que una cookie se puede borrar en lo que se tarda contar 3 misisipis. Este sistema es inútil.

-El registro de la IP: Muchos otros usan la premisa que si tenemos asignada una IP por nuestro ISP, si se registra esta IP se lograría un solo “voto por persona”. El problema es que detrás de un dispositivo NAT (un router por ejemplo) puede existir desde una familia ha una empresa con muchos empleados, y este sistema estaría denegando el acceso a dichos usuarios desde ese lugar, sin contar por supuesto que sería posible saltarse el sistema poxeando o tuneleando la conexión sin mayores problemas. Incluso es relativamente simple el uso de programas o scripts para automatizar el proceso para ir saltando de proxy en proxy constantemente. Este sistema es inútil.

-El registro del User-Agent: Todos los navegadores tienen por así decirlo un identificador propio y único en teoría que los identifica. Muchos sitios usan la combinación entre User-Agent+IP+Coockie para de este modo permitir tan solo “un voto por persona”, permitiendo solo desde la misma IP múltiples accesos siempre que fuesen con diferentes User-Agent, de este modo en teoría se estaría permitiendo a otro usuario diferente detrás de la misma IP pública poder realizar su aportación. El problema es que si cambiar la IP momentaneamente es fácil, modificar el User Agent es aun más simple. En Firefox es tan simple como cambiar la opción: “general.useragent.override”, o por supuesto por medio de scripts y wget en linux.Evidentemente este sistema es inútil.

 

Dado que el único sistema viable y seguro es molestar al usuario, esto no es viable, por tanto es lógico usar un sistema alternativo, que aunque sea posible de saltarse al menos sea lo suficientemente “lento” o farragoso para un usuario mal intencionado de sortear. Y ante esto hay dos aproximaciones que he visto de forma extensa: Los que usan JavaScript para realizar las comprobaciones pertinentes y lanzar o no así las peticiones, y los que usan PHP para lo mismo. JavaScript es un lenguaje que se ejecuta en los equipos de los usuarios, PHP se ejecuta en los servidores… por tanto cualquier programador que use JavaScript para este tipo de cuestiones, y sin ánimo de ofender a nadie, es idiota. Si se ejecuta en el equipo del cliente, el cliente puede modificar el código como quiera, y por tanto puede evitar prácticamente cualquier medida preventiva que hubiese añadido, por no decir que tendría acceso al código JavaScript y ver por donde pillarlo. Con PHP por otro lado no es posible saber que se está realizando en el otro lado, ese código no nos llega, tan solo podemos saber que datos enviamos nosotros, pero no como se tratarán esos datos.

En este caso concreto de tusencuestas.com, ni que decir queda que usan JavaScript para sus sistemas, algo realmente absurdo por lo simple que resultará como veremos modificar cualquier votación/encuesta que usa su plataforma en unos pocos minutos.

Tomemos de ejemplo una web cualquiera que use este servicio, en este caso concreto he tomado la web de un programa televisivo bastante conocido en España, y que por deferencia a ellos me abstengo de decir. En este portal aparecen encuestan semanales cuyos resultados son al final presentados en el propio programa de televisión. La votación semanal en esta ocasión cuenta con 5 opciones posible, que por motivos obvios no pongo que se vota ni cuales son las opciones… de lo contrario cualquiera podría saber a que estábamos refiriendo. Actualmente la distribución es la siguiente:

1º Opción: 43.6%
2º Opción: 10.1%
3º Opción: 17.4%
4º Opción: 17.5%
5º Opción: 11.4%

Con un total de 2506 votos.

El problema reside como he dicho en que este proveedor de encuestas/votaciones, tusencuestas.com, usa JavaScript para registrar las votaciones, y para peor males tan solo prohíbe la votación por una simple verificación de Cookie. Aun así, como veremos más adelante, el echo de usar una cookie o no para verificar si el usuario ya votó o no es totalmente irrelevante. 

Lo primero es echar un vistazo al código HTML del formulario de envío de la votación:.

<div id=”tusencuestas_identificador”><div width=”100%”><div width=”100%”>Nombre de la Encuesta</div><div width=”100%”>
<input type=”radio” value=”287603″ name=”tusencuestas_respuesta_resultados_name”> Opcion 1º<br>
<input type=”radio” value=”287604″ name=”tusencuestas_respuesta_resultados_name”> Opcion 2º<br>
<input type=”radio” value=”287605″ name=”tusencuestas_respuesta_resultados_name”> Opcion 3º<br>
<input type=”radio” value=”287606″ name=”tusencuestas_respuesta_resultados_name”> Opcion 4º<br>
<input type=”radio” value=”287607″ name=”tusencuestas_respuesta_resultados_name”> Opcion 5º<br>
</div><div width=”100%”><span align=”center”>
<input type=”button” onclick=”tusencuestas_votar();” value=”Votar”></span><br>
</div></div></div>

 Por comodidad he eliminado algunos hash que continuaban a cada propiedad name. El caso es que se trata de un formulario muy simple, 5 opciones posibles a las que se asigna dependiendo de cual esté seleccionada un valor diferente. Cando el usuario quiere enviar su voto tan solo tiene que presionar el botón “Votar” que aparece en la encuesta, en cuyo caso el formulario invoca la función “tusencuestas_votar()”.

Del mismo modo, podemos echar un ojo al código JS de la web dicha función:

function tusencuestas_votar()

{
if (cookieHabilitada())
{
var accion_argumento = tusencuestas_recogeValor();
tusencuestas_accion(2, accion_argumento);
if (accion_argumento != “-1”)
{
var expira = new Date();
expira.setSeconds(expira.getSeconds() + 604800);
setCookie(“P_Id” + P_Id_hash, “1”, expira, “/”);
}
else
alert(‘��Escoge  una opcion!!’);
}
else
alert(‘No puedes votar porque no tienes las cookies habilitadas’);
}
 En realidad antes de pasar a esta función, si nuestro navegador envía una Cookie anteriormente seteada, el sistema no nos permitirá realizar la votación, y en vez de eso nos mostrará el resultado que pusimos anteriormente. La función mostrada tan solo tendremos acceso a ella si nuestro navegador no posee aun la cookie en cuestión. La función es bien simple. Si tenemos las cookies habilitadas, recoge el valor de nuestra opción marcada y lo almacena en la variable accion_argumento, y después invoca otra función que supuestamente será la que registre la votación. El resto de la función simplemente setea la cookie para que el sistema detecte al visitante que ya ha votado o muestre uan advertencia si tenemos las cookies deshabilitadas.
 
En otras circunstancias más complejas tendríamos que continuar con un seguimiento de las funciones que se van llamando, así como verificar efectivamente que la funcion recogeValor efectivamente captura el valor de la opción marcada (mostrado anteriormente en el código HTML). Pero lo cierto es que los amigos de tusencuestas.com lo han dejado francamente sencillo. Simplemente usando la consola del navegador (Ctr+Shift+k en Firefox) podemos introducir insitu el código JS que deseemos inyectar en la web que queramos, a fin de cuenta como hemos dicho el código JS es ejecutado en nuestro equipo. Así pues, podemos de forma directa introducir la función que suponemos es relevante para el caso:
 
tusencuestas_accion(2, 287607);
 
El valor 287607 no es arbitrario evidentemente, corresponde a la opción 5º del código HTML anteriormente tomado. Es decir, si todo es correcto simplemente invocando esa función en dicha web, se estaría enviado un voto a la 5º opción, sin preocuparse nadie ni nada de cookies o historias. siempre quedaría la opción de que el servidor denegar multiples conexiones desde la misma IP, pero este no es el caso.
 
Interesantemente, el servidor al introducir esa función por consola nos responde con:
 
GET http://www.tusencuestas.com/acciones/tusencuestas.aspx?44905… [HTTP/1.1 200 OK 1231ms]
Está acortado por comodidad, es a fin de cuenta una URL compuesta entre otras cosas con el ID de la encuesta (que he suprimido desde el comienzo, el valor de la opción y algunos datos más.
 
Llegados a este punto, cada vez que introducimos la función por la consola y le damos a enter, automáticamente si lo comprobamos el sistema registra un voto!! Simplemente presionando cursor arriba y enter introducimos en el sistema un nuevo voto… 10, 100, 1000… pero seamos sinceros, eso un poco farragoso y un trabajo manual de narices si deseamos por ejemplo darle la vuelta a la encuesta, o suponer en una encuesta que hayan miles o decenas de miles de votos… nos llevaría un ratito. Por suerte el voto se registra simplemente con una petición GET al servidor, como vemos en la propia consola. De echo si copiamos la URL y la pegamos directamente en la barra de dirección se registra también el voto. Por tanto, nada más sencillo que automatizar el proceso:
#!/bin/sh
X=0
while [ $X=0 ]
do
wget -O- –timeout=1 “http://www.tusencuestas.com/acciones/tusencuestas.aspx?44905…”
done
exit 0
Un simple script que realiza de forma indefinida peticiones HTTP que registrarán el voto por medio de wget, especificando que no se desea un arcivo de salida y un timeout de 1 segundo (ahora mismo lo necesito por cuestiones de retrasos de la línea en la que estoy). Y con eso el negocio quedaría terminado.
 
Para ver si funciona tan solo hay que invocar el script y ver que pasa al cabo de un ratito, pongamos 10 minutos:
 
 1º Opción: 20.7%
2º Opción: 4.8%
3º Opción: 8.2%
4º Opción: 8.3%
5º Opción: 58.1%

Con un total de 5462 votos.

 
En realidad, poca importancia tendría que tener esto, a fin de cuenta que importancia puede tener si en un periódico hacen una encuesta sobre cual es político mejor valorado o el peor… No porque la encuesta o la votación en sí carezca de sentido, sino que se usan la mayoría de las veces con fines demagogos. La importancia radica de nuevo, como en la mayoría de las veces, en lo que el usuario cree o quiere creer, dejándose casi siempre influenciar por lo que leen/escriben otros, sin pensar generalmente un poco por ellos mismos. ¿Cuantas gráficas vemos con datos tan contradictorios a lo largo de la semana? Si accedes a cierto tipo de sitios las estadísticas son unas, si entras en otros las estadísticas son diferentes… a veces explican con pelos y señales las condiciones en las que los datos fueron recogidos, otras veces son tan absurdas que comparan manzanas con platanos tan solo para que los defensores salten a la red en cualquier lugar: Blog, foros… defendiendo a ultranza a veces con total fanatismo ideas de otros con datos tergiversados y muchas veces manipulados.
 
Ahí queda eso señores. Solo espero que aquel que lea estas letras, la próxima vez que vea una encuesta, votación, gráfica… se pregunte aunque solo sea por un segundo de donde salieron esos datos, que sistemas usaron y que intereses o no puede existir detrás.
 
Un saludo.

Comparativa Navegadores 2012/Q1: Internet Explorer 10, Firefox 14.0, Chrome 19.0, Safari 5.2, Opera 12

Í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.

Comparativa Navegadores 2011/2: IE9, Firefox 9.0, Chrome 15.0, Safari 5.1, Opera 12

Índice

  • Versiones de los navegadores
  • Que comparar
  • Benchmarks (Nuevo: RAM, CPU, GPU, Consumo Energético…)
  • Conclusiones

 

Versiones de los navegadores

Dada la nueva tendencia al ciclo rápido de versiones al cual se están agarrando los principales navegadores, no tiene lógica hacer una comparativa cada vez que sale un navegador nuevo, puesto que además entre versiones contiguas no existirían grandes diferencias. Antes veíamos este comportamiento tan solo en Chrome, cuya versión en desarrollo es ya la 15!! los chicos de Mozilla igualmente, con los ciclos cortos de versiones han hecho que la versión en desarrollo actual sea la 9. Es decir, si recordamos la comparativa de hace 6 meses de este mismo redactor, vemos que la versión recién lanzada era Firefox 4.0 y Chrome 10. Por el contrario Micorosft con Internet Explorer 9, Opera y Safari han mantenido sus ciclos algo más largos.

En esta ocasión no se han tomado los navegadores oficiales, sino sus versiones en desarrollo más actuales. ¿Por qué? Bueno, es evidente que los navegadores que más van a dar que hablar presumiblemente (quitando sorpresas) Firefox y Chrome, y precisamente estos dos son los que poseen menos diferencias entre sus versiones oficiales y sus versiones en desarrollo, puesto que poseen los ciclos más cortos. Esto hace que se haya tomado la versión build hasta el día de hoy (1 de septiembre de 2011) de Firefox 9.0a1 (la build de dicho día) y de Chrome 15.0.865.0. En el caso de Opera, la versión en desarrollo tomada corresponde a la lanzada hace unos 10 días, Opera 12 (build 1047), que es la más actual

En el caso de Internet Explorer no es posible acceder a una versión más actual por desgracia, quitando las actualizaciones que ha ido añadiendo microsoft a IE9 en estos meses, desde actualizaciones de seguridad como de rendimiento. Es cierto que existe una Preview 2 de IE10, el problema que tenemos con la versión Preview de IE es que no se puede decir que sea realmente un navegador, sino prácticamente tan solo el chrome (no confundir aquí chrome con e navegador Chrome) de este. Es como si a Chrome o Firefox le suprimimos casi toda la interfaz, opciones, extras… y dejásemos tan solo una “ventana” a algunas web.

Por último, Safari posee ciclos intermedios. Así por ejemplo si en la comparativa anterior teníamos Safari 5.0.3 si recuerdo bien, en esta ocasión trataremos con Safari 5.1. Safari sí posee entre “” versiones de desarrollo, pero son más exactamente de Webkit y no tanto de Safari. De todos modos para la próxima ocasión intentaré usar la última Build de WebKit para Safari, aunque estas son un poco.. “sucias”.

Es por tanto que lo lógico es que encontrásemos mayores diferencias en Firefox, Chrome, Opera y Safari respecto a la comparativa pasada, ya que los resultados de IE9 a penas deberían de verse movidos.

Por tercera vez, la versión de Safari instalada está exenta de QuickTime por las razones ya explicadas en otras comparaciones. QT actúa de plugin para Safari para dotarlo de mayores prestaciones,  y por tanto este debe de ser suprimido. En la comparativa, se usan perfiles limpios, instalaciones limpias, sin complementos sin añadidos. De lo contrario podríamos instalar extensiones y complementos en Firefox o Chrome para obtener mejores resultados en los test de compatibilidades, y evidentemente no se trata de esto. Además, en esta ocasión se han añadido comparativas de consumo de RAM, CPU/GPU y energía, todos los cuales pueden verse muy afectados por complementos o extensiones de cualquier tipo. El único complemento que será instalado en todos los navegadores será Flash Player 11 b2 por cuestiones de necesidad.

 

Que Comparar

Esta no es la primera comparación de navegadores que se hace evidentemente, pero si en su día hice la primera, después la segunda y ahora la tercera, es porque la mayoría de todas las comparativas que he visto se ciñen tan solo a aspectos concretos del navegador. Unos tan solo hacen comparativas según el resultado de un test sintético, otros tan solo en un subconjunto de ellos. Incluso cuando se pudiesen hacer test para cada una de las partes de un navegador, existen otras cuestiones a valorar, como la compatiblidad, estabilidad, consumo de recursos… y por supuesto los “extras” que hacen del navegador la cara más visible del usuario en Internet: Extensiones, temas, sincronización, aplicaciones…

Evidentemente este no es más que otra comparatiba más. Posiblemente pueda aparecer alguien y decir que no soy riguroso por el número de test empleados en cada apartado, o que podría haber puntuado mejor de otro modo, o que no he tenido en cuenta otros parámetros o que… y de ya les digo que tienen toda la razón del mundo. Por riguroso que uno quiera ser, es evidente que en este mundillo es muy complicado cubrir absolutamente TODOS los puntos.

En esta ocasión se ha añadido el consumo de RAM y los tiempos de inicio en frío, amen de algunos test más. Por supuesto aun quedan cuestiones interesante que se comentarán en la conclusión, pero que posiblemente podamos incluir en futuras entregas, como por ejemplo el porcentaje de tiempo que cada núcleo pasa en estado C3 o más profundo.

 

 

Benchmark

En esta ocasión se han ampliado los test ejecutados, y se han unificado algunas gráficas A algunas de ellas se le incluirán la carga promedia de la CPU y GPU con idea de poder comparar también la eficiencia de cada navegador, cuestión que repercutirá a fin de cuenta en el consumo energético, esencial para dispositivos portátiles.

El consumo de RAM en contrapartida será comparado con test específicos, forzando a los navegadores a abrir primero 10 pestañas, para pasar luego a duplicar cada una de ella para obtener 20 pestañas en total. Por supuesto todos los navegadores abrirán las mismas, y también se verificará la estabilidad del navegador ante tal carga. Evidentemente se tendrán en cuenta TODOS los procesos dependientes de navegador, en el caso de Chrome todos los procesos chrome, en caso de Firefox plugins-container además del proceso principal, en caso de Safari…  Para las 10 Web usadas (duplicadas para el test de 20 pestañas) se han usado webs típicas que podría tener cualquier usuario a día de hoy: Bandeja de entrada de Gmail, Google Plus, Facebook, YouTube con un video de 320×240 cargado entero, la portada de DevianArt, la web del diario “El PAIS”, la Web del Marca, la bandeja de entrada de Windows Live Hotmail, la Web del Market de Android y la Web de la NASA.

La comparativa de tiempos de inicio serán contados siempre en un arranque en frío del equipo y abriendo por defecto la web de google: http://www.google.es.

Los resultados obtenidos por Peacekeeper (el total), ha sido modificado para incluir en él el peso de la sección de “Gráficos Complejos”. Cuando apareció Peacekeeper, no todos los navegadores soportaban Canvas (función de HTML5), y por tanto se decidió no incluir esta sección para la puntuación final, así especifica el propio Peacekeeper cuando está ejecutando dicha sección del test. Dicho esto, dado que absolutamente todos los navegadores soportan perfectamente esta función, la puntuación total de Peacekeeper será la media aritmética de las 6 secciones de este test.

Cada prueba puntuará de 1 a 5 cada navegador en función del resultado obtenido (1 para el navegador peor, 5 para el mejor), con el fin de poder hacer un “orden” de dichos navegadores al finalizar en función del número de puntos acumulados. Las versiones de 64 bits (Firefox e Internet Explorer) no contarán a la hora de puntuar para el resultado final, y se usarán tan solo como referencia. En caso de existir un empate, ambos obtendrán la misma puntuación.

Y como siempre, absolutamente todos los resultados serán ejecutados siempre en el mismo equipo, con instalaciones limpias de todos ellos, con el equipo reiniciado y haciendo el promedio de 3 ejecuciones de cada uno de los test/pruebas.

 

Sistema:

  • OS: Windows 7 Ultimate x64 SP1
  • CPU: Intel Core i7 920
  • RAM: 12GB DDR3 Triple canal
  • Video: nVidia GTX460 (Driver 280.26)
  • Resolución: 1920 x 1080, el navegador siempre maximizado

Navegadores:

 

Test:

  • Recursos
    • Tiempo de Inicio
    • RAM (10 y 20 páginas)
    • CPU/GPU reproduciendo contenido Full HD

 

 

Tiempo de Inicio

Una de las primeras sorpresas (negativa) ha sido sin duda alguna Chrome y Safari, que quedan relegadas a la penúltima y última posición respectivamente. Habría que determinar si esto es debido a Superfetch, aunque viendo los números obtenidos más adelante en cuanto a consumo RAM y comparándolos respecto a Opera, los resultados son interesantes

 

 

Consumo de RAM

Durante mucho tiempo se ha criticado duramente a Mozilla por el gran consumo de RAM de Firefox, lo curioso es que tanto en la prueba de 10 pestañas como en la de 20 pestañas, vemos que Firefox obtiene la segunda posición, mientras que Chrome queda relegada a último lugar (si quitamos las versiones de 64 bits). También es cierto no obstante que tanto Chrome como Internet Explorer usan procesos múltiples para mejorar el rendimiento y estabilidad, y ello conlleva un mayor consumo de RAM también

  • En ambos test, Safari provoca que su proceso” webkit2webprocess.exe” provoque una carga de la CPU de  17%-19%
  • En ambos test, en Safari es necesario refrescar algunas pestañas hasta 3 veces para poder visualizar la web

 

Video 1080p

Una cuestión interesante es la reproducción de contenido en HD a través del navegador, un buen identificador del consumo energético del equipo. Cuanto menor uso de CPU/GPU tenga el navegador, menor consumo energético estará teniendo, importantísimo en dispositivos portátiles. Por ahí he visto comparativas usando por un lado videos en Flash y por otro lado vídeos usando HTML5… el problema de este sistema es que los navegadores usan codec diferentes para esto (H264, WebM), lo cual implicaría realizar las pruebas con vídeos codificados de forma distinta. Es decir, no son una medida válida para comprar el rendimiento. Tan solo se puede comparar cuando es lo mismo. En caso de un vídeo en Flash es más sencillo, puesto que el vídeo usado en la comparación es siempre el mismo, en este caso el vídeo oficial en YouTube de “We are the World” con motivo de Haiti, en 1080p.

 

 

SunSpider

Un clásico de los Benchmark para medir el rendimiento en JavaScript del navegador. No obstante, debido al gran salto cualitativo de los navegadores en este aspecto, SunSpider ha ido perdiendo “valor” a favor de otros test, y también por no escenificar la “vida real” que tendrá después un navegador. Por otro lado, los márgenes se han vuelto sumamente pequeños entre los diferentes navegadores, por poner un ejemplo IE posee el mejor tiempo con tan solo 209 ms, pero lo distancia de Firefox por 4 ms.

 

 

V8

 Google se percató que SunSpider (creado por Apple principalmente) dejaba de ser un test “vistoso” de cara a la competencia, a fin de cuenta las diferencia entre navegadores son como mucho de unas decenas de milisegundos. Así se creó V8, un test para medir a priori el rendimiento del motor JS de Chrome, que también se llama V8. El problema con V8 es que es muy dependiente de Google, es decir, es un test sintético creado fundamentalmente para Chrome, lo cual hace que Chrome reviente literalmente a sus competidores. No obstante, no deja de ser un test más, interesante también porque pone en evidencia tanto los mejores puntos de algunos navegadores como los peores.

 

Kraken

En respuesta a V8 de Google, Mozilla tomó el estilo y alguno de los test de SunSpider y creó un test sintético mucho más riguroso que SunSpider, y por supuesto mucho más “real” de cara a la navegación de los usuarios. Por supuesto es todo subjetivo, pero si es cierto que Kraken es otro de los test de obligado paso para poner a prueba los motores JS de los navegadores

 

JSNES

Con la llegada de HTML5 y los cada vez más potentes motores JS (o al menos según lo que indicaban los test sintéticos), se abría la puerta a la creación de infinidad de aplicaciones y juegos de todo tipo que hacían un uso extensivo de JS. Anteriormente esto habría sido de todos modos imposible, dado el pobre rendimiento que se tendría… pero a día de hoy esto ya tampoco es una excusa. Así lo demostró el emulador de SNES creado en JavaScript

  • Tanto Safari como Internet Explorer aunque obtienen aparentemente buenos resultados, SALTAN frames, lo que produce que el juego de saltos constantes aun cuando trabaja a 54-56 fps. Un antiguo truco para obtener un framerate superior al que pueden manejar en realidad

 

Biolab

Un excelente ejemplo de lo que es capaz de hacer JS en conjunción de HTML5 gracias a Canvas. No obstante, aunque sin duda alguna es un gran ejemplo, prácticamente todos los navegadores han llegado a la cima de este test, y por tanto el test deja de ser útil. Así pues, esta será la última vez que veamos Biolab en acción, el cual será sustituido posiblemente por una aplicación de representación del ADN que me ha gustado mucho.

 

  • Safari no puede cargar el juego, no es compatible por alguna razón

 

 

Asteroids

 Un test que se hizo relativamente famoso por ser un “Firefox Killer”. Pero esta misma característica lo hace interesante desde el punto de vista de los propios programadores y desarrolladores, que permiten intentar pulir aquellas partes de rendimiento donde más sufren sus navegadores. Aunque hace uso de la aceleración hardware, es mucho más dependiente del código JS que ejecuta.

 

Normal Mapped Photos

Un nuevo test para mostrar la eficiencia de JS y HTML5 del navegador. En este caso no es un juego, sino una aplicación, y pese a lo que aparenta, no es un test para comprobar la capacidad gráfica del navegador, sino de JS. Es muy interesante de cara a los resultados obtenidos, puesto que cambia la tendencia de que Chrome aparenta ser el más rapido en JS o IE en cuanto a gestión gráfica. Podríamos pensar que los resultados dependen en gran medida del soporte hardware para la aceleración gráfica, pero IE que es la estrella en ello queda muy por detrás de Firefox o Chrome, este último que posee un rendimiento muy pobre en la aceleración por hardware en comparación con Firefox o IE

 

Peacekeeper

Es un test sintético que mezcla varios elementos, parte JS, parte manejo de cadenas, parte gráficos, parte objetos DOM. En esencia es un test bastante interesante porque intenta dar una perspectiva general del rendimiento del navegador. En contrapartida, ha sido un test muy criticado por explotar con fines mediáticos la fortaleza y debilidades de los navegadores. Pero de nuevo, no deja de ser un buen indicador. Interesante sin duda alguna es la puntuación en este caso de Opera, que obtendría la primera posición. Podemos decir que prácticamente todos los navegadores tienen su “test” ideal.

 

Tanque de peces (2000 peces)

El test original de Microsoft usa un máximo de 1000 peces. Lo bueno de este tipo de test es que es fácilmente escalable, y dado que 1000 paces no son un indicativo muy bueno (algunos de los navegadores llegan fácilmente a los 60 fps), se hace que el test represente 2000 peces. Con 2000 peces, este test hace buen uso de las capacidades gráficas del navegador y de la aceleración por hardware de este, tanto para la composición como para la renderización. Con la incorporación del uso de la CPU/GPU podemos ver además la eficiencia

 

 

“Come-Cocos” (Browse Hunt)

Siendo teóricamente un test fuertemente gráfico, deja de manifiesto problemas de rendimiento de algunos navegadores que incluso poseen aceleración por hardware como pueda ser Firefox. Mientras que Internet Explorer x64 logra el tope de los 60 fps, el resto de navegadores se encuentran muy lejos de lograr tal azaña.

 

 

 

 “Letras” (SpeedReading)

Uno de mis test favoritos para medir el rendimiento puro y duro de la aceleración por hardware de contenido del navegador. Este test deja bien claro que navegador posee aceleración por hardware de contenido, quien no y quien la implementa mejor

 

  • La versión de 64 bits de Firefox no ha aparecido pro alguna extraña razón. Los resultados eran: 6 segundos, 2% CPU y 22% GPU

 

Psicodélico

Otro buen ejemplo de lo importante que puede resultar la aceleración por hardware en el navegador. Aunque este test en particular es de Microsoft, Mozilla tiene otro muy similar, y otros tantos existen por al web

 

 Webvizbench

Nuevo test introducido en esta edición. En este caso se trata de un benchmark dependiente sobre todo de la aceleración hardware de composición (no de contenido. De composición siempre influye menos), pero un fuerte componente JavaScript. Ninguno de los navegadores es capaz de mantener un framerate de 60 (recordemos que estamos siempre en 1080p). Este benchmark es interesante porque muestra como el navegador es capaz de aplicar diferentes efectos CSS, superposiciones rápidas de imágenes, transiciones…

 

 Pecera (1500 peces)

Benchmark parecido al tanque de peces, pero usa un modelo diferente a la hora de mostrar los peces en pantalla. Es más escalabre y hasta hace poco era otro test famoso por ser otro “Firefox Killer”, la paradoja es que ahora es al contrario. Este test hace uso extensivo tanto de la aceleración hardware de composición como de conteido.

 

 

“Campo de Pruebas” (Field Test)

 Es el único benchmark actualmente para WebGL, pero también es cierto que actualmente tan solo Chrome y Firefox son compatibles con esta tecnología, lo que hace un poco absurdo sobrecargar la comparativa con más test WebGL. En la medida que el soporte WebGL crezca (tanto Opera como Internet Explorer están trabajando en ello) será más interesante ver como luchan en otros test. Aun así es útil para comparar la mejora de rendimiento entre las versiones de los mismos navegadores, por ejemplo el resultado obtenido con Firefox 4 Vs Firefox 9 (ya que Chrome mantiene los 60 fps). Es importante también mirar la carga de la CPU y la GPU.

  • El test parece establecer un framerate máximo de 60 fps, pero por alguna extraña cuestión Firefox anula dicho límite. Se tomará en cuenta como 60 fps a fin de cuentas.

 

Test de compatibilidad HTML5 de Niels y WebGL de Khronos

Como ya se ha dicho otras veces, no solo de velocidad vive el hombre, y es necesario que un buen navegador cumpla con los estándares más actuales, incluso muchos de ellos que aun no serán oficiales hasta dentro de unos años, como es el caso de HTML5. En contrapartida, WebGL es una especificación ya oficial, y Khronos (la misma organización que gestiona/crea/encargada de OpenGL/WebGL/WebCL…) tiene su propio test de compatibilidad con WebGL.

El test de compatibilidad de Niels es bastante riguroso e interesante, y es usado en muchísimas comparativas para decidir si X navegador es más compatible que Y. Pero ojo, Niels tan solo mira por HTML5!! HTML5 no es el único estándar emergente, y por ello usaremos más adelante la suite de Microsoft para completar los test de compatibilidad

 

  •  El test de Niels se basa actualmente sobre 450 puntos máximos.
  • El test de Khronos completo son unos 7400 pruebas diferentes a pasar.

 

IE Center Testing

Este site de Microsoft nos muestra una tabla con los resultados que estos han obtenido supuestamente con los navegadores de la competencia. Hacen lo mismo que he hecho yo, solo que ellos tan solo comparan las versiones de los navegadores que les interesa. Por ejemplo, actualmente si accedemos al site veremos que es Firefox 6.0, Chrome 12, Safari 5.0.5 y Opera 11.11 los navegadores testeados, y los enfrenta todos ellos con IE10 preview. En cambio las versiones en desarrollo que estamos viendo son mucho más actuales, y de ahí la necesidad de volver a pasar todos los test de Microsoft (Y creerme, es un trabajo). Es paradójico, pero aquí se suprime IE 10 por las razones expuestas (no existe una beta o una versión Alpha que sea un navegador realmente)

 

 

Conclusiones

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

Resultados Firefox 9.0a x86 Chrome 15.0.865.0 IE 9 x86 Opera 12 (B1047) Safari 5.1
Inicio en Frío 4 2 5 3 1
Consumo de RAM 4 1 2 5 3
Reproducción Vídeo HD 4 2 5 3 1
SunSpider 4 3 5 2 1
V8 4 5 1 3 2
Kraken 4 5 1 3 2
JSNES 4 5 3 1 2
Biolab 5 5 3 4 2
Asteroids 2 4 5 1 3
Normal Mapped Photos 5 4 3 1 2
Peacekeeper 3 4 2 5 1
Taque de Peces 5 3 4 2 1
Come-Cocos 3 4 5 1 2
SpeedReading 5 3 4 2 1
Psicodélico 5 3 4 2 1
Webvizbench 4 3 5 2 1
Pecera 5 3 4 2 1
Campo de Pruebas 5 5 4 4 4
HTML5 y WebGL 4 5 1 3 2
IE Testing Center 5 4 3 1 2
Total: 84 73 69 50 35

 

 

  • Recursos

    Este era un apartado clave de esta comparativa. Cada día queremos más y más, pero no nos preguntamos el coste que esto posee. Esto lo hemos visto totalmente claro por ejemplo en el consumo de RAM, en el tiempo de inicio del navegador e incluso en muchos de los test en los que se incluía el consumo de CPU/GPU que tenían.

    Respecto al consumo de RAM los datos han sido reveladores. Opera ha sido el menos pesado y con un tiempo de apertura bastante decente, que aunque no llega a ser el mejor no se encuentra muy lejos. Incluso con 20 pestañas abiertas no muestra una carga en RAM excesiva. Firefox ha obtenido sorprendentemente un segundo lugar!! y esto es sorprendente porque existe el rumor muy extendido de que Firefox es el agujero negro del consumo de la RAM… con esto queda bastante claro que esto no es cierto, o al menos no es cierto del todo. Firefox es cierto que posee un consumo muy grande de RAM… cuando se usan montones de extensiones, al igual que le pasaría a cualquier navegador. Lo que sucede es que el usuario de Firefox suele tener infinitamente más extensiones y complementos que cualquier otro usuario de otros navegadores, bien porque no existen dichas herramientas o bien porque no las usan.

    Pero si Firefox ha sido la sorpresa por tener un segundo puesto, Chrome ha sido la oveja negra sin duda en este aspecto. Quitando las versiones de 64 bits, Chrome se lleva la palma en consumo de RAM, llegando prácticamente a los 2GB de RAM para 20 pestañas, y casi 1.1GB solo para 10. Evidentemente no significa que el usuario tenga que tener constantemente 20 pestañas abiertas, por supuesto, pero recordemos que aquí estamos ante perfiles limpios!! Imaginar que tenemos solo 5 pestañas pero unos cuantos complementos instalados… 2GB para 20 pestañas no es muy aceptable, cuando Opera abre las mismas 20 con tan solo la mitad de RAM.

    Chrome no solo se lleva la peor parte en cuanto a RAM, sino que también en cuento a uso de la CPU. En prácticamente todos los test, Chrome usa sensiblemente más CPU que el resto de los navegadores, que no sobrepasan el 13%. Esto en parte se entiende porque mi sistema posee 8 nucleos lógicos, 100/8 = 13 aprox. El problema es que al poseer un mayor uso de la CPU, consumirá sensiblemente más energía, que en un portátil se traduce en minutos de uso.

    El consumo de la GPU en el caso de IE, Firefox y Chrome es más o menos similar. Si es cierto que el uso de la GPU en Firefox es en algunas ocasiones algo más elevado que el resto de la competencia, lo cual por supuesto también repercute en un mayor consumo energético.

    Con todo esto podríamos decir que Chrome sería el navegador menos eficiente de todos, y que IE9 posiblemente el más eficiente.

     

  • Estabilidad

    Si bien es cierto que la última comparativa no estuvo exenta de problemas con los navegadores, en este caso todos los navegadores se han portado más o menos bien. No ha existido ningún cierre inesperado, error o problema de ningún tipo quitando un par de excepciones con Safari.

    La primera ha sido a la hora de abrir 10/20 pestañas en el navegador, lo que produjo de pronto un uso constante de 13-17% de la CPU (cuando lo normal sería 0%). A esto se le unía la necesidad de tener que actualizar reiteradamente algunas de las pestañas abiertas puesto que no se lograba visualizar el contenido.

    La segunda ha sido de nuevo al intentar de ejecutar Biolab, por alguna extraña razón no es posible, quizás por la falta de ¿QuickTime?

 

  • JavaScript

    Todos los navegadores han mejorado su rendimiento JS con respecto a la comparativa anterior. Quizás los dos cambios más sustanciales han sido por un lado el de Chrome respecto a Kraken, en el que ha reducido algo más de 3000 milisengundos!! y por otro lado Firefox en V8, que se ha visto aumentado unos 2000 puntos.

    Por supuesto, estos cambios no solo tienen repercusiones en los test sintéticos. Como se aprecia todos obtienen mejores resultados en los test sintéticos, pero esto se puede observar más adelante en las aplicaciones/juegos. Ejemplo de ello es Biolab, en el que prácticamente todos los navegadores obtienen un rendimiento perfecto.

    Una vez más y como era de esperar dado que IE9 no ha sufrido cambios sustanciales, la versión de 64 bits de este parece no tener habilitado el nuevo motor JS de Microsoft, lo que hace como vemos que su rendimiento quede a años luz del resto, obteniendo en cualquier test que sea muy dependiente de JS la última posición.

    Respecto a JSNES hay que decir que una vez más aunque Safari e IE9 obtienen un frame rate razonable, este es totalmente injugable debido a que etos navegadores saltan frames. Esto hace que en vez de ir lento (que sería lo esperado cuando se tiene un framerate bajo) experimente saltos constantes. Es una “trampa” para apuntar un alto FPS, pero el juego es totalmente imposible.

     

  • Gráficos

    Aunque sin duda alguna los ganadores han sido tanto IE9 como Firefox, la mayor sorpresa ha sido Chrome, que ha irrumpido por fin con soporte hardware para su navegador. Es cierto que el soporte que este posee no es comparable ni mucho menos al ya demostrado por IE9 o Firefox 9.0, pero es evidente que incluso con la implementación que tienen actualmente es infinitamente superior a Safari y Opera.

    Actualmente existe una versión de prueba de Opera con soporte hardware completo que apareció en Febrero. Desgraciadamente no solo se trata de una versión antigua de Opera, sino que además resultó ser totalmente un fracaso en cuanto estabilidad, errores, rendimiento… Esto no quiere decir que sea malo, y estoy seguro que pronto tendremos una nueva versión con soporte hardware mucho más madura. Sobre Safari no puedo decir nada, actualmente no posee soporte para hardware ni hay pensamiento de incluirlo, al menos de momento.

    Mozilla por su parte tampoco ha estado con los brazos cruzados, y se puede ver un incremento sustancial en los aspectos gráficos del navegador. Si Firefox 4.0 llegó a 37 fps en el campo de pruebas por ejemplo, ahora llega sin problema alguno a superar los 60 fps. Que no sea tan sustancial como de nada a todo no significa que incrementos de 20-50% del rendimiento sea poca cosa. No obstante Chrome si posee en WebGL una característica que Firefox no tiene implementada actualmente (aunque está de camino), que es Antialiasing en WebGL, lo que aumenta considerablemente la calidad de las figuras presentadas.

  • Estándares

    Todos los navegadores como era de esperar han mejorado sus compatibilidades. Para empezar, el propio test de Nielsen ha pasado ha puntuar ya sobre 450 puntos (creo que en la anterior era sobre 300), con lo que implica que se han introducido más test y actualizado otros.

    Respecto a WebGL, tanto Firefox como Chrome han aumentado considerablemente el soporte para este, llegando prácticamente a alcanzar la confiabilidad del 100%, siendo Chrome algo más competitivo que Firefox. Microsoft ya advirtió que WebGL aunque es un buen estándar sufre de problemas de seguridad, los cuales por supuesto se han tenido en cuenta por Google o Mozilla. Queda aun por ver si Microsoft se decidirá por incluir WebGL en IE10 o si por le contrario tendremos que esperara a un IE 11. Opera en contrapartida, su navegador con soporte hardware que comentábamos en el punto anterior era compatible con WebGL. Esto quiere decir que es solo cuestión de tiempo para que aparezca el soporte para su navegador, aunque sí hay que decir que llegan tarde. Apple por su parte comienza a añadir poco a poco algunas piezas de WebGL en las build de WebKit, pero aun muy preliminar y tan solo para MAC OS

    En cuanto al IE test center, Chrome se ha quedado esta vez muy cerca de Firefox, aunque posiblemente en cuanto aparezca la beta de IE 10 los chicos de Microsoft actualicen de nuevo el IE test center con montones de nuevos test no compatibles para el resto de los navegadores… a fin de cuenta es evidente que dicho site aparece precisamente para IE.

    Otra función interesante que ya tenemos tanto en IE, en Chrome y en Firefox es Web Timming, que permitirá medir prácticamente todos los tiempos de una web. Pero de esto se hablará en otro momento, por ahora decir que en el mundo de los navegadores nadie se está quieto.

 

  • Compilaciones x64

    En general podemos decir que el soporte x64 para Firefox está empezando a ser casi a la par que su versión de 32 bits. Si es cierto que el motor JS no está optimizado totalmente para 64 bits, vemos pocas diferencias. En todos los test prácticamente la versiond e 32 bits de Firefox está pegada a la versión de 64 bits, siendo a veces una la mejor, siendo otras veces la otra. En general, el rendimiento JS de la versión de 64 bits es aun algo inferior, pero suele tener un mayor rendimiento en gráficos.

    Por parte de IE el panorama es muy diferente. De nuevo la versión de 64 bits de Microsoft es un desastre en tanto y cuanto JS se refiere, o al menos en comparación con su versión de 32 bits. Gráficamente es algo mejor generalmente, pero si bien la versión de 64 bits de Firefox sería a día de hoy estable y muy a la par que su versión de 32 bits (se espera que con el tiempo la versión de 64 bits sea más rápida), en caso de IE9 no sale muy “rentable” hacer uso de la versión de 64 bits.

Google+

Empecemos con Google+ (Google Plus)

 

Nota: Antes de comenzar, y para evitar comentarios y comentarios de “Quiero invitación, quiero invitación”, evidentemente no tengo problema alguno de mandar invitaciones a nadie. Al poner el comentario tienes que escribir el correo, correo que evidentemente yo si veo, con lo que no publiquéis el correo en los comentarios. Como digo no tengo problemas con ello, pero aconsejaría a leer el artículo primero para saber como funciona realmente el tema de las invitaciones. Por descontado queda que cualquier comentario absurdo referente a que las invitaciones no llegan por el motivo que sea (ya sea por Google ya sea porque no tengo tiempo o no me apetece), si podéis omitirlos, mejor:

 

Increíblemente, en tan solo 9 días que lleva Google+ como servicio de pruebas de Google, ha logrado en los 9 días acaparar  prácticamente todas las noticias sobre tecnología e Internet que han estado circulando. A día de hoy, tan solo 10 días después de su lanzamiento en pruebas (y por tanto tan solo disponible para algunos), rara es la persona que no sabe que es Google+ o no ha escuchado nada de ello al respecto.

Google+ es básicamente una nueva red social al estilo Facebook, con algunos elementos comunes a ella evidentemente y otros bien diferentes. Algunos auguran que será la red social que desplace a Facebook (tal y como esta hizo anteriormente con My Spaces), otros que será Twitter el que peor salga parado de ello, otros que convivirá en perfecta armonía con el resto de servicios que ya disponemos y una minoría que fracasará. Lo que sí ha quedado patente es la gran crítica positiva que ha tenido y está teniendo por parte de todos los usuarios que ya han probado Google+. Hay que dejar claro que actualmente Google+ está aun en fase de desarrollo, con esto no digo sólo que aun estén mejorando el servicio del mismo modo que Facebook añade más cosillas, sino que aun puede encontrarse de cuando en cuando algún comportamiento erróneo/errático, o funcionas que aun no tiene por qué estar definidas al 100%, y por ello son susceptibles a ser modificadas/cambiadas/eliminadas si así se estima. El lado positivo de ello por el contrario, es que Google está teniendo un contacto muy cercano con el usuario y sus sugerencias.

Todo esto no quiere decir que Google+ sea actualmente una red tan solo para probar y experimentar, nada más lejos!! Que aun se encuentre en desarrollo y no esté abierta a todos son más cuestiones de prevención. Si Google lanzase el servicio mañana mismo estoy seguro que aparecerían problemas como en cualquier cosa, y la prensa y la crítica los machacaría por sacar al mercado un producto de baja calidad. En cambio, con los sistemas de control que impone garantiza que en unas semanas Google+ esté suficientemente testeado y puesto a prueba como para pasar a producción y abrir las puertas. Pero de que tipo de medidas hablamos? Que tipo de control está ahora mismo imponiendo Google?

Cuando sacas un servicio que auguras tendrá un éxito considerable, necesitas tener el producto en pruebas privadas por largo tiempo. Se ha sabido por ejemplo que Google+ lleva en fase experimental no 10 días ni mucho menos, sino que Google+ llevaría ya algo así como un año en pruebas. Esto es comprensible como hemos dicho. Una vez que crees que el servicio está lo suficientemente maduro como para probarlo en un entorno real realmente, tampoco puedes abrir las puertas tal cual. Puede que Google+ haya estado a lo mejor un año en pruebas, pero con cuantos testeadores? La siguiente etapa por tanto es someter Google+ a un entorno real, con uso real, con cientos de miles de personas de todo el mundo interactuando con él. Y así se ha hecho. Google dio a conocer su red el día 28 de Junio, tan solo por invitación exclusiva de ellos, aunque unos días después fue posible por medio de pequeños hack el lograr que otros usuarios pudiesen invitar a terceros. Esto produjo un efecto en cascada tan impresionante que Google se vio forzado a cerrar de forma temporal todo tipo de alta nueva en Google+, teniendo invitación y sin tenerla.

En Internet, no hay nada que más atraiga la atención que un producto que se perfila de momento como exclusivo, y de ahí el gran efecto mediático que ha tenido, por supuesto a parte del gran éxito en sí que es Google+. La cosa llegó a tal extremo que se vendían inivitacione para Google+ incluso en ebay!! y no son pocas las web y portales que prometían invitaciones a aquellos que enlazaran su web, que inundasen Twitter con enlaces a ellos etc etc etc. Y lo curioso es que durante todos estos días, tan solo hay que escribir en Twitter o Google “Google Plus” para hacerse una idea del efecto mediático que está teniendo.

Se ha dicho mucho sobre como lograr una invitación a Google+, pero ¿existe realmente algún sistema para acceder a él? Sí. Hay 3 formas reales de poder acceder a Google+, aunque también dicho usuario tendrá que reunir ciertos requisitos para ello, y ello tampoco garantiza el acceso a Google+:

  • Acceso por invitación directa de Google: Ya sea porque Google directamente desea que uses su servicio, ya sea porque el usuario se tomo la molestia de dejar el correo a Google con su deseo de acceder lo más prematuramente posible al servicio, para lo cual existe la siguiente web: Petición de invitación a Google
  • Acceso por invitación de otro usuario de Google+: Este es el sistema que más ampollas ha abierto, y que más ambiguo parece. En teoría, cualquier usuario de Google+ puede invitar a cualquier otro usuario que no esté en Google+. Al comienzo, cada usuario tenía 10 invitaciones que podía otorgar a quien quisiese, pero la avalancha que se produjo hizo que Google eliminase este método. Más tarde, se encontraron pequeños hack que permitían la invitación a terceros, el cual Google se vio obligado también a bloquear.Actualmente, Google ha remodelado el sistema de invitación y funciona de la siguiente manera. Sí, cualquier usuario dentro de Google+ puede “invitar” a cualquier otro usuario que no esté dado de alta en Google+. Para ello lo único que tiene que hacer es realizar cualquier publicación a cualquiera de sus círculos. Los usuarios de dicho círculo que no dispongan de Google+ recibirán una invitación casi al momento. No obstante, y esto es importante, dicha invitación no garantiza de modo alguno el acceso inmediato a Google+, tal y como dice el propio correo que llega al buzón de los usuarios: “Actualmente, el Proyecto Google+ está trabajando para resolver todos los pequeños fallos con un pequeño grupo de prueba. Si no puedes acceder a Google+, vuelve a consultarlo más adelante.” Es decir, si siguiendo el enlace de la invitación no accedemos, no implica que no estemos invitado o algo falle, de echo esto es LO NORMAL. Lo que sucede es que Google posiblemente tenga una cola de usuario a los cuales permite el acceso poco a poco. Es decir, la invitación es obligatoria ahora mismo, pero no implica que el tener una garantice el acceso inmediato. Lo mejor que se puede hacer en estos casos es probar suerte en otro momento con la misma invitación. Espero que esto quede claro:

  • Acceso una vez las puertas estén abiertas: Evidentemente, una vez el servicio esté habilitado completamente, cualquier usuario podrá acceder a Google+

 

No obstante, existen algunos requisitos que hay que cumplir antes de poder acceder a Google+, los cuales dan algunos dolores de cabezas también a algunos:

  • Obligado el disponer de una cuenta de Google: Evidentemente, es un servicio de Google, por tanto debemos de disponer una cuenta de ellos. Que por cierto, aquellos que aun se empeñan a usar Hotmail, Yahoo… sinceramente, al margen de Google+, es un buen momento de cambiar (por seguridad, versatilidad, herramientas…)
  • Obligado a tener un perfil público en Google: Google posee como sabe la mayoría un abanico enorme de servicios: Google Maps, Gmail, Picassa (dentro de un mes llamado Google Fotos)… y entre ellos un servicio llamado Google Profiles, el cual podemos acceder desde aquí: Google ProfilesBásicamente no es más que un pequeño retrato nuestro, nombre apellidos bla bla bla. Que el perfil sea público no significa que la información que en él aparece sea toda visible. Visible será nuestro nombre y apellidos, el resto es controlable por nosotros mismos. Evidentemente es obligado el tener un perfil Público de Google, puesto que este será parte de Google+.
  • Imposible con Google Apps: Actualmente, aun no es posible el acceso a Google+ por medio de Google Apps. Para quien no sepa que es Google Apps, digamos que es un paquete de servicios que Google pone de manera tanto gratuita como de pago (dependiendo del tipo de suscripción que se desee y su uso) a organizaciones, escuelas y empresas principalmente. Digamos que permite a una empresa con el uso de su dominio propio la creación y gestión de cuentas de usuarios para el acceso a los servicios de Google. Pues bien, actualmente Google Profiles no está disponible para Google Apps, y por tanto es imposible de momento el acceso a Google+. La buena noticia es que Google ya está más que al tanto de esto, y ya ha dicho que en poco tiempo estará el asunto solucionado también.
  • Empresas por ahora fuera: Google quiere dejar bien clara la diferencia entre una empresa o un perfil de una empresa al de un particular. Recordemos que en Facebook cualquiera puede crear un FB de la empresa, y usarlo como cualquier usuario. pues bien, Google quiere que se diferencie perfectamente lo que es un usaurio y lo que es una empresa. Por ello ya ha dicho que en Google+ no existirán empresas como usuarios. Por el contrario, deja también claro que dentro de unos meses tendrá lista digamos la presencia de las empresas en Google+. Es decir, si habrá empresas en Google+ evidentemente, pero por lo que se puede ver parece que tendrán un perfil bien diferenciado de los usuarios normales.

 

Google+ es nuevo, y tendrán que pasar unos meses para que se estabilice. Lo bueno es que conociendo a Google no dejarán de añadir mejoras que realmente mejoren la experiencia de los usuarios. Cada día que pasa se unen cientos y miles de usuarios nuevos a Google+, lo cual es perfecto para acelerar la apertura total al sistema, así que un poco de paciencia. No hay una fecha oficial de “apertura”, pero al ritmo que se lleva, es posible que el control de las invitaciones deje de ser tan riguroso para final de mes, y que sea un servicio completamente abierto para todos en un mes más o dos. Pero quien sabe… Google tiende a sorprender, así que…

Bueno, dejando todo ello al margen, hablemos un poco de lo que es y no es Google+, que está genial poder hablar de como acceder o de las medidas de control de Google, pero mejor es poder hablar de si es tan bueno como se pinta, si es útil o si realmente nos va a dar algo más que no teníamos. Lo cierto es que Google+ posee ciertos elementos que lo hacen a día de hoy bastante atractivo y único, otros como veremos son bastante similares a los que podemos encontrar en Facebook o Twitter. Veamos como funciona y sus puntos más interesantes:

 

Filosofía

Para mí al menos, este es el punto más importante de todos. Desde el primer día que usas Google+ comprendes que es cierto la diferente filosofía que Google+ y Facebook tienen con tratar los datos del usuario.

Para Facebook, ellos son los dueño y señores de TODO lo que publiques en Facebook. Así pues, no solo pueden retener tus datos por años para uso de terceros, sino que se pueden apropiar de ello. Es decir, si publicas una foto en facebook, le estás dando la propiedad de dicha foto a Facebook, y pasa a ser de domino público. Para Facebook como he dicho, tus datos, todo lo que almacenas en Facebook es de ellos.

Para Google+ (para Google) la filosofía es completamente opuesta. Todos los datos son siempre y por siempre del usuario, teniendo este siempre control total sobre estos. Es más, incluso permite realizar una copia de absolutamente TODOS los datos que contenga nuestra cuenta de Google+ (fotos, publicaciones, contactos, perfil…).

Esto evidentemente es una enorme diferencia ;). Si no queremos una foto, podemos acceder a Picasa y directamente eliminarla!! sin preocuparnos de nada más. La foto es nuestra, la compartimos cuando queremos y el tiempo que queramos, una vez eliminada está eliminada completamente, Google no guarda copia de ella (exceptuando las copias de seguridad temporales que se realizan claro)

 

Círculos

Google+ cambia por completo el concepto de “Amigo” que posee otras redes como pueda ser Facebook. Google emplea un sistema llamado círculos que permite independizar completamente un contacto con otros, organizándolos en grupos bien distinguidos. Se pueden tanto crear como eliminar Círculos sin problema alguno, y la la utilidad radica en que cada círculo puede ser completamente independiente del otro. Por defecto se crean 4 círculos: Familia, Amigos, Conocidos, Seguidor de. La idea es que tengamos a lo mejor un círculo con aquellos contactos que son familiares nuestros, otro para los amigos, otros para los conocidos… de este modo por ejemplo, cada vez que publicamos cualquier cosa en Google+, ya sea un comentario, foto, vídeo, enlace… podemos seleccionar directamente el/los círculos que podrán acceder y ver dicho contenido. Si marcamos así un comentario para la Familia, tan solo aquellos contactos en nuestro círculo de familia leerán en sus perfiles nuestro comentario, y ningún otro podrá acceder a nuestra publicación salvo dichos contactos.

Esto no solo dota a Google+ de un control muy superior en cuanto a lo que publicamos, sino que además nos permite Twittear al más puro estilo de Twitter, capacidad que FB no posee. Así, todos aquellos que tengamos en el círculo de “Seguidor de” podremos leer en nuestro perfil todo aquello que dichas personas hagan público, sin necesidad que nos tengan colocados a nosotros en ningún círculo. Es decir, es como cuando en Twitter decidimos seguir a una persona.

Por otro lado, es posible publicar de forma totalmente pública!! de modo que absolutamente todo el mundo, ya esté en Google+ o no podrá leer lo que pongamos allí. Esto en conjunción a la capacidad de “Twittear” con los círculos de seguidores es posiblemente el destructor directo de Twitter, aunque habrá que esperar mucho tiempo para ver como evoluciona realmente el asunto:

 

Intereses

Google+ añade una “pequeña” funcionalidad llamada Sparks (o intereses). Básicamente es un buscador automático e inteligente de los intereses que podemos tener, de modo que estos se añaden a nuestro Google+, de modo que una vez añadido el Spark específico, podremos acceder a él cuando queramos y ver las novedades que de él se obtienen. Es decir, es algo así como un pequeño menú que nos irá mostrando aquellos puntos de interés que tenemos y las noticias actuales referentes a ellos. Así por ejemplo si tecleamos “Android”, cuando accedamos a dicho Spark se nos mostrarán noticias actuales de Android

Para todos aquellos que les gusta simplemente cotillear o investigar es una buena opción, así como aquellas empresas que quieran promocionarse y hacer publicidad apareciendo en Spark, ya que por descontado presupongo que los resultados devueltos por Google dependerán en parte a sus socios.

 

Conversaciones en grupo

Google cuenta con una ventaja que no posee Facebook, y es la gran plataforma que tiene ya creada. Esto le permite integrar sin problema alguno una gran cantidad de servicios de forma simultánea. Huddles (o las conversaciones en grupos) es un ejemplo de ello. Gtalk existe desde hace mucho tiempo, y la posibilidad de entablar conversaciones en grupo con nuestros contactos no es tampoco ninguna novedad. Pues bien, si integramos todo ello en Google+ y por supuesto dispositivos portátiles (Por ahora tan solo Android), tenemos Huddle.

Con Hddle Google logra de nuevo un efecto demoledor a la competencia. Por un lado, amplia su servicio de Gtalk de forma considerable, añadiéndolo como servicio de mensajería/chat de Google+, sin necesidad de reinventar nada. Por otro lado automáticamente da a Google+ la posibilidad de mantener conversaciones con todos los usuarios que deseemos o círculos enteros si queremos. Recordemos que esto es imposible con Facebook.

Pero sin duda alguna, aquí el éxito está de nuevo en los terminales portátiles. Con Huddle, Google pone en jaque servicios como Whatapp y otros, solo que en este caso Huddle es completamente gratuito e igualmente universal. No es un programa para intercambiar datos sin embargo, como pueda ser Whatsapp (al menos por ahora), pero la función principal que es mantenernos en contacto con nuestros contactos, la cumple a la perfección, y además se aprovecha de la realización de grupos de conversación y del uso de los círculos de Google+. Por supuesto con sus notificaciones y alertas habituales en Android. Como ya he dicho, los usuarios de Android estarán igualmente contentos con este aporte, aunque se espera que en breve los usuarios de iPhone tengan a disposicion la aplicación Google+ en el Market, siempre y cuando Apple la apruebe, que está aun por ver:

 

Quedadas

Llamado Hangouts por Google, es sin duda alguna una de las capacidades estrella de Google+. Si ahora, 4 años después de Facebook es cuando estos implementan la vídeo llamada en FB, Google no solo la implementa desde ya, sino que supera con creces cualquier expectativa. “Quedadas”, no es un mero servicio de vídeo llamada con tus contactos, sino que permite algo que hasta ahora era impensable para prácticamente cualquier servicio de este tipo, y son las vídeo conferencias múltiples. Es decir, la posibilidad de mantener una vídeo conferencia a tres, cuatro, cinco… podremos mantener una vídeo llamada no solo con un contacto, sino habilitar una “sala” en la que incluso todo un círculo pueden hablarse, verse y oírse entre sí.

Evidentemente, cuantas más personas estén unidas a la llamada más recursos serán necesarios en nuestro equipo, y mayor será el ancho de banda requerido. No obstante, prácticamente la totalidad de equipos actuales serán más que capaces de gestionar una conversación de unos cuantos de contactos sin problema alguno. Ideal para hacer planes, compartir ideas o simplemente reunirse virtualmente. Sinceramente es de las mejores funcionalidades que podrían haber añadido, no solo es algo novedoso, sino que es sumamente útil.

 

Compartición de fotos, vídeos…

Google+ se perfila como un espacio más personal, o como Google lo llama, un espacio más semejante al día a día, un modo de compartir realmente la vida. Y en parte es cierto y lo está logrando. Parte de este éxito es también la facilidad para compartir cualquier tipo de contenido por nuestras cuentas.

Evidentemente todos hemos tratado con el sistema que posee FB para compartir una foto, un vídeo, un enlace… con nuestros contactos. Y no digo que sea un sistema malo, para nada, es un sistema excelente. Pues bien, el problema es que Google+ va aun más lejos. Por un lado, gracias de nuevo a sus círculos nos permite publicar cualquier tipo de contenido para un círculo/s concretos, sin preocuparnos ya si deseamos que un contacto tenga acceso a dicha foto por ejemplo o no.

Pero por otro lado, está el soporte Android de Google+ que sin duda es cuanto menos interesante. Cualquier teléfono Android con Google+ podrá configurar este (Google+) para que las fotos tomadas sean automáticamente subidas a Google+. Dicho de otro modo, salimos de fiesta y toamos unas cuantas fotos de los amigos, copas… pues bien, de forma automática, dichas fotos serán cargadas a nuestra cuenta paralelamente. No tendremos siquiera la necesidad de coger una foto, seleccionarla, marcarla para publicarla etc etc.

Por supuesto, las fotos serán por defecto subidas como privadas y no serán publicadas a menos que así lo deseemos, y publicadas por supuesto a aquellos círculos que deseemos. Además, dado que se toman desde teléfonos Android, la gran mayoría de las fotos tendrán incluida la información de geolocalización, la cual se usará también para especificar en la propia foto donde fueron tomadas.

Ni que decir tiene que todo es configurable. Podemos configurar el teléfono para que tan solo suba las fotos cuando dispongamos de WIFI, podemos decir que las suba inmediatamente, o simplemente que no las suba o que lo haga tan solo cuando el terminal está cargando.

 

Remodelación de la interfaz de Google

Inmediatamente después de que tengamos acceso a Google+, nuestra cuenta de Google cambia para adaptarse a este. Para empezar, la barra superior de nuestro navegador que nos da acceso rápido a nuestros servicios, contendrá sustanciales cambios. Aparecerá un servicio nuevo llamado +[Nuestro nombre]. En el lado derecho, aparecerá la foto de nuestro perfil al lado de nuestro nombre de sesión/correo electrónico. Igualmente si hacemos clic para extenderlo se nos mostrarán opciones de nuestros círculos, cuenta… además tendremos un pequeño recuadro que nos notificará con un número el número de nuevas notificaciones que tengamos en Google+ (al estilo de los numeritos de Facebook de notificaciones. También podremos compartir lo que sea de forma rápida desde la propia barra. Esta barra, es como sabemos visible desde cualquier servicio de Google que estemos visitando (o la gran mayoría de ellos)

Por otro lado, nuestra pagina habitual de configuración de Cuenta de Google cambia sustancialmente y es sustituida por un nuevo look, que si bien contiene exactamente las mismas herramientas, estas son presentadas de un modo más bonito, y por supuesto se nos presentan nuevas opciones, como la configuración de Google+ o el acceso al administrador de contenidos:

 

APIs para desarrolladores

Por último lugar pero no menos importante, es que Google está trabajando de forma intensa también para entregar una suite completa de herramientas para que terceros puedan crear sus aplicaciones, asociaciones, acceso… a Google+. Esto permitirá como es lógico el poder disponer por ejemplo de complementos para navegadores, blogs, aplicaciones… que permitan el acceso y puedan compartir información con nuestra cuenta, tal como hace Facebook o Twitter por ejemplo.

Es cierto que actualmente no existe esta API en el mercado, y por ello no es posible interactuar desde fuera de forma directa sobre Google+ si no es por medio de las herramientas de las que ya disponemos. De nuevo recordemos que Google+ está en fase de desarrollo, y aunque no tardaremos en ver esta API en la calle, aun no está terminada y/o publicada. Presumiblemente, cuando Google+ sea totalmente público, todo este tipo de cosillas estarán terminadas.

 

Sin duda alguna a Google+ aun le queda un largo camino si quiere hacerse un hueco real y significativo en las redes sociales. Sin embargo parece estar al menos más que capacitado para luchar de forma simultánea contra Twitter y Facebook. Por otro lado, Android será una piedra importante para Google a la hora de hacer realmente útil Google+, y sus servicios como Picasa (próximamente llamado Fotos), Youtube, Gmail… y tantos otros son siempre extras que nos permiten un mayor control de todo lo que podamos hacer y querer.Todo ello aderezado con una interfaz sencilla y bastante limpia.

Por supuesto, habrá que esperar meses, ver si las empresas se interesan en los perfiles empresariales, y más importante quizás, que los usuarios se movilicen y se muden poco a poco a Google+, ya que mantener hasta 4 redes sociales de forma simultánea puede llegar a ser un dolor de cabeza.

Lo que sí está claro, es que ahora mismo Google+ lo que más posee evidentemente es una comunidad de Geeks y personalidades del mundo de Internet, lo cual no es de extrañar ya que por ahora como hemos dicho es un servicio por invitación y no muy fácil de acceder… al menos por ahora.

Dicho esto, espero que nos veamos pronto en Google+. Un saludo amigos.

Comparativa Navegadores 2011: IE9, Firefox 4, Chrome 10, Safari 5, Opera 11

 

Índice

 

Versiones de los navegadores

Hoy, tras el lanzamiento de forma oficial de Internet Explorer 9 y el inminente Firefox 4, saco un hueco para rehacer la comparativa que realizamos hace 6 mese en la que tanto IE9 como Firefox 4 aun continuaban en fase de desarrollo. 6 Meses después tanto Microsoft como Mozilla lanzan de manera oficial sus navegadores (En el momento de escribir estas letras, Firefox se encuentra en fase RC1, con lo que es posible que la versión final oficial sea la misma que la usada en estos test).

Me hubiese gustado que a estas alturas Firefox 4 estuviese en la calle, pero para el caso de esta comparativa sinceramente importa poco, dado que en el caso de FF4, el desarrollo propiamente dicho ha finalizado, y a espera de encontrar un fallo de seguridad que sea importante, FF4 debería de ser oficialmente lanzado entre esta semana y la siguiente. Si bien podría esperar al lanzamiento de FF4 de forma oficial para publicar esta comparativa, dado el lanzamiento de IE9 y dado que FF4 no va a cambiar prácticamente entre la RC1 y la RTM, he decidido tomar la RC1 de FF4 como “oficial”. Hay que tener en cuenta también que a modo de “comparación” se ha incluido también la versión de 64 bits de Firefox a los test, la cual NO SERÁ LANZADA de manera oficial hasta la futura Firefox 5, la cual debería de llegar para mayor/abril.

Edito: Según la reunión de hoy, parece ser que la RC1 se convertirá en versión de oro (lanzada oficialmente) el día 22 de Marzo. Posiblemente esté disponible un poco antes, recordemos que hay que compilar de nuevo la RC1 como versión final, preparar todo el marketing, esperar si a última hora aparece algún problema… pero podemos casi afirmar con completa seguridad que la RC1 será en esencia la misma versión que Firefox 4.0 oficial.

Sobre el resto de los navegadores usados, en estos últimos 6 meses todos han ido sufriendo actualizaciones. Hasta el día de hoy, tanto Internet Explorer como Firefox y Safari tenían los ciclos de actualizaciones más altos, cosa que Microsoft como Mozilla han decidido aparcar y optar más por el modelo de Chrome, el cual es no esperar a grandes actualizaciones, sino que las propias funciones nuevas y las mejoras realizadas se van incorporando poco a poco. Esto tiene sus ventajas y sus inconvenientes. Pensar que en estos 6 meses, Firefox ha terminado el desarrollo de Firefox 4 (En septiembre estábamos en Beta 7 sino recuerdo mal). En cambio, Chrome ha pasado de la versión 6 a la versión 10, y la 11 en fase beta. Esto no quiere decir que Chrome tenga más personas trabajando o que sean más rápidos, lo que sucede es que entre Chrome 6 a Chrome 10 los cambios que han existido no han sido ni de lejos los que ha sufrido Firefox desde su versión 3.6 a la 4.0. Esto es aplicable igualmente a IE8 Vs IE9.

Opera y Safari también a mejorado sus navegadores, y si acudimos a las versiones testadas hace 6 meses veremos algunas mejoras en cada uno de ellos. Así que a diferencia de hace 6 meses en el que aun había muchos fallos que arreglar y rendimiento a ganar, hoy si podemos hablar de todas las versiones oficiales. En el futuro, si Microsoft como Mozilla optan por ciclos de actualizaciones cortos, intentaré publicar las comparativas a intervalos más o menos regulares

De nuevo, la versión de Safari instalada está exenta de QuickTime. Algunos podrían criticar dicha decisión dado que en algunos sistemas se obliga la instalación de QT en el PC para la descarga e instalación de Safari. No obstante, desde mi punto de vista aquí se está testeando navegadores, no reproductores multimedia. El problema que se presenta es que Apple usa QT como interfaz para la reproducción de elementos de este, entre otras cosas algunos de los elementos de HTML5. Ya en la otra ocasión establecí mi opinión sobre esto, y es que para realizar un test de Safari, QT debe de ser desinstalado. ¿Por qué? Es simple, del mismo modo que los otros navegadores cuando se testean no se instala ningún complemento que pueda darle un punto más o un punto menos en cualquier prueba, o hacerlo más compatible. Por poner un ejemplo práctico, Google tiene un programa por así decirlo que añade compatibilidad WebM a IE9, lo cual le daría a IE9 más puntuación en los test de compatibilidad para HTML5, o lo mismo se podría hacer para Firefox para añadirle soporte para H264. Aquí se juega limpio, y todos los navegadores están en las mismas condiciones, no hay complementos ni añadidos externos que puedan ayudar a ningún navegador, y si Safari está realizado así por diseño, mal pensado está, no tiene sentido que tengas que tener instalado QT por narices ya uses Safari o iTunes o…

 

Benchmark

Siguiendo más o menos el esquema de hace 6 meses, se han usado los mismos tests de entonces (o la actualización de estos) y se han añadido otros nuevos, para de nuevo intentar ser lo más rigurosos posibles y abarcar en todo lo posible cuantas más características tengamos entre manos. Evidentemente no voy a usar un simple test JS y con ello llegar a la conclusión que el navegador X es mejor que el resto. Veremos como en realidad todo es relativo, y tan solo con una mirada general a los datos recogidos se puede tener una idea más o menos clara de que navegador es mejor o peor. Ojo! Aquí tampoco están cubiertos todos los test que podrían ser interesantes, como por ejemplo el consumo de RAM, el tiempo de inicio en arranque en frío o el uso de CPU en los test, que si es posible estará incluido en la siguiente entrega.

Dado que los propios Test se han actualizado en este tiempo, no es posible comparar los resultados aquí obtenidos con los obtenidos hace 6 meses. Por ejemplo, en la anterior entrega se usaba el test V8 de Google versión 5, y en esta ocasión la versión 6 con lo que los datos de uno no pueden mezclarse con los otros.

Empecemos.

 

Sistema:

  • OS: Windows 7 Ultimate x64 SP1
  • CPU: Intel Core i7 920
  • RAM: 12GB DDR3 Triple canal
  • Video: nVidia GTX460 (Driver 267.24)

Navegadores:

Test:

 

 

 

 

  • IE 9 x86 no carga ninguna ROM, no es compatible

 

  • Safari no puede cargar el juego, no es compatible.

 

  • El test original permite un máximo de 1000 peces, fue modificado para permitir 2000 peces dado que tanto IE9 como Firefox 4 alcanzaban los 60 fps
  • En 1000 peces, el fps del resto de los navegadores era de 0-3 fps.
  • Tan solo IE9 y FF4 poseen aceleración hardware completa (DirectWrite/Direct2D y Direct3D 10)

 

 

  • Tan solo IE9 y FF4 poseen aceleración hardware completa (DirectWrite/Direct2D y Direct3D 10)

 

  • Tan solo IE9 y FF4 poseen aceleración hardware completa (DirectWrite/Direct2D y Direct3D 10)

 

  • Tan solo Chrome 10 y FF 4 poseen soporte WebGL

 

 

  • Las versiones de 64 bits poseen la misma compatibilidad que sus homólogas de 32 bits

 

  • Las versiones de 64 bits poseen la misma compatibilidad que sus homólogas de 32 bits

 

  • Tan solo Chrome 10 y FF 4 poseen soporte WebGL
  • Las versiones de 64 bits poseen la misma compatibilidad que sus homólogas de 32 bits

 

 

Conclusiones

  • JavaScriptDesde la pasada comparativa, las cosas han cambiado. Actualmente todos los navegadores parecen tener en general un rendimiento JS bastante competitivo, y cada día que pasa los test sintéticos para JS tienen menos valor y son más difíciles de cuantificar. Si partimos de todos los test JS mostrados y tuviésemos que obtener un resultado de forma global, posiblemente el ranking sería el orden: Firefox, Chrome, Opera, Sarari y por último IE.

    Pero estos test no solo nos sirven para llegar a esa posible conclusión, sino que nos podemos dar cuenta perfectamente de lo poco veraces que pueden resultar estos test. Vemos 2 cuestiones concretas en las que me gustaría detenerme unos segundos. En primer lugar tenemos que curiosamente los test realizados por cada desarrollador suelen dar de ganador a dicho desarrollador, menos en el caso de Apple. Por ejemplo, en V8 vemos que de forma clara Chrome prevalece por mucho al resto, mientras que Firefox lo hace en Kraken (la diferencia frente a Google era muy superior hace tan solo unas semanas con Chrome 9).

    El segundo aspecto cuanto menos curioso es que IE9 obtiene teóricamente el mejor resultado de todos en SunSpider, pero en contrapartida obtiene siempre el último puesto en todos los demás test JS. No conozco sinceramente el desarrollo de IE9 para poder afirmar o negar con rotundidad que MS ha hecho “trampas” de forma manifiesta, pero es evidente que es cuanto menos curioso. Estas trampas no son complicadas de hacer, simplemente si sabes como se ejecuta el test, puedes preparar de antemano el navegador para asegurarte que en dichos test y solo en esos tu navegador es el mejor. El problema es que cuando enfrentas IE9 en cualquier otro test los números hablan por si mismo. Este un es claro ejemplo de que jamás puedes fiarte de un test aislado, tan solo puedes tener una respuesta más o menos clara después de varios test de diferentes, es un poco como la regla de oro. También podemos ver que MS no ha realizado prácticamente ningún cambio a su versión de 64 bits, si vemos el rendimiento de este frente a su versión de 32 btis, es de pena, posiblemente la versión de 64 bits no haya migrado al nuevo motor JS, lo cual tendría también sentido en el emulador SNES, ya que mientras que la versión de 32 bits es incapaz de procesar el juego (posiblemente alguna incompatibilidad en el nuevo motor de MS) si lo hace el navegador de 64 bits.

    Es evidente que los programadores de los navegadores han estado trabajando duro para poder mejorar en lo imposible sus resultados JS, y como ya dije en otra ocasión, estos resultados pueden ser en el 99% ignorados por la mayoría, ya que en un entorno real rara vez veremos o podremos ver una diferencia clara. Es por ello que incluí dos juegos que usan de forma masiva JS, como por ejemplo el emulador de SNES, que hay que anotar que aunque Safari alcanzó 40fps, este resultó completamente injugable, mientras que

 

  • GráficosCopia de la comparativa anterior: “Con gráficos recordemos que nos referimos a cualquier contenido de este tipo, desde videos, imágenes, texto… casi cualquier elemento que sea procesador en el navegador. En realidad es tanto o más importante que JavaScript, en cambio esto parece que pasa desapercibido para la mayoría. En cuanto a Gráficos se refieres creo que nos encontramos con lo que podríamos llamar navegadores de primera generación: Chrome, Safari y Opera, y navegadores de segunda generación: IE, Firefox. Para aquellos que no hayan realizado test pertinentes o no estén puestos en la materia, podrían incluso creer que los resultados son erróneos, pero nada más lejos. Estos son debido en gran medida gracias a la Aceleración Hardware del navegador, que usa la tarjeta de vídeo del sistema como apoyo. El resultado no puede ser más increíble. El test de las letras, así como otros muchos no son aplicaciones o test necesariamente en 3D, muchas veces se cae en el error que la tarjeta de vídeo tan solo sabe renderizar polígonos en la pantalla. Chrome, aun cuando en la versión 7 ya poseía un soporte parcial para la aceleración por hardware, la verdad es que 6 meses después no ha cambiado mucho como podemos ver en los test, tan solo tiene un soporte parcial. Opera por otro lado esta trabajando en un soporte hardware completo, aunque por ahora tan solo se encuentra en las primeras fases. Safari que yo sepa no ha comenzado con ningún tipo de soporte hardware, ni para MAC OS ni para Windows.La Aceleración Hardware en los navegadores se ha logrado en dos partes. La primera es por medio de las API de Windows Vista y Windows 7, concretamente gracias a Direct2D y Direct Write, dos tecnologías creadas por Microsoft que permiten usar las tarjetas de vídeos basadas en DirectX10+ (y la mayoría de DirectX9c) para acelerar prácticamente cualquier aspecto gráfico de Windows. El éxito de esta tecnología es más que evidente, al igual que sus resultados. La segunda parte es bastante menos significativa, aunque igualmente ayuda en muchas tareas, como por ejemplo en la presentación de vídeos que están superpuestos sobre otros elementos o a los que se le aplican diversos efectos o web con diferentes capas y hojas de estilo. Esto es posible tanto a OpenGL como a DirectX9, y se le llama Aceleración Hardware de composición de capas. La ventaja de este sistema es que al funcionar sobre OpenGL podría ser usado tanto en Windows, Linux o MAC OS, mientras que para poder usar Direct2D/DirectWrite es necesario Windows Vista o Windows 7. Los dos sistemas son complementarios, uno no sustituye al otro, siendo sin duda alguna el más significativo el de Direct2D/DirectWrite.

    El secreto de los números anteriores es que tanto Internet Explorer 9 como Firefox 4 poseen ambas tecnologías en sus navegadores (en caso de Firefox en MAC OS/Linux tan solo podrá usarse evidentemente la aceleración hardware por capas, y en ninguna circunstancia se podrán beneficiar de D2D/DW). Chrome en sus últimas Builds de Chrome 11 ha comenzado a implementar la aceleración hardware de composición de capas, y dentro de esta tan solo una parte. Es decir, incluso en esas builds el soporte de aceleración de composición es pobre, y los resultados que se obtienen aunque mejoran las cifras actuales en la renderización, estan muy lejos de las cifras de IE o Firefox. Como dije, Opera ya se ha puesto manos a la obra, mientras que Safari casi con toda seguridad no lo haga. Por qué? Es simple, Safari es de Apple y Apple usa MAC OS, dudo mucho que Apple trabaje en una versión de Safari que sería muy superior a la versión de Safari para MAC OS. Una vez más vemos la importancia de un OS.

    Me gustaría aquí abrir un pequeño paréntesis. Tanto Microsoft como Opera ahora anuncian por todo lo alto que sus navegadores tienen (tendrán en el caso de Opera) un soporte por hardware total (es decir, tanto composición por capas como DW/D2D), lo gracioso es que insultan a Mozilla y a su Firefox 4 con que el navegador tan solo realiza una aceleración parcial. Bueno, esto es falso.

    La cabeza en este caso es para IE9 de nuevo, pero en esta ocasión tan solo por los pelos, actualmente el rendimiento de Firefox 4 frente a gráficos está muy a la par que el de IE9. No obstante también hay que alabar el trabajo de Mozilla, dado que es lógico que Microsoft (que fue quien creo la tecnología en cuestión) la use de forma más eficiente, sin olvidar que Firefox ya trabajaba con ella antes de que IE9 apareciese siquiera anunciado. Además, hay que aclarar algo, y es que de nuevo MS a veces hace “trampas” en sus test para inflarlos. El mejor ejemplo de esto es el test “Psicodélico”. MS usa un timeout de 4ms, mientras que por defecto actualmente Firefox 4 usa 10 ms. Cuando ambos navegadores usan 4 ms el resultado es prácticamente el mismo, pero lo que llama la atención es que si especificamos el timeout de Firefox 4 a 1, entonces Firefox 4 no ronda los 8000 puntos, sino los 30000 (si, treinta mil). Es solo un ejemplo absurdo de como hacer “trampas”. Para quien quiera saberlo, la propiedad de Firefox que controla el timeout se llama: “dom.min_timeout_value”

    En esta ocasión he decidido incluir el estándar WebGL, que permite usar especificaciones OpenGL para el navegador, es decir, la posibilidad de renderizar contenido 3D directamente en el navegador. El soporte WebGL no obstante creo recordar que es parte de HTML5 (ahora mismo no estoy seguro), y de todos los navegadores tan solo Firefox posee tanto aceleración hardware completa como soporte WebGL, con lo que los test serían un poco deprimentes para los demás. Hay que tener en cuenta que actualmente tan solo Firefox y Chrome son compatibles con WebGL. Los beneficios son claros, contenido 3D renderizado por nuestro adaptador gráfico gracias a OpenGL (en caso de Chrome por ANGLE (DirectX, en caso de Firefox por ANGLE o OpenGL nativo), el poder usar OpenGL nos abre un sin fin de posibilidades que de otro modo sería imposible, como por ejemplo juegos 3D, representaciones complejas y ricas de detalles… posiblemente uno de los ejemplos más llamativos de esto sea el cuerpo humano creado por Google:

    http://bodybrowser.googlelabs.com/body.html#

    Hay que alagar también el buen rendimiento de Chrome 10 en WebGL, una pena que no sea así para el resto de contenidos gráficos.

  • EstándaresEste es otro punto candente. Los test de estándares en este caso los he incrementado. Al tes de estandar HTML5 y al portal de MS le he sumado el de WebGL, que aunque aun tan solo Chrome y Firefox son compatibles, estoy seguro que antes de que termine el año todos se habrán subido al carro. Microsoft ha creado un portal bastante interesante en cuanto a test se refiere para estándares. En este caso en particular he pasado todos los test a Firefox 4 y todas las versiones actuales de los navegadores, y de ahí he obtenido los resultados publicados. Evidentemente estos tests están pensado para que IE9 aparezca como claro vencedor, y en cambio vemos que incluso en sus test Firefox 4 se acerca peligrosamente a los resultados de IE9, mientras que el resto aun distan mucho.

    Y que decir sobre Nielsen? Bueno, en este ocasión IE9 sale muy perjudicada, y es que aunque es cierto que IE9 ha mejorado enormemente frente a su predecesor, no es todo lo que podría ser y se ha dejado muchísimas cosas en el tintero.Personalmente a cuanto HTML5 se refiere me fío más de los segundos test, más que nada porque aun cuando Microsot esté haciendo las cosas mucho mejor, no serían tan idiotas de sacar un conjunto enorme de Test que le dieran la victoria a otro navegador. Es evidente por tanto que los test que encontraremos en Microsoft tienen la finalidad de dar como ganador a IE9. No obstante son igualmente útiles a la hora de comparar el resto de los navegadores.

    En estos test encontramos de nuevo grandes sorpresas, quizás no tanto por los números, pero sí por lo que significan si se saben interpretar. Por ejemplo, si hacemos cuenta a los Test de IE9 vemos que Firefox 4 llega casi al 80% en todos ellos, llegando al 90% en la mayoría de los casos. Pero si mirásemos donde falla (por motivos de legalidad no creo que pueda publicar la tabla completa de resultados tal y como la tiene publicada microsoft), vemos que lo hace en su mayoría en DOM (escritura japonesa y eventos) y en algunos elmentos de HTML5 (con elementos no me refiero a partes de html5). Tanto Chrome como Safari (los cuales usan ambos el mismo engine WebKit), así como Opera obtienen claramente unas “puntuaciones” bastante inferiores. El test de MS hay que mirarlo con prudencia evidentemente. Como podemos ver es claro que MS iba a obtener un 100% en todos los test (es de cajón), del mismo modo que es evidente que aquellos test en los que IE9 fuese a fallar no se exponen. Pero evidentemente dejando a un lado a MS, es interesante para probar al resto de los navegadores.

    En la nueva actualización del test de compatibilidad de MS se han cambiado unas cuantas cosas de sitio, pero casi todos los test son los mismos. Si se ha incluido como novedad una especificación (de nuevo, no deja de ser por ahora un borrador no definitivo) llamado Web Timing. En realidad será posiblemente una función interesante de cara a diseñadores/programadores web (para mi resulta interesante), aunque de escaso valor para el público mayoritario, y que por ahora tan solo MS como chrome la integran ligeramente. Mozilla trabaja en ella pero dad la ambiguedad de las especificaciones oficiales y del continuo cambio de estas, no parecen estar muy convencidos (no porque resulte difícil su implantación, sino por una cuestion de no trabajar el doble para nada). Safari y Opera por ahora no se han movido al respecto.

    Podemos concluir sin duda alguna que mirando todos los tests, quizás el navegador más compatible con los estándares actuales sea Firefox, seguido quizás por Chrome. Determinar el tercer lugar sería complicado, quizás fuese Internet Explorer, quizás Opera, quizás Safari, todo depende de a que le diésemos mayor valor. Pero es lo que sucede con los estándares que aun a día de hoy no son oficiales.


  • Compilaciones x64Copiado del articulo anterior en parte: Aun no he tocado este tema. Como puede verse, se ha usado también las versiones de 64 bits de los navegadores que las tienen, Firefox e IE9. En general podemos decir que el soporte x64 aun no cumple con lo esperado. El equipo de Mozilla por su parte está logrando alcanzar los resultados que se obtienen con el navegador de 32 bits, mientras que en cuestionese intensivas se puede obtener un mejor rendimiento. Por otro lado me he topado con una gran sorpresa al ver la versión de 64 bits de IE9. No, no hay error en las cifras, IE9 x64 falla estrepitosamente en JavaScript!! es posible no obstante que su nuevo motor JS no haya sido portado a la versión x64, y de ahí a sus resultados tan dispares. Portar un programa a 64 bits es complicado. Ya no solo el optimizarlo, sino simplemente el portarlo. La gran mayoría de optimizaciones no se han realizado teniendo en cuenta los 64 bits, con lo que es de esperar que el rendimiento sea inferior. La buena noticia es que en el caso de Firefox el proyecto ya ha unificado las dos arquitecturas. Cada día que pase los compiladores que usan estarán mejor preparados para 64 bits y llegará el día en el que efectivamente veremos de forma clara el beneficio de un navegador web de 64 bits, a fin de cuentas recordemos que teóricamente un programa en 64 bits podría ser hasta un 15-20% más eficiente que su homólogo en 32 bits (por supuesto dependiendo de mil circunstancias).

    Queda citar que la versión oficial de 64 bits para Firefox no aparecerá en Firefox 4, sino que será retrasada para Firefox 5 (que debería de llegar antes del verano).
    Por su parte, actualmente no existe intención por parte de los demás navegadores la creación de versiones de 64 bits, aunque creo (no estoy seguro) que para MAC OS si hay una versión de 64 bits de Safari.

 

Creo que todos estan haciendo un trabajo importante, sobre todo Google y Mozilla. Safari se está quedando muy atrás en la guerra de los navegadores (si es que alguna vez entró en ella) y Opera no logra levantar cabeza. Aun está por ver si IE9 logra levantar algún punto, aunque debería de ser posible dado el marketing del lanzamiento de este. El problema es que junto a este llega ahora el de Firefox 4 (la semana que viene), lo cual puede ecliptar en parte IE9, sin contar evidentemente que aunque IE9 es un buen avance frente IE8, no es comparable ni de lejos a Chrome ni Firefox.

De todos modos aquí no podemos cubrir todos los test posibles, el decir que navegador es mejor que otro es algo complicado. Personalmente la mayoría conoce mi predilección, que es sin duda alguna Firefox 4. Chrome es una opción interesante, pero cojea enormemente tanto en extensiones como en opciones, por ejemplo el depender de las opciones de IE para configurar un proxy, algo que debería de ser trivial, o la pobre implementación de aceleración hardware que posee o poseerá a corto plazo. De Opera no puedo decir nada, solo que posiblemente nunca logren una cuota importante de mercado, mientras que IE9 bueno… como sustituto de IE8 por supuesto, pero al igual que Safari, aun estan a años luz de lo que es Firefox. ¿Para mi? 1º Firefox, 2º Chrome, 3º IE9, 4º Opera, 5º Safari.

Aprovechando el lanzamiento oficial de Firefox, ampliaré parte de la información y veremos como muchas características que aquí no se nombran son de peso a la hora de escoger un navegador, no simplemente test sintéticos o números que muchas veces simplemente no nos dicen nada.

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.