Archivo de la categoría ‘MAC OS’

Vulnerabilidades en 2012: Windows 7/8, OSX, SmartPhones y Navegadores

Este año las felicitaciones navideñas y el próspero año nuevo se quedaron en aguas de borrajas, aunque no por eso quiera decir ni mucho menos que los días de escribir algunas cosillas en el blog terminaron. Así que antes de comenzar, aunque vaya un mes tarde, espero que todos pasásemos unas felices navidades, y que este año sea próspero para todos.

Dicho esto, ya el año pasado hice exactamente lo mismo para con los datos de 2011. Así que este año había que hacer lo mismo para el año 2012 que ya hemos dejado atrás. Los datos de nuevo están extraídos desde Secunia y el NIST

Muchos pueden creer que no es importante estos datos, pero sinceramente al menos para mí, no como aficionado a la materia sino como usuario diario de estos software es de suma importancia, lo suficiente muchas veces como para ver si uso el software correcto, o a la hora de aconsejar a otros sobre que productos decantarse. Es algo que siempre me ha sorprendido enormemente, cualquier persona se escandaliza si ve una pantalla de publicidad con un mensaje extraño, pero nadie se escandaliza cuando le dicen que su dispositivo o su equipo se encuentra en serias deficiencia en cuanto a seguridad, y que cualquier Hacker inteligente podría tomar el control de su dispositivo. Cuando intentas contarle esto a las personas te miran raro, o te dicen eso de: “Total para lo que tengo…”. En cambio, es cuando a esa persona le sucede algo por culpa de ello, es ya siempre tarde, y no son uno ni dos ni tres los casos al año, raro es el mes que no leo en mi correo o por cualquier otro medio alguien que tiene un problema, y no precisamente por que el navegador no deja de reenviarle a webs pornográficas.

Es por todo ello, que el principal problema de seguridad que existe a día de hoy es la ignorancia, el creer que nadie puede estar interesado en nuestros datos (cuando son oro puro para muchos), el creer por pura fe lo que le dicen otros, que posiblemente tienen aun más problemas que él, aunque no lo sepa. La mejor forma de enseñar, no es con miedo, no es con críticas baratas, es simplemente mostrando datos, enseñando que hay, que no hay, y que cada cual sea por tanto quien saque sus propias conclusiones.

 

Bien, el objetivo de este post como el del año pasado, es ver el número de fallos de seguridad (vulnerabilidades) acumulado durante este año pasado 2012 en sistemas operativos de escritorio, de dispositivos portátiles y de navegadores web. Eso no quiere decir que no existan otros problemas de seguridad ni mucho menos, los datos que puedo mostrar son datos PÚBLICOS que cualquiera puede tener acceso, en concreto mis datos recogidos son simplemente los CVE registrados. CVE son los reportes (un identificador) que asigna un organismo internacional a vulnerabilidades/fallos de seguridad. Hay que tener en cuenta ciertas cosas a la hora de interpretar los datos

Primero, un CVE NO IMPLICA de modo alguno que un hacker podría hacerse con el control total de tu dispositivo a través de él, un CVE es un problema potencial de seguridad que puede ser explotado con fines malignos o no, y que por supuesto su peligrosidad varía enormemente en relación con el tipo de fallo descubierto. De este modo, tenemos problemas de seguridad menos peligrosos como los que “simplemente” exponen datos de nuestro sistema o datos sensibles al exterior sin nuestro consentimiento, pasando por fallos de seguridad que permiten el Spoofing, el Cracking, escaladas de privilegios, ataques de denegación de servicio… y por supuesto hasta llegar al peor de los males, como es el acceso al sistema, que son vulnerabilidades que se pueden aprovechar para la ejecución de código remoto (digamos, el santo grial siempre del Hacker)

Segundo, hacer una tabla con el número de fallos de seguridad sin tener en cuenta otros datos sería totalmente demagogo, hay que entender muchas veces como se recogen dichos datos, si puede existir una explicación “decente” a dichos números… de lo contrario entraríamos de nuevo en escribir artículos partidistas en los que el redactor siempre haría que ganasen unos y otros en función de sus intereses. Aquí no se trata de ganar o perder, se trata de exponer datos y explicar lo que puede explicarse con las razones que puedan darse. A partir de ahí, cada cual tendrá que pensar un poco por si mismo y sacar sus conclusiones, no creerse los datos expuestos y fijarse simplemente en una tabla de datos.

Por el segundo punto, voy por ello a recalcar con mucho énfasis la gran importancia de esos “atenuantes” o “detonantes” de este número de vulnerabilidades. De echo en mi humilde opinión, que un producto haya obtenido el mayor número de vulnerabilidades a lo largo del año no implica que sea un producto inseguro per sé, eso hace solo un 50%, el otro 50% reside (de nuevo en mi opinión) en las políticas de actualizaciones/distribuciones de los desarrolladores, y del índice de penetración del mercado que posee cada producto. Las políticas de actualizaciones/distribución es esencial para tener nuestros sistemas dispositivos siempre al día, y la penetración del mercado es esencial para entender que plataformas están mucho más expuestas a todo tipo de ataques, a fin de cuenta nadie quiere encontrar un fallo de seguridad que afecte a un 1% de la población, lo intentan buscar en productos que afecte a un 50%, aunque sea 100 veces más complicado el hacerlo.

Las versiones usadas en cada caso, correspondería con las versiones que dicho producto ha tenido durante estos pasados 365 días. Por ejemplo en el caso de Windows, se han sumado los fallos de seguridad de Windows 7 de TODO el año conjuntamente con los de Windows 8 de TODO el año (desde que se terminó la versión de oro en Agosto. Lo mismo para cada producto. El índice de penetración de mercado se calcula simplemente tomando el porcentaje global de cada producto, y este a su vez se divide en función del índice de penetración que posee dicha versión dentro de dicho producto, si posee más de una versión ese producto en el período a tratar (2012), se suma dicho porcentaje. Es  decir, que si Windows posee por ejemplo un 90% de cuota de mercado y fuésemos a tratar SOLO windows XP, y que este fuese un 50% de todos los Windows instalados, el porcentaje real de Windows XP sería por tanto de un 45%, el 50% de ese 90%. Es simple.

 

Sistemas Operativos: Windows 7/8 VS OSX Lion/Montain Lion

Escritorio

 

Los datos son escalofriantes un año más, tanto en fallos de seguridad como en cuota de mercado.

  • Windows 7 en conjunto con Windows 8 poseen una cuota de mercado aproximado de un 50%, y terminaron el año con solo 50 fallos de seguridad
  • OS X Lion en conjunto con OS X Montain Lion posee una cuota de mercado conjunta aproximado del 5%, y terminaron el año con la friolera de 164

Los datos que tendríamos que obtener serían totalmente inversos, dado que Windows 7/8 posee una cuota de mercado 10 veces superior, el número de fallos de seguridad quizás no tendría que ser proporcionalmente también diez veces superior, pero evidentemente superior. En cambio el panorama no es así. A pesar de que Windows 7/8 están asentados en el 50% de los PCs de escritorio (un 92% aproximadamente todas las versiones de Windows en su conjunto), y a pesar de que OS X tan solo posee una cuota de mercado (sumando todas sus versiones) de un 6-7%, OS X posee una tasa de problemas de seguridad muy superior a Windows, la triplica!! Con el índice tan bajo de cuota de mercado y dicha tasa de problemas, teniendo en cuenta que OS X es igualmente software de código cerrado, deja claro sin lugar a dudas que es un sistema muy vulnerable.

Como ya dije anteriormente, hay que ver también la política de empresa de cada desarrollador de cara a las actualizaciones o el despliegue de su software. Una tasa alta de fallos de seguridad es mala, pero dentro de lo malo puede ser menos malo si se implementan políticas de actualizaciones rápidas, de respuesta inmediata ante cualquier tipo de vulnerabilidad que se descubra. Estos datos son igualmente públicos y se conoce la política de estas dos grandes empresas ante los fallos de seguridad:

  • Microsoft: Publicación estándar mensual de todos los boletines de seguridad, así como actualización de las definiciones de malware y otras actualizaciones (no de seguridad). Dicha publicación se realiza el segundo martes de cada mes. Al margen de este ciclo estándar, a veces también se han lanzado actualizaciones esporádicas en cualquier momento del año cuando se había detectado un problema de seguridad muy grave o para solucionar un fallo existente que ya se estaba usando para causar estragos. Eso quiere decir que en el año 2012 Microsoft lanzó sus actualizaciones en al menos 12 entregas.
  • Apple: No posee un calendario fijo de actualizaciones, suele lanzar sus actualizaciones en forma de macropaquetes, distribuidos a lo largo de todo el año. El problema es que a lo mejor en todo el año tan solo lanza 3-4 de estos. Eso quiere decir que aun cuando aparece un fallo de seguridad grave, el usuario puede necesitar de al menos unos meses para que Apple haga caso. A lo largo de 2012 Apple lanzó 5-6 paquetes de este tipo, y solo intervino en una actualización espontánea no ante la gravedad del fallo de seguridad que les afectaba, sino porque dicho fallo saltó a los medio de prensa. Es una pena, pero Apple tan solo lanza actualizaciones de forma rápida cuando el problema se ha hecho eco en los medio.

De nuevo, otro fracaso por parte de Apple y su OS X, fracasa en fallos de seguridad al año, fracasa en número de fallos de seguridad si tenemos en cuenta la tasa de mercado estrepitosamente, y lo que es peor, la política de actualización de Apple es pésima, lo que hace que los usuarios sean propensos de sufrir problemas de seguridad por exploits y otros medios que llevan circulando por la red a lo mejor durante meses, sin que Apple haga nada.

 

SmartPhones: Android VS iOS VS Windows Phone

 smarphones

 

En este caso no tenemos dos competidores, tenemos 3, y si bien es cierto que Windows Phone aun no tiene una cuota de mercado importante, es previsible que vaya subiendo poco a poco. Pero discutamos estos resultados teniendo en cuenta la penetración en el mercado que tiene cada OS:

  • Windows Phone posee tan solo un 3% aproximadamente de cuota de mercado dentro de los Smartphones, y tan solo se ha conocido un boletín CVE en todo 2012. Este resultado por tanto es totalmente consistente, es decir, con una tasa de mercado que ronda el 3%. al margen de lo seguro o lo inseguro que sea el sistema, es comprensible que el número de fallos sacados a la luz en este año sea mínimo. De nuevo esto no quiere decir que el sistema sea más o menos seguro que el resto, pero al menos sus datos son repito consistentes.
  • Android posee un índice de mercado entorno al 75%, eso quiere decir que más o menos 3 de cada 4 dispositivos Smartphones que se venden es Android. A pesar de ello terminó el año con 8 CVE, un dato bastante bueno para tener un 75% de cuota de mercado, ya que implica que Android es a día de hoy la plataforma más… “jugosa” de cara a los Hackers
  • iOS posee una cuita de mercado entorno al 15%, que no es poco ni mucho menos, pero en su caso terminó el año con la friolera de 94 fallos de seguridad. Que sea mucho o poco no podemos juzgarlo de forma sencilla, pero si simplemente lo comparamos con Android que posee una penetración de mercado 5 veces superior y menos de la décima parte de fallos de seguridad…

Estos datos son aun más inexplicables si tenemos en cuenta otro factor que aun no se ha comentado, que es que software que vamos a ver aquí, es de código libre. Cuando un software es de código libre cabe esperar que en igualdad de condiciones registre siempre un mayor de fallos de seguridad publicados. Esto es muy sencillo de entender, si es de código abierto CUALQUIERA puede acceder al código fuente y buscar y encontrar vulnerabilidades de forma mucho mucho mucho más sencilla. Esto lo veremos con claridad un pelín más adelante con los navegadores Web.

Bien, Android es de código abierto, y además posee una cuota de mercado de un 75%, esto significa que los resultados habrían sido consistentes y relativamente lógicos si fuese Android y no iOS quien tuviese esos 94 fallos de seguridad. Es más, si así hubiese sido, durante un mes estaríamos escuchando en todos los medios lo vulnerable que es Android. Lejos de eso, es iOS con tan solo un 15% (mucho si tenemos en cuenta el total, poco si lo comparamos con Android), a pesar de código totalmente cerrado, alcanza la friolera de 96.

En cuanto a políticas de actualizaciones y distribuciones:

  • Microsoft al igual que hace con su OS de escritorio, suele ser relativamente rápido a la hora de tapar cualquier problema de seguridad. No podemos saber no obstante su política exacta ante Windows Phone, puesto como ya se ha dicho con tan solo un fallo de seguridad en 2012 no se puede cuantificar demasiado bien su tiempo de respuesta.
  • Google por su parte es conocido en todos los ámbitos por dar siempre una respuesta casi inmediata ante cualquier fallo de seguridad, este es inmediatamente corregido en los repositorios AOSP para que cualquiera pueda aplicar el fix que sea necesario. Aquí hay que indicar que existe un retraso significativo no a la hora de actuar contra el problema, sino en que los fabricantes lo adepten. No es un fallo de Google de echo, es de las políticas de cada uno de los fabricantes. Lo general es que ante un fallo de seguridad grave, los fabricantes puedan tardar en lanzar actualizaciones a sus dispositivos hasta dos y tres meses.
  • Apple aplica la misma filosofía que con OSX, hasta que el fallo no trasciende a los medios de comunicación le da igual la gravedad del problema, y por desgracias tenemos muchos ejemplos de ello. De echo, precisamente aparece en los medios, porque es algo fragante que está totalmente extendido. Así aun recordamos todos el fallo de seguridad que permitía tomar el control de cualquier iPhone simplemente a través de unos SMS que se enviaban, o al menos 4-5 fallos de seguridad críticos que permitían igualmente apoderarse del control total del dispositivo simplemente haciendo que el usuario accediese a una web concreta. Fueron necesario meses y meses antes de siquiera lanzar una actualización para ello, a lo que a partir de aquí hay que sumar el tiempo que tardaría cada cual en aplicar dicha actualización.

 

Navegadores WEB: Opera 11/12, Internet Explorer 9/10, Firefox 10..17, Safari 5/6. Chrome 17..23

 navegadores

 Veamos en esta ocasión la consistencia de los fallos de seguridad de cada navegador atendiendo a su cuota de mercado, aunque en el caso de los navegadores hay que añadir un factor adicional que posee tanto Firefox como Chrome y que se debe de tener muy en cuenta:

  • Opera registra el menor número de fallos de seguridad, con tan solo 34 boletines CVE si sumamos los fallos de seguridad de todo 2012 a las versiones que estuvieron en funcionamiento en él, pero hay que tener en cuenta que posee una tasa de mercado muy pequeña, entorno al 3%. Es necesario por tanto ver el resto de navegadores para ver si sus datos son consistentes, y lo cierto es que más o menos si lo son. No es una tasa demasiado elevada, era de esperar que al tener tan poca tasa de mercado sería el que menor número de boletines acapararía. Aun así, desde mi punto de vista, para tener tan solo 3% de cuota me parece un valor alto
  • Internet Explorer 9 y 10 suman un total de 39 problemas de seguridad, algo más que Opera, pero con una gran diferencia, y es que IE tiene una penetración que ronda el 39%, eso multiplica por 10 la expansión de IE frente a Opera, y aun así tan solo llega a 39. Este dato es muy sorprendente.
  • Firefox si lo comparamos con los datos del año pasado a sufrido un incremento exponencial (que ya veremos debido a que), terminado 2012 con 216, muy superior a los 39 de IE sin duda alguna, y posee un share entorno al 25%, nada despreciable tampoco.
  • Safari alcanza los 274, pero en este caso el share de este es igualmente mínimo, rondaría el 6%.
  • Chrome por su parte comparte todos los pros y contra de Firefox, solo que en este caso llega a los 277 boletines, con un mercado que ronda el 36%, eso significa la segunda posición en cuanto a su uso.

Antes de analizar esto, hay que tener en cuenta que tanto Chrome como Firefox son de código abierto, y que ambos ademeás poseen ciclos de productos muy cortos, solo hay que ver que en todo 2012 el resto de los navegadores difícilmente cambiaron en uno la versión de sus productos, mientras que Firefox vivió 2012 con 8 versiones diferentes, y Chrome lo hizo con 7. Esto es a tomar muy en cuenta, ciclos cortos permiten un progreso más rápido de los navegadores, pero también implica que aparecerán más problemas de seguridad, aunque (y esto es importante) solo afecten a versiones concretas de ellos. Es decir, Chrome y Firefox poseen una tasa mucho más alta fundamentalmente a que participan con muchas más versiones, pero no quiere decir que todos esos fallos de seguridad afectasen a todas las versiones, de echo si dividimos el número CVE entre el número de versiones lanzadas, vemos que el resultado es mucho más cercano al que logra obtener IE.

Dicho esto, de todos modos el ganador indiscutible es Internet Explorer, aunque es cierto que es de código cerrado, con una tasa tan grande de mercado y con tan solo 39 fallos de seguridad en todo 2012, nadie puede acercarse. Impresionante trabajo por marte de Microsoft. El segundo lugar sería más complicado, Opera tiene un resultado muy bueno, pero un 3% es muy poco significativo, por tanto el segundo lugar sería quizás para Firefox, sí, son 216 CVE, pero si tenemos en cuenta que posee un 25% de mercado, ciclos cortos y de código libre, hay que entender el gran trabajo que hay de fondo. Del mismo modo y rozando los talones estaría Chrome con algunas más, aunque también con un porcentaje de mercado algo superior. Después si situaría a Opera, y por último tendríamos Safari, que aun cuando tendría que partir de una postura ventajosa como Internet Explorer, fracasa estrepitosamente en todo. Con tan solo un 6% de mercado, aun asiendo de código cerrado y con ciclos largos, obtiene el el segundo peor número, muy cercano al de Chrome, con 274. A diferencia de Chrome, Safari no tiene excusa alguna de tal número de fallos de seguridad, y tampoco puede culparse a las diferentes plataformas ya que desde Safari 6, este tan solo se usa en OS X.

Las políticas de actualizaciones y distribución en algunos casos son las mismas ya comentadas:

  • Opera actúa ciertamente con bastante rapidez ante cualquier problema de seguridad, no tiene una actuación inmediata, pero se puede tener la cierta seguridad de estar protegido por fallos de seguridad que salen día a día. Si es un fallo crítico, posiblemente tendrían una actualización lista en dos o tres días.
  • Microsoft aplica a Internet Explorer su misma política que a Windows, usa los boletines de seguridad mensuales de Windows para actualizar Internet Explorer, y solo cuando un problema grave de seguridad es detectado se plantea el lanzamiento de una actualización fuera de su ciclo normal. Eso nos dice que con seguridad Internet Explorer suele estar actualizado y protegido con un intervalo de un mes, y si es urgente de nuevo casi de forma inmediata, unos días como mucho
  • Mozilla y Google al usar un navegador de código abierto y ciclos cortos, la actuación ante problemas de seguridad es prácticamente inmediata, en cuanto es conocida o comunicada, sin importar demasiado el grado de importancia que tenga problema encontrado es corregido con la mayor presteza en los repositorios oficiales, y en cuanto son probados se lazan actualizaciones inmediatas al propio navegador, que se actualiza el sólo sin intervención siquiera muchas veces del propio usuario. Sin duda alguna son las dos compañías que reaccionan más rápido ante cualquier amenaza. Bravo por ambos.
  • Apple por su parte usa también la misma filosofía que en OS X o en iOS, actualizaciones esporádicas en las que aprovechan para parchear todo lo que tengan pendiente, no importa si el fallo de seguridad lleva circulando dos días o un mes, si no ha trascendido a la prensa no cambian su calendario. Eso hace evidentemente que el navegador del usuario se encuentre constantemente en peligro, y más si vemos el gran numero de fallos que acumula, con 274 fallos de seguridad tenemos una media de 0.7 fallos diarios, lo que quiere decir que el usuario de Safari está sencillamente “jodido”, usar Safari implica estar expuesto a cualquier Hacker básicamente.

Pronto será el Pwn2Own como todos los años, en el que los navegadores se expondrán en un concurso de Hackers a ser destrozados. Aquí es donde vemos realmente no lo bueno o malo que sea el navegador en aguantar (que también), sino las políticas de empresa de cada cual. Cuando veos que dos o tres días antes del Pwn2Own Apple lanza apresuradamente un macro paquete de actualizaciones, algo te dice que es mejor huir de dicho navegador. Google hace lo mismo no nos engañemos, aprovechará días antes para parchear al máximo Chrome e intentar pasar indemne la prueba del Pwn2Own, pero en su defensa tenemos que decir que es un patrocinador oficial del Pwn2Own y que hace precisamente estos días una competición similar, dicho de otro modo y pese a intentar aprovecharse el día antes para actualizar su navegador, posiblemente es la empresa que se toma más en serio la seguridad de los 5, o al menos lo demuestra. Microsoft el año pasado ya optó por jugar limpio y no lanzar ninguna actualización a destiempo, es decir, fue el único que jugó limpio…. veremos este año que sucede.

Es por eso que aunque Firefox o Chrome posean las tasas mas altas de problemas de seguridad (quitando Safari), es casi imposible que ninguno de esos fallos de seguridad pueda afectar al navegador, a menos que alguno de ellos sea lo que se conoce como un Zero Day Exploit, es decir, un exploit que se aproveche de un fallo de seguridad que aun no ha sido comunicado o hecho público. Es la única forma, puesto de lo contrario si el usuario mantiene su navegador actualizado (que generalmente se automantienen ellos), estará siempre protegido. Internet Explorer es igualmente complicado atacarle con un CVE ya publicado, aunque es posible, si un exploit aparece para aprovechar un CVE, con suerte es posible usarse durante unos días. Ese es el problema de Sarafi, que es posible usar contra él exploits que afectan a CVE publicados incluso meses antes, sin que el usuario pueda hacer nada al respecto porque no hay ninguna actualización que le protega ante ellos, y hablamos de exploits y fallos de seguridad, aquí no sirven de nada los corta fuegos o cualquier otro tipo de medidas.

 

Tener un número alto de fallos de seguridad es malo, este número es alto o bajo solo si lo comparamos con productos similares y vemos que número podría ser más o menos aceptable o lógico, es cuando vemos la capacidad realmente de los programadores y lo serio que pueden tomarse la seguridad. Pero eso no hace ni mucho menos que nuestros dispositivos sean más o menos seguros, es importante, pero no es algo que lo decida por completo, como hemos dicho con Google o Mozilla, es incluso más importante el tener una actuación inmediata ante cualquier problema, es la única forma de tener la certeza, o al menos la garantía más alta, de que estamos seguros. Vale, no hay nada seguro, y un exploit Zero Day hará trizas cualquier sistema por protegido que esté, pero hay que poder encontrarlo y usarlo. Y sí, los hay, siempre los habrá.

Un saludo.

Comparativa Navegadores 2012/Q2: Internet Explorer 10, Firefox 20.0, Chrome 25.0, Safari 6, Opera 12.12

Índice

  • Navegadores
  • Condiciones de las pruebas
  • Benchmarks
  • Conclusiones

 

Versiones de los navegadores

 

Navegadores:

 

Aunque hayan pasado más de 6 meses, no podía faltar una nueva entrega, sobre todo teniendo en cuenta que no hace mucho Windows 8 fue oficialmente lanzado, y con él por tanto la versión final de Internet Explorer 10. La razón por la cual siempre hago mis comparativas con las versiones aun en desarrollo la he dicho siempre y siguen siendo las mismas, y me limito a hacer prácticamente un Copy/Paste de la comparativa anterior:

a) Chrome y Firefox poseen ciclos de actualizaciones muy rápidos, haciendo por tanto que estos siempre tengan ventajas ante otro tipo de comparativas que los enfrenten ante navegadores con ciclos de actualizaciones más largos como Opera, IE o Safari, ya que estos últimos tan solo lanzan versiones oficiales cada bastante más tiempo. Comparar las últimas versiones en desarrollo de cada navegador nos permite ser más imparciales. Incluso Microsoft está empezando a lanzar cada cierto tiempo versiones preview.

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. Por tanto es también una buena oportunidad para probar no lo que hay sino lo que tendremos.

 

Por tanto como es costumbre, tanto Firefox como Chrome se han tomando sus respectivas versiones Nighly. Opera no lanza versiones Nighly, pero sí prácticamente  todas las semanas, al igual que Safari. Las versiones de todos ellos se han especificado anteriormente. Para Internet Explorer se ha usado la versión más actual a la que tenemos acceso, que aunque no es una versión en desarrollo, no olvidemos que su lanzamiento oficial conjuntamente a Windows 8 hace tan solo unos días, puesto que por desgracia no tenemos acceso a versiones betas o alpha.

Como siempre, las versiones de 64 bits de Opera, Internet Explorer y Firefox NO CONTARÁN en el tanteo final, y tan solo tendrán un valor presencial en las comparaciones pertinentes, exceptuando en las de compatibilidades con estándares puesto sus resultados serían supuestamente los mismos. Esto es necesario debido a que lamentablemente aun no tenemos disponible versiones de 64 bits de Chrome o de Safari. Hay que anotar que aunque Windows 8 x64 incorpora tanto una versión de 32bits como de 64bits, el navegador siempre ejecutará una instancia en 64bits que tomará el rol de la interfaz, mientras que ejecutará el contenido de las pestañas en instancias separadas, de 32bits si se ejecuta en modo estándar Internet Explorer, o en el modo “puro” de 64 bits si se habilita las funciones de “Modo protegido Avanzado”. En las pruebas de 32 bits se usa el modo mixto (la interfaz siempre se ejecuta con instancias de 64 bits), en las de 64 bits se activa el modo protegido avanzado y todo se ejecuta en 64bits.

Por quinta (y posiblemente última vez), la versión de Safari instalada está exenta de QuickTime como ya se ha explicado otras veces, esto hace que pierda muchos aspectos de compatibilidad. Las razones son las que he dado siempre, QT actúa de plugin para Safari para dotarlo de mayores prestaciones, y la idea es probar siempre los navegadores, no sus complementos. De lo contrario, por esa regla de tres, podríamos instalar diferentes plugins o extensiones a otros navegadores para dotarlos de más características o mejoras. Sería evidentemente injusto. Apple es la que no debería de asociar un reproductor multimedia a su navegador.

Por otro lado, posiblemente esta sea la última vez que veamos Safari en estas comparativas. Es muy simple. Aunque Apple no ha hecho hasta la fecha ningún comunicado al respecto, lo cierto es que desde hace ya meses Apple ha eliminado de su web todo comentario, enlace, propaganda… hacia Safari para Windows. Esto no es algo a extrañar realmente, si tenemos en cuenta que el índice de mercado que posee Safari en Windows es prácticamente nulo, e incluso en MAC OS ha dejado de ser la opción predominante. Actualmente se siguen generando no obstante Nighlys casi a diario de Safari para Windows desde el proyecto WebKit, lo cual por tanto no debería de ser un problema continuar dando soporte a este navegador en mis comparativas, pero lo cierto es que estas Build no funcionan de forma totalmente independiente, sino que dependen básicamente de toda la interfaz de Safari y otros. Sin el debido soporte de Safari para Windows, estas versiones serán posiblemente cada vez más inestables, y será cuestión de tiempo que dejen siquiera de generarse. En esta ocasión no han existido mayores problemas, y aunque la build se referencia como Safari 5.2 no hay que engañarse, y os aseguro que se ha usado el código más reciente que posee Safari. Por tanto aunque a efectos teóricos se base sobre Safari 5.2, se estará probando Safari 6+

Por último, respondiendo a algunos comentarios y sugerencias de otras veces, la razón por la cual no se incluyen en la comparativa otros sistemas operativos es muy simple. Si quieres hacer una comparativa que sea mínimamente rigurosa tienes que intentar eliminar todas las variables que sean externas a los navegadores. En una comparativa puedes medir al mismo tiempo una sola variable, no dos. Si introdujésemos en esta comparativa resultados provenientes de Linux por ejemplo, además de tener disponibles menos navegadores no podríamos comparar los resultados obtenidos en Windows con los obtenidos en Linux, no tendrían validez alguna puesto que el sistema operativo sería siempre una variable constante. Es como si queremos comparar el rendimiento de una CPU, y para ello tenemos dos equipos totalmente iguales en el que en uno ejecutamos el programa A y en el otro el programa B para medir el rendimiento. Evidentemente ese test no tiene sentido alguno ya que se está midiendo algo de dos formas diferentes. Siempre que sea posible hay que hacer el esfuerzo de no alterar las condiciones, y es por ello que es necesario realizarlo tan solo sobre un solo OS. Sí, se podría hacer la misma comparativa sobre Linux y ver los resultados, y podríamos llegar a conclusiones similares incluso, pero serían solo válidas para ese OS. Dado que Windows posee una cuota de mercado que roza el 90%, es evidente el motivo de por qué se usa este Sistema Operativo.

 

 

Condiciones de las Pruebas

 

Sistema:

  • OS: Windows 8 Enterprise x64
  • CPU: Intel Core i7 920
  • RAM: 12GB DDR3 Triple canal
  • Video: nVidia GTX460 (Driver 310.61)
  • Resolución: 1920 x 1080 (navegador siempre maximizado)
  • Flash Player: 11.5.502 (Firefox, Opera y Safari), 11.3.376.12 (Internet Explorer 7), 11.5.31.106 (Chrome)

 

Como es costumbre, todos los navegadores son instalados de forma limpia en el mismo equipo, usando para ellos como es de esperar perfiles nuevos, tocando mínimamente las opciones de configuración de los navegadores, como pueda ser la página de inicio, la deshabilitación de la carga selectiva progresiva de pestañas, la activación de aceleración por Hardware y WebGL en Opera y poco más. Esto último es debido a que Opera aun no está entregando su navegador con dicho soporte activado, aunque pueda parecer algo de “trampas” se tomará en cuenta también a la hora de evaluar el navegador.

Tan solo se ha instalado como complementos Adobe Flash Player en todos los navegadores y el complemento para WebM de Internet Explorer. El uso de Flash Player es evidente, necesario para algunos test en los que se desea probar el rendimiento Flash en diferentes navegadores y circunstancias, pero también para compararlo con las funciones nativas de vídeo en HTML5. La instalación por otro lado de WebM en Internet Explorer 10 tiene también su lógica. El futuro HTML5 especifica que los navegadores puedan reproducir vídeo sin necesidad de complementos, pero no estandariza que codecs para hacerlo. Opera, Firefox o Chrome soportan todos ellos el estándar propuesto por Google WebM, mientras que Microsoft y Apple apuestan (al menos por ahora) tan solo por H264. Guerras a parte, la idea no es comparar H264 frente a WebM, sino medir el rendimiento de la tecnología de vídeo para HTML5 y compararla a la tecnología de vídeo de Flash. Todos ellos (excepto Safari) soportan de un modo u otro esta tecnología sin ningún tipo de complemento, por tanto el requerimiento mínimo lo cumplen. Ahora bien, como deseamos medir el rendimiento es necesario que TODOS usen la misma tecnología. Por suerte además, existe un complemento oficial del proyecto WebM para IE, con lo que de este modo podemos hacer uso de la tecnología de vídeo WebM de HTML5 en todos los navegadores por igual, excepto como digo Safari, que queda fuera por la sencilla razón que ni siquiera (fuera de la caja) es compatible sin QuickTime. Si Safari fuese compatible al menos con WebM o HTML5 sin necesidad de QuickTime aun podríamos pensar en incluirlo, pero de lo contrario debe de quedar fuera.

 

Cada test se ejecuta 10 veces en cada navegador. Dado que hay test que son muy dependientes a las condiciones externas (y por tanto capaces de generar resultados extraños), el valor final de cada prueba se ha obtenido calculando la media aritmética de los valores registrados un UNA VEZ han sido descartados los valores “extraños” estadísticamente (por medio de la “Distribución Normal”). De este modo se intenta que los datos obtenidos sean lo más fiables posible, sobre todo como he dicho en aquellos test en los que simplemente una pequeña interferencia en el PC como un acceso a disco por algún proceso de fondo, es suficiente para modificar por completo un resultado.

Cada prueba puntúa de 1 a 5 (1 el peor resultado, 5 el mejor), reservando el cero para aquellas pruebas en las que el navegador no pueda realizarse por carencias 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. Dado que son versiones inestables (al menos algunas ellas) se creará un último “test” que recogerá a modo de resultado la estabilidad del navegador frente a las diferentes pruebas.

 

 

Benchmarks

En esta ocasión no ha habido grandes cambios en los test usados. Si cabe destacar que de momento se ha eliminado de forma temporal el test de PeaceKeeper. La última actualización que hicieron provocó que fuese imposible acceder de forma simple a los resultados parciales, así como no ha sido actualizado algunos de los test que ejecuta a los últimos estándares, con lo que los resultados no son para nada exactos. En cuanto los solucionen, se volverá a incluir.

Las Webs usadas para el consumo de RAM en este caso, así como los tiempos de inicio en frío/caliente y cierre serán las siguientes:

Bandeja de Gmail, Bandeja de Mail Live (Outlook), La página personal de Facebook, La página personal de Google+, YouTube (http://www.youtube.com/watch?v=KEIdACFBhGE en 360p), Portada de “MARCA”, Portada de “El País”, Google Play Store, Wikipedia (https://en.wikipedia.org/wiki/History_of_the_web_browser), eBay (http://www.ebay.com/fashion/womens-clothing). 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)
    • Tiempo de Inicio en caliente (1, 10 y 20 pestañas)
    • Tiempo de Cierre (20 pestañas)
    • Velocidad de carga de Webs con/sin Caché
    • RAM (10 y 20 páginas)
    • CPU/GPU reproduciendo contenido 1080p (Flash y WebM)

 

 

 

 

 

 

 

 

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. Fundamentalmente, 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, generalmente se realiza ejecutando el navegador una vez el arranque del sistema se estabiliza y se ejecuta pro primera vez este, restaurando la sesión de forma automática (de 1, 10 o 20 pestañas). En esta ocasión no se ha recurrido al sistema de siempre de reiniciar el equipo para vaciar la RAM, sino una aproximación similar más consistente y más rápida. El inicio en Frío se hace para asegurarnos que no hay datos en RAM que puedan agilizar la carga del navegador, pero el propio sistema operativo hace esto de forma automática nada más arrancar, cacheando en RAM librerías y otros de programas que ejecutamos de forma habitual para que después se ejecuten estos de forma más veloz. A esto Microsoft lo llama por ejemplo “Superfetch”. Es decir, que los tiempos de inicio en frío de los navegadores en Windows dependen completamente de esta tecnología. Para evitar esto en lo posible se podría deshabilitar Superfetch (que desestabilizará en parte el sistema) u optar por una opción más simple y eficaz: Llenar la RAM.

El sistema después de un arranque en frío empieza a cachear algunos datos. Si además abrimos cualquier aplicación y la cerramos, una gran parte de la memoria se va llenando con datos antiguos que pueden ser usados a posteriori, esta es la razón por la cual abrir una aplicación la primera vez después de arrancar es más lenta que la segunda. Esto lo hace el sistema pero siempre que existan RAM para hacerlo, a fin de cuentas si el sistema posee RAM que no está usando de forma activa, ¿por qué no usarla para cachear datos? Una forma rápida y totalmente eficaz de inducir a un navegador o cualquier aplicación a un inicio en frío es simplemente colapsando la propia RAM del sistema, obligando a este a consumir todo ese espacio que se había reservado para el caché de las aplicaciones. Esto es fácil, tan solo hay que escribir una pequeña aplicación que nos permita reservar la cantidad de RAM que especifiquemos. Si dispongo de 6GB de RAM libres, de los cuales se usan 2 para caché (y contienen datos), si ejecuto mi aplicación y digo que reserve 6GB más, los 2GB reservados son consumidos, puesto que tiene preferencia la aplicación activa. Crear una aplicación para esto es muy simple, y gracias la propio administrador de tareas de Windows 8 podemos ver en todo momento no solo la RAM libre/consumida, sino también la RAM usada en cada momento en el cacheo de aplicaciones/procesos.

Resumiendo, Inicio en frio en esta ocasión se ha realizado consumiendo toda la RAM del sistema asignada para caché, liberando toda la RAM asignada a la aplicación de consumo (lo que asegura que no hay cacheado nada importante) y ejecutando el navegador. Después de comprar este sistema con el inicio en frío (reiniciar) de toda la vida, los resultados son bastantes consistentes, más exactos y además no requiere reiniciar el sistema.

Inicio en caliente implica por el contrario 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=36 w=350 h=228 float=left][singlepic id=35 w=350 h=228 float=center]

  • Chrome: Falló en la carga de algunas pestañas, siendo necesario refrescarlas posteriormente (no se contabilizó ese tiempo extra)
  • Internet Explorer: Múltiples bloqueos y cierres en la carga

 

Tiempo de Cierre

Se ha medido 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, lo cual evidentemente no es deseable, sin contar con el consumo de RAM que mantiene. 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. Es importante al hablar de proceso “padre” si tenemos en cuenta que navegadores como Chrome o Internet Explorer son multiprocesos, y cada proceso padre ejecuta uno o varios procesos hijos:

[singlepic id=31 w=700 h=456 float=center]

  • Internet Explorer: Grandes irregularidades al cerrearse, diferencias de tiempo…

 

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 el caché del navegador activado y deshabilitado. 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 (La de Facebook, la d PlayStore, la de Wikipedia y la de eBay) fue abierta de forma aislada y se sumaron los tiempos de todas ellas. Como medida y para la consistencia de los datos, se seguro que el tamaño total de la web era aproximadamente siempre el mismo, y las webs tomadas eran las que presentaban un menor contenido dinámico (invariante):

[singlepic id=30 w=700 h=456 float=center]

 

Consumo de RAM

A día de hoy la gran mayoría de los sistemas actuales cuentan con cantidades más que suficientes de RAM, pero no por ello hay que malgastarlo. Además, hay que entender que cada dato que es cargado en RAM o procede del mismo proceso que lo genera o ha sido cargado desde el disco duro anteriormente, y los discos duros (ya sean SSD o convencionales) siguen siendo con diferencia el elemento más lento del equipo, con lo que esto es de vital importancia. El problema se acrecenta en dispositivos portátiles donde la RAM a veces no es tan “sobrante”, o cuando se está trabajando con otras aplicaciones más pesadas. 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=42 w=700 h=456 float=center]

  • Safari: Múltiples cierres
  • Opera: Picos entorno al 16-20% de uso del procesador
  • Internet Explorer: Picos entorno al 40-50% dele procesador

 

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 también si tenemos en cuenta que la la reproducción de Vídeo continúa a día de hoy siendo uno de los mayores “comecome” de baterías… sin contar con que la gran mayoría del tráfico producido en inet es por estos. 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 también a través del estándar HTML5 vídeo, usando como sistema WebM. Así podremos comparar a grandes rasgos la eficiencia de un sistema o de otro. Internet Explorer reproducirá WebM a través de un complemento como ya dijimos, más que nada porque IE10 oficialmente posee soporte para el estándar de vídeo de HTML5, lo único que ellos ofrecen de base tan solo el uso de H264 y no WebM. El vídeo reproducido en este caso es el mismo tanto en Flash a 1080 como en WebM a 1080 también, el trailer de “El Hobbit“, lo bueno de este vídeo es que está disponible en Full HD tanto en Flash, en WebM como en H264 (aunque este último no lo vamos a testear)

[singlepic id=50 w=700 h=456 float=center]

  • Opera: Saltos tanto en WebM como en Flash, posiblemente algún tipo de FrameSkip

 

SunSpider, V8 y Kraken

Son los 3 benchmarks más utilizados para medir el rendimiento de los motores JavaScript de los navegadores. En los últimos meses Google ha lanzado otro test nuevo a fin de sustituir básicamente V8, llamado Octane. Me parecería injusto usar los dos de Google, por tanto he optado por usar por última vez V8, y en la siguiente será sustituido por Optane. No obstante, aunque los resultados no los publique, son muy similares a los obtenidos por V8, quedando todos los navegadores más o menos en la misa posición parcial.

Como ya he dicho en muchas ocasiones no soy fan de test sintéticos de ningún tipo, y mucho menos tests que han sido optimizados al máximo por todos los navegadores para obtener buenas puntuaciones. Estos 3 test se toman como estándar por todos los navegadores, lo que quiere decir que puedo asegurar que TODOS los navegadores hacen trampas en estos test según les convenga. 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. Así es previsible que Google obtenga un resultado favorable además en V8, Firefox en Kraken y Safari en SunSpider, más que nada porque los test son suyos.

Más adelante veremos que el rendimiento JS en entornos reales (aplicaciones, código…) que a fin de cuenta son muy dependientes de JavaScript, los resultados son muchas veces totalmente dispares a los test sintéticos:

[singlepic id=46 w=350 h=228 float=left][singlepic id=49 w=350 h=228 float=center]

[singlepic id=37 w=350 h=228 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… siempre que por supuesto el navegador sea capaz de ejecutar en tiempo real la aplicación correspondiente, lo cual como digo se fundamenta en JavaScript

Normal Mapped es un test que aunque es claramente gráfico posee una carga de está 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:

[singlepic id=39 w=350 h=228 float=left][singlepic id=29 w=350 h=228 float=center]

[singlepic id=51 w=359 h=235 float=left][singlepic id=28 w=359 h=235 float=center]

  • Opera: En Canvas usa algún tipo de FrameSkip, lo cualmejora la puntuación pero produce saltos constantes

 

Tanque de peces (3.000 peces), Pecera (2.000 Peces)

Lo bueno de los peces, es que solo tenemos que añadir más al tanque o a la pecera para aumentar la complejidad. Se han mantenido los 3000 peces en el tanque y los 2000 en la pecera, aunque en esta última ya se ha alcanzado el tope por dos de los navegadores (se incrementará en la próxima). Dos Test similares pero diferentes, orientados ambos al rendimiento gráfico de Canvas puro y duro. Los dos fueron diseñados para aprovecharse de la aceleración hardware de contenido, por lo que es de esperar que Safari fracase estrepitosamente.

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=48 w=350 h=228 float=left][singlepic id=40 w=350 h=228 float=center]

 

“Come-Cocos” (Browse Hunt)

Un test bastante exigente en todos los aspectos, aunque está en la categoría de gráficos hace un uso extensivo de JS y SVG.  sin duda caprichoso y que prácticamente ningún navegador logra ejecutar de forma correcta, después de muchos meses ninguno es capaz de llegar a los 60 fps.

[singlepic id=32 w=700 h=456 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. Posiblemente sea también la última vez que lo veamos en acción, puesto que exceptuando Safari el resto de los navegadores logran “Pasarlo” correctamente, de 6 a 7 segundos no es algo que podamos… “valorar” en demasía.

[singlepic id=44 w=700 h=456 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. A diferencia que el test anterior, es uno de los mejores test para ir comprobando la evolución y el perfeccionamiento del potencial gráfico del navegador:

[singlepic id=41 w=700 h=456 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:

[singlepic id=53 w=700 h=456 float=center]

 

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

De nuevo, dado que todos los navegadores exceptuando inexplicablemente Internet Explorer 10 y (previsiblemente) Safari soportan WebGL, es ya de obligado cumplimiento su testeo. En realidad Safari si cuenta en esencia con soporte para WebGL, pero este soporte es tan solo para MACOS, por tanto queda exlucído a última posición junto a IE10.

El caso de Microsoft de no dar soporte para WebGL fue explicado hace tiempo por ellos mismos, personalmente no comparto su visión pero es respetable. El problema nace de que puede ser “peligroso” que el navegador pueda tener acceso directo o indirecto al hardware del equipo, como es en este caso el adaptador de vídeo para poder hacer uso de webGL. Navegadores como Chrome, Firefox u Opera no es que no tengan en cuenta este tipo de “problemas de seguridad potenciales”, todo lo contrario, simplemente se centraron en solucionar esas deficiencias. Han pasado ya muchos meses desde que comenzamos a ver WebGL en los navegadores y sabemos por los reportes de seguridad que las primeras versiones que implementaban los navegadores eran como digo potencialmente peligrosas, ya que podría descubrirse (siempre hipotéticamente hablando) un exploit a través de WebGL que a su vez pudiese interactuar con el Driver de vídeo y por ende ejecutar código malicioso en modo Kernel (muy peligroso). Esto se ha ido solucionando con el tiempo, y a día de hoy se usan incluso extensiones de OpenGL específicas como pueda serlo GL_ARB_robustness para protegerse de este tipo de posibles problemas potenciales.

Esto no elimina totalmente el potencial peligro de WebGL, y técnicamente podría encontrarse alguna combinación de shaders,  texturas, geometrías… que desestabilizasen el sistema. En realidad no por un problema del navegador en sí, sino por el propio Driver de vídeo del sistema o una mezcla de ambas cosas. Es un riesgo mínimo y hay sistemas como digo para evitarlo (para empezar unos Drivers actualizados siempre ayuda). Por otro lado hay que destacar que aunque GL_ARB_robustness es una solución muy eficaz (y realmente funciona), es una extensión de OpenGL 3.2, lo que deja fuera prácticamente por diseño a cualquier navegador bajo MAC OS (el soporte de OpenGL bajo MACOS es de muy deficiente a pésimo) y a muchos adaptadores (sino todos) de AMD. Tan solo nVidia y bajo Windows se salvan en gran medida, con lo que se puede comprender en parte el miedo de Microsoft. Repito… hablamos hipotéticamente.

 Es interesante no obstante 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=47 w=350 h=228 float=left][singlepic id=43 w=350 h=228 float=center]

  • Opera: No es capaz de representar los “planetas” en Sistema Solar

 

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, función que es llevada acabo por lo que llamamos un Garbage Collector (recolector de basura en sentido literal). Los navegadores no son una excepción a esto, y pueden producir en cortos períodos de tiempo muchos objetos nuevos debido a código JavaScript o DOM, los cuales muchos de ellos incluso son destruidos con la misma rapidez. Esto genera constantemente muchos trozos de RAM “basura” que es bueno… es necesario ir liberando. La alternativa de no usar GC (Garbage Collection) no es viable en ninguna circunstancia, sin esto el navegador no tardaría en colapsarse y agotar la RAM del sistema.

El problema de los recicladores es que son funciones/subrutinas que tienen que ser ejecutadas como es natural dentro de los propios procesos, y dependiendo del sistema GC que estén usando pueden incluso detener la ejecución del proceso por completo hasta que el reciclado se ha terminado. Esto en un navegador se traduce por ejemplo como una extrañas pausas 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.

Cualquiera que haya jugado a cualquier juego online conoce los efectos del “lag”, pues bien esto sería algo similar, donde da igual cuan potente sea el equipo, puesto si el lag es alto puedes darte por muerto. La eficiencia o no de cada modelo de GC varía. En algunos programas puede ser mejor un modelo, en otros otro. Por ejemplo se podría hacer un GC simple que cada 2 segundos ejecutase una subrutina para hacer el reciclado, pero el tiempo invertido en ese “limpiado” también variará en función de la última vez que se realizó. Podríamos ejecutar GC cada X segundos, pero cada esos X segundos casi con toda seguridad se notaría una micro pausa. Si no se ejecutase ya sabríamos que pasaría y si se  hiciese cada medio segundo a lo mejor se estaría tb produciendo una latencia y lag por el número de veces que se ejecuta el recolector… es decir, no es nada fácil dar con el mejor sistema, puesto que el mejor sistema depende de cada momento.

Este test mide este comportamiento. Genera muchos objetos a gran velocidad constantemente, y mide las pausas que se registran. Este test es muy muy sensible a cualquier otro proceso que se esté ejecutando, incluso puede afectar el movimiento del propio ratón, 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=45 w=700 h=456 float=center]

 

Test de compatibilidad HTML5 de Niels

A día de hoy un 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 estándar HTML5. En las últimas actualizaciones se le ha añadido también algunas otras características ajenas a HTML5 de todos modos. Hay que tener en cuenta que este test al margen de algunos otros añadidos y HTML5 no testea otros estándares igualmente importantes, como puedan ser WebGL, CSS, SVG…

[singlepic id=38 w=700 h=456 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=52 w=700 h=456 float=center]

  • Internet Explorer y Safari: No son compatibles
  • Opera: Aunque es compatible, múltiples test provocan cierres constantes

 

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 que se han usado aquí son exactamente los mismos, solo que yo los aplico a mis versiones de los navegadores, y no a las que aplica MS.

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. 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 es compatible, con lo que cabe esperar que Internet Explorer 10 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 estar a la altura, 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 que conscientemente o inconscientemente Microsoft comete, haciendo que IE 10 sea capaz de pasar dichos test y la competencia no. Esto no es tan extraño, pensar que muchas cuestiones de las especificaciones son totalmente interpretativas, y así por ejemplo Mozilla puede entenderlas de un modo y Microsoft de otro. Otras veces simplemente se deja abierto a elección de cada cual como hacerlo… Supongo que la mejor forma de saber quien de ellos tiene razón es mirando simplemente las implementaciones de cada uno, y si 3 lo hacen de un modo y solo es uno quien la interpreta de otro, posiblemente esos 3 tengan razón. De todos modos aquí nos basamos tan solo en los test de Microsoft tal como ellos los concibieron.

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, JavaScript…  es bastante bueno. Quizás la mejor forma de interpretar estos resultados sería eliminando a Internet Explorer de este test, lo que nos daría posibilidad de comparar realmente otros navegadores entre ellos, no contra otro que evidentemente sabemos que va a ganar (se hizo para ello).

[singlepic id=34 w=700 h=456 float=center]

  • Test realizados con la última versión del IE Center de Microsoft, actualizada a 25/10/2012

 

  Test de W3C para CSS 2.1

 Pese al bombo que se le ha dado a las futuras especificaciones de HTML5, posiblemente CSS sean especificaciones mucho más importante que los nuevos añadidos que pueda implementar HTML5. Esto es simple, CSS es usado a día de hoy prácticamente en todas las web del mundo, y cada vez se hace un uso más intensivo de este, tanto para aplicar simples estilos, a crear auténticos efectos de todo tipo.

CSS permite básicamente aplicar estilos, formatos… a cualquier parte de una web, elemento o conjunto de ella de forma que sea simple reutilizar su código, modificarlo… y como cualquier otro estándar ha estado en continuo cambio y evolución. Las especificaciones CSS 2.1 son a día de hoy ya un estándar en uso, no es como HTML5 un estándar en desarrollo, sino que esta por decirlo de algún modo publicado. Es cierto por supuesto que se continúan revisando sus especificaciones añadiendo… pero básicamente está terminado. La evolución de este sería CSS 3.0, que se encontraría en el mismo estado más o menos que HTML5, en pleno desarrollo.

En este caso, me gustaría tener tiempo material para poder lanzar un análisis exhaustivo sobre los navegadores y CSS 2.1 gracias a la suite de W3C, el problema es que hablamos de miles de test y no son automatizados, requieren una constante vigilancia. Es por ello que en esta ocasión he de optar por tomar los datos oficiales de W3C sobre estos datos, y lo que voy a exponer aquí no son pruebas personales y locales, sino los datos del último reporte de W3C. 

Los datos son simples de interpretar, existe un porcentaje de test cubiertos y otro de test cubiertos pasados. Como es porcentual, y teniendo en cuenta que la mayoría de los navegadores tienen cerca del 100% de test cubiertos, podemos usar de resultado final el porcentaje de test pasados cubiertos. Por supuesto este tendrá una pequeña desviación de error, que es menor en tanto y cuanto el porcentaje de test cubiertos sea mayor.

En el futuro intentaré poder pasar manualmente todos los test a cada navegador, puesto que los resultados del W3c no son aplicados a un navegador en particular, sino que se aplican a cada Engine del navegador, y además son acumulativos. Es decir que Safari o Chrome se le asigna el mismo valor (cuando por descontado las puntuaciones serían diferente), y por otro lado no se aplican tan solo a cada versión del navegador en particular, sino en el conjunto de todas ellas. Pese a todo, es interesante tener una visión globgal de la compatibilidad de los navegadores frente a CSS 2.1

Sobre CSS3, el test de Microsoft ya cubre parte de estas especificaciones, y en el futuro incluiré también la suite oficial de W3C de test para CSS3 (muchos de los cuales son los que usa Microsoft)

 [singlepic id=33 w=700 h=456 float=center]

 

 

 

Conclusiones

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

Resultados Firefox 20 x86 Chrome 25
IE 10 x86
Opera 12.12
Safari 6
Rendimiento 62 41 32 24 35
JavaScript 12 13 11 5 4
Canvas 13 17 14 11 5
Gráficos 28 16 23 20 7
WebGL 10 7 0 7 0
Otros 5 4 1 3 2
Compatibilidad 17 15 12 9 4
Estabilidad 5 4 2 1 4
           
Total 152 117 95 80 61

 

  • 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 de lo posible los accesos a disco, innovar en nuevos sistemas de almacenaje de datos para su rápido acceso, reducir la sobrecarga del propio OS… y sinceramente esto es una tarea muy complicada.

    En cuanto a tiempos de inicio se refiere, en este caso es Firefox quien prevalece sobre el resto casi en todas las pruebas. Esto posee una mayor importancia si recordamos que Firefox no es un navegador multiprocesado como es Chrome, lo que significa que los chicos de Mozilla están aunando un esfuerzo increíble en mejorar la respuesta general del Navegador. Chrome e Internet Explorer aunque son multiprocesados (que no quiere decir multihilos, que lo son todos) no son capaces de optimizar lo suficiente el código para estar a la par, pero exceptuando Opera que posee problemas en este caso, no tienen un rendimiento que sea muy alejado.

    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 carguen después en 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, como es natural.

    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. En esta ocasión Chrome ha mejorado en mucho el cierre del navegador, mientras que IE continúa con tiempos muy altos y muy inestables. De cualquier modo, se puede apreciar perfectamente como precisamente Chrome e IE poseen con diferencia el mayor consumo de RAM, mientras que el resto de los navegadores poseen un consumo mucho más amortiguado, llegando hasta las increíbles cifras de FIrefox. Uso increíbles porque si las comparamos con Chrome, para 10 y 20 pestañas Chrome casi duplica el consumo de RAM frente a Firefox. Tanto Opera como Safari poseen un consumo medio no obstante.

    Respecto a la carga de contenido cacheado y sin este, vemos que de nuevo Firefox vence, aunque prácticamente con unos resultados iguales a Chrome, siendo las diferencias complicadas de apreciar. Safari tampoco queda muy lejos de Chrome, e incluso IE no obtuvo unos resultados demasiado malos, sino fuese por algún que otro problema cuando no cachea el contenido.

    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, la batería y el pasado. 6 meses después, volvemos a demostrar que flash sigue siendo la opción más viable, más rápida, con menor consumo energético, con mayor rendimiento para la reproducción de contenido audiovisual. 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 notables, aunque en esta ocasión vemos que los resultados son más moderados, lo cual nos dice que posiblemente nVidia al menos habría aplicado algún tipo de aceleración hardware a sus drivers para WebM, y esto se nota. Aun así vemos que es mucho más eficiente Flash, 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 11% la GPU (en el peor de los casos), WebM llegó a necesitar en el peor de los escenarios un 13% CPU/20% GPU. sin duda alguna es una gran evolución desde la última comparativa, pero aun así Flash continúa siendo lider.

    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 y ya explicamos el por qué de usar WebM.

    Estoy convencido que en el futuro se podrá estandarizar el uso de codecs en los navegadores y que la reproducción por medio de HTML5 será tan eficaz como con Flash, pero eso será el futuro, continúa estando lejos. El proyecto WebM no será posible mientras que el soporte para este sea el que estamos viendo.

     

  • JavaScript

    Los test sintéticos JavaScript que ya conocen todos siguen siendo punto de referencia para muchos. Como ya he dicho tantas veces, 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 la primera posición en SunSpider, pero si miramos en Kraken que es un derivado de SunSpider queda lejos de esa posición.

    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.

 

  • Canvas

    He querido separar este apartado del de JavaScript, aunque en realidad están muy relacionados uno con otros. 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. Si vemos los resultados son muy variados, no hay un claro ganador porque como digo es muy dependiente del contenido del canvas. Quizás podamos afirmar que cuando Canvas posee un fuerte componente Javascript, el ganador es Opera o Chrome, mientras que si posee un componente gráfico es Firefox.

 

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

    Opera continúa por defecto con esta característica deshabilitada, aunque en esta ocasión ha logrado rebajar de forma considerable el uso de GPU que tenía anteriormente. Internet Explorer o Firefox continuan siendo lideres indiscutibles, siendo muy eficaces tanto en uso de GPU como en rendimiento general.

    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 hace algo similar que Opera, usando un backend de OpenGL Safari por contrapartida parece haber abandonado el soporte para Windows, con lo que es más que posible que jamás lo tenga. En la versión de MAC OS posee cierto tipo de aceleración, pero recordemos que MAC OS no posee ninguna API Decente de aceleración hardware 2D, con lo que estos test en MAC OS darían igualmente a Safari la última posición.

    Por último decir que la ventaja de que Opera o Chrome usen 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 e incluso Windows si se fuerza. 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

    Opera se sumó hace tiempo al carro de WebGL aunque aun no habilitado por defecto.

    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. Aun así, se ha demostrado que WebGL aun está muy lejos de alcanzar el rendimiento que se obtiene con una aplicación nativa en OpenGL.

    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 (implementación de OpenGL sobre DirectX) 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.3.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 OpenGL en la actualidad, ahora mismo creo que ya soporta en Windows 8 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.3.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 3.0 y con muchas 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.

 

  • 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. 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 cumplir 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 muchos 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. Opera se ha subido al carro y no ha empezado con mal pie desde luego, aunque en las últimas versiones no es demasiado estable.

    Microsoft optó al final por desgracia de no implementar por ahora WebGL, parece más o menos claro que antes o después lo implementará. 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 ya explicamos esto es relativo y existen sistemas para evitar estos problemas de seguridad.

 

  • Compilaciones x64

    Internet Explorer 10 ejecuta su interfaz siempre en 64 bits, siendo su chrome en 32bits o 64 bits dependiendo de si se ha habilitado el modo de seguridad avanzada, pero aun cuando habilitamos el modo nativo 64bits vemos que por fin MS se decidió a añadir sus mejoras de rendimiento a la versión de 64bits.

    Firefox continúa ofreciendo versiones diarias de 64 bits con un rendimiento muy similar a las versionese de 32 bits, manteniendo la estabilidad. Por desgracia recientemente se ha anunciado que durante un tiempo deshabilitarán las versiones de 64 bits problemas a la hora de detectar los fallos de su navegador, pero han asegurado que estarán disponibles para el año próximo.

    Opera continúa con sus versiones de 64 bits, y son bastante decentes.

    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 de los 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 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 por un exceso en el uso de la GPU, y Chrome tampoco quedaría en muy buen lugar, con cargas de CPU/GPU considerables.

    Quizás en un equipo de sobremesa el consumo energético es lo de menos, pero como siempre pensemos en portátiles.

Google I/O 2012 – En Directo

Para hacer en casa: Como agotar en minutos, de forma remota, los datos móviles de cualquier usuario de iOS (iPhone o iPad)

Animado por la cantidad de datos manipulados y/o tergiversados que Apple está enseñando estos días en su WWDC (gráficas “falseadas” constantemente) e impresionado una vez más por los 20€ que quiere cobrar a sus usuarios por una actualización de su sistema operativo (recordar que no es un OS nuevo sino actualizaciones, parches), escrito estas palabras a día de hoy, para mostrar una vez más al lector con mucha o poca idea de tecnología, lo bonito y bello que es el mundo fuera de esa secta.

Material necesario:

-Un PC con conexión a Internet
-Seleccionar de forma inteligente el tipo de paquetes a usar (desde un simple Ping a un paquete Sync TCP…)
-Unos minutos/horas (dependiendo diversos factores)
-Un objetivo con el que “experimentar”
-Tener ganas de gastar una graciosa broma “pesada”

Nota: En las pruebas realizadas, se logró un agotamiento de datos aproximados de unos 10MB/minuto sin mucha complicación

 

La idea surgió mientras me daba un relajante baño, y lo cierto es que brilla por su sencillez, no comprendo como a estas alturas no sea algo que haya visto en ningún sitio, y es cuanto menos gracioso. Antes de empezar, y prometo no extenderme “demasiado”, voy a explicar un poco más el título de este pequeño artículo, y es que hoy vamos a prender como cualquier persona detrás de un PC, una línea a Internet y poco más puede agotar en cuestión de minutos u horas (dependiendo de su conexión y del plan de datos del usuario de iPhone/iPad) los datos que tenga contratado dicho usuario. En realidad no puede aplicarse absolutamente a todos, pero sí me arriesgaría a decir que sí es posible a la inmensa mayoría de ellos.

Veamos, la inmensa mayoría de todos los usuarios que tenemos Smartphones tenemos contratado con nuestro operador una tarifa de datos, hasta aquí todo perfecto. Por otro lado, al menos aquí en España, nuestros operadores como sabéis nos asignan un límite mensual en el volumen de datos transferidos, definido por el tipo de tarifa que tengamos con ellos. Cumplido dicho límite pueden suceder dos cosas: Algunos operadores te bajan la velocidad de la transmisión de datos a niveles irrisorios (que valen para leer un correo y poco más) y otros pasado dicho umbral tarifan los MegaBytes transferidos hasta finalizar el mes.

¿Qué consecuencias podría acarrear el agotamiento de estos datos en un usuario que tenga un iPhone o un iPad? Es simple:

-En caso de que su operador le reduzca la velocidad, agotarle sus (por ejemplo) 500MB mensuales, obligándole a trabajar a velocidades bajísimas, haciendo prácticamente inservible dicho dispositivo para cualquier tarea que requiera datos. Llegado a este umbral si se continuase con este método a ahogar al dispositivo, no repercutiría en la tarifa de dicho usuario, pero sí bloquearía totalmente el tráfico de datos del usuario, hasta que el (llamémosle atacante) atacante detuviese el asalto.

-En caso de que su operador le facture el tráfico de más, a dicho usuario le podría llegar una cuantiosa factura al finalizar el mes, el límite tan solo estaría en lo bueno o malo que sea el gracioso que le quiera jugar una mala broma. A efectos prácticos dicho usuario afectado no podría rendir culpa al operador ya que como veremos no ha existido trampa por ningún lado, simplemente alguien se aprovechó del sistema, y el usuario de su dispositivo iOS tendría que pasar por caja.

-De estar el dispositivo en baterías (sin estar cargando), le estaríamos reduciendo su batería de forma drástica!! no puedo conocer de cuando estaríamos hablando, pero posiblemente en unas horas podríamos agotar por completo la carga de un iPhone con la batería al máximo, y eso solo contando el consumo de batería repercutido por el propio bombardeo.

-A corto plazo el propio dispositivo del usuario afectado funcionaría en correcto estado (salvo por el consumo masivo de datos que empezaría a acusar), pero a medio largo plazo podría ver como su dispositivo se bloquearía o comenzase a actuar de forma errática por culpa del efecto de un DoS (Ataque de Denegación de Servicio)

-Si quien realiza el asalto es ingenioso, podría bloquear la capacidad de sincronización del dispositivo de la víctima (el usuario de iPhone/iPad)  de forma simple, impidiendo que este pueda usar servicios como sincronización, iCloud… e incluso Whatapps y otros.

 

Todos sabemos de lo que estoy hablando cuando nombramos el consumo de datos, cualquiera que tenga un Smarphone lo sabe, así como su límite mensual. Lo que no sabe la gran mayoría sin embargo porque quizás nunca se ha hecho dicha pregunta, es como se contabiliza esta transferencia. En la práctica, cualquier dato que sale o llega al dispositivo cuenta, da igual que este tráfico lo haya generado el propio usuario directamente o indirectamente. Es evidente que el usuario siempre puede controlar (los usuarios de iOS no tienen prácticamente control de nada) el tráfico generado por ellos mismos, ¿pero que pasa con el tráfico generado por el exterior?

Muchos pueden pensar que el exterior no genera ningún tipo de tráfico a sus dispositivos cuando estos no lo solicitan, pero esto es totalmente falso. Es cierto que si abrimos un navegador Web estamos iniciando nosotros una comunicación de forma directa y que desde ese momento se abre un canal de comunicación el cual consumirá datos (los enviados por el dispositivo al exterior y los recibidos por parte del servidor), pero ¿qué pasaría si de forma externa intentamos conectar/contactar con otro dispositivo sin que este solicite dicha conexión? A fin de cuentas cualquier dispositivo conectado a Internet es accesible desde otro dispositivo por medio de su dirección IP como muchos saben, y aunque no sea el dispositivo quien inicie la comunicación, sería absurdo pensar que desde fuera esto no puede hacerse.

Bueno pues en esta ocasión la teoría es casi tan simple como la práctica. ¿Qué sucede si bombardeásemos cualquier dispositivo conectado directamente a Internet con paquetes de datos arbitrarios (o no tan arbitrarios)? Dado que el operador de dicho usuario contabiliza los datos que llegan al terminal (con total indiferencia de si son datos útiles o no), por cada Kb que le enviásemos le estaríamos comiendo otro Kb de datos que tiene. El concepto no es nada nuevo, y los que viven en estos lares desde hace años, quizás les suene los viejos Flood de texto del IRC, o incluso los Sync Flood. El concepto es el mismo, bombardear un dispositivo con paquetes de datos.

Esto por supuesto es algo que puede hacerse con absolutamente cualquier dispositivo conectado directamente a Internet, ¿pero que hace de este sistema realmente interesante aquí? Son dos las peculiaridades que hacen que este sistema de extenuación de datos obtenga un éxito abrumador: Tarifas de datos limitadas y la facilidad de detección de un dispositivo con iOS (ya sea iPhone o iPad). Estas dos peculiaridades hace que resulte realmente sencillo acabar en un rato con todo el consumo mensual de cualquier usuario estos dispositivos. Gracioso cuanto menos, ¿verdad?

 

Manos a la obra. Al comenzar expuse el material necesario, y lo cierto es que prácticamente cualquier usuario puede probarlo. Ni que decir tiene que no comparto la idea de fastidiar por el mero echo de fastidiar, yo expongo simplemente echos y vulnerabilidades que creo que son de gran interés, sobre todo a los propios usuarios expuestos. Tan solo hay dos puntos en todo el proceso que merece la pena deteneros, que sería el tipo de datos a enviar (y como hacerlo) y el objetivo.

 

Paquetes a usar

Podríamos enviar de forma arbitraria cualquier dato a un dispositivo por medio de multitud de herramientas existentes, pero lo cierto es que pensando un poco podemos idear/fabricar paquetes que sean más efectivos que otros.

Bien, la idea es agotar en el menor tiempo posible la mayor cantidad posible de Bytes. Si lográsemos un agotamiento de 1Byte por segundo tardaríamos más de 12 días en consumirle a ese usuario 1MB… lo cual no es viable desde luego. Y si enviamos cada segundo paquetes de 1KB? y si son de 16KB? A un consumo de 16KB por segundo, consumiríamos 1MB en tan solo 64 segundos, 10MB en 10 minutos aproximadamente… en 9 horas se abrían consumido de ese usuario 500MB.

Cual es el mejor sistema? Aquí cada cual puede optar por el sistema que crea mejor, pero si tenemos en cuenta que nuestros operadores cuentan como datos cualquier dato tanto recibido como ENVIADO, en mi cabeza solo suena una palabra: Ping. Una de las herramientas más viejas que existen y una de los más famosos. No voy a extenderme minutos u horas explicando las bondades de nuestro amigo el Ping, pero lo mínimo para entender la gran utilidad de este amigo. El Ping no es más que una herramienta que permite enviar un tipo especial de paquetes de datos ICMP llamado “Echo Request”, un tipo de paquete usado en el protocolo IP que no usa los protocolos de transportes TCP o UDP. Al igual que todos de los paquetes ICMP, se creó con el propósito de garantizar el buen funcionamiento de la red por medio de dos tipo de paquetes concretos, el Echo Request y el Echo Reply (pregunta y respuesta). La idea era simple, cuando a cualquier dispositivo de internet le llagase un Echo request, este respondería con un Echo Reply. Esto tenía dos funciones fundamentales: Saber el estado de un dispositivo de red (si está en línea o no) y conocer incluso la calidad de la red midiendo el tiempo transcurrido desde que se realiza el request hasta que se recibe el reply, puesto que cuanto menor sea el tiempo es de suponer que la red es más rápida o está menos congestionada o sufre de menor retraso.

A día de hoy, excluyendo algunos Routers o puertas de enlace residenciales, cualquier dispositivo está configurado por defecto para contestar los ICMP Echo Request, lo cual es lógico puesto que como digo estos paquetes juegan una importante labor en el mantenimiento y correcto funcionamiento de Internet. Pues bien, dicho todo esto tendríamos en nuestras manos una herramienta que no solo nos permite enviar datos a un determinado objetivo (consumiéndole la cantidad de datos que sea) por medio de un paquete Echo Request, sino que además dicho objetivo nos responderá con otro paquete Echo Reply!! eso quiere decir que sus datos se verán consumido tanto por nuestro paquete de datos enviado como por el paquete de contestación que se ha visto forzado a enviarnos de vuelta sin que él lo sepa.

Pero es que además, prácticamente todas las herramientas de Ping para generar este tipo de paquetes nos permiten especificar el payload (datos) a enviar dentro del propio Echo Request!! sin contar que el Echo Reply de vuelta contendrá también exactamente los mismos datos. Dicho de otro modo, si hacemos Ping a un iPhone especificando usar un payload de 16KB y este paquete llega a su destino, el destino nos responderá con un paquete de respuesta a nuestro Ping con el mismo Payload enviado por nosotros, co lo que en total estaríamos consumiendo al usuario 16*2=32KB simplemente enviando un Ping de 16KB. Un dos por uno, no está nada mal. Recordar que el tamaño máximo del Payload son los 64KB. Lanzar este tipo de ping es trivial en cualquier plataforma, voy a poner dos ejemplos, uno en Windows usando Ping y otro en Debian usando nPing. La única desventaja que posee Ping en Windows es que este no envía otro Ping hasta que no ha recibido el Eco de respuesta, y esto hace que se ralentice mucho el ataque. Podríamos usar nPing en Windows, pero no permite por desgracia la fragmentación de paquetes y tendríamos que usar un payload máximo que rondaría los 1500KB. De cualquier manera, ya sea usando Ping o nPing el resultado es impresionante. Por supuesto esto no es más que un pequeño ejemplo:

Debian:

nping -c 0 –icmp –icmp-type 8 –data-length 4096 –mtu 1448 –delay 50ms IP_Destino

Se estaría enviando un paquete de 4KB de datos fragmentados (dado que el MTU de las líneas DSL/cable no es más de 1500 máximo y es necesario fragmentar) cada 50 milisegundos al destino especificado, y continuaría así hasta que el usuario cancelase el asalto.

Windows:

ping -t -l 4096 IP_Destino

En este caso se enviaría un paquete de 4KB fragmentado, pero no se puede controlar con que velocidad, el sistema enviará un nuevo paquete en cuanto reciba la respuesta por parte del destino.

 

Por descontado que la primera opción es mucho más eficaz. Con la primera opción, se lograrían estar generando 20 paquetes por segundo de más de 4KB, que así mismo en teoría generarían otros tantos paquetes por parte del cliente, duplicando la tasa de datos consumida. Es decir, en este caso concreto serían 20 paquetes enviados en un segundo a 4KB = 80KB/seg, y se generarían otros tantos el otro extremo, lo que resultaría de un total de 160KB/s, 1MB cada 6 segundos y medio, 100MB cada 10 minutos aproximadamente. Esto quiere decir que en menos de una hora habríamos consumido (posiblemente mucho antes) todos los datos del mes del usuario!

En las pruebas que he realizado, en el caso de iPhone/iPad el tamaño más adecuado para el ping sería de 4KB, es capaz de devolver prácticamente todos los Echo Request a una buena velocidad. Por supuesto dependerá de la buena o mala cobertura que el dispositivo tenga. Por supuesto el tiempo que tardará el sistema en consumir al totalidad de los datos del usuario dependerá también del plan contratado, si el usuario tan solo dispone de 100MB le podríamos consumir el primer día del mes todos los datos en tan solo 10 minutos.

 

 

Que objetivo especificar

Hasta aquí ha sido todo fácil, pero prácticamente el sistema explicado anteriormente puede usarse no solo en iPhone, sino en cualquier dispositivo conectado por datos a Internet. ¿Porque hace este sistema un arma terrible contra los dispositivos de Apple? Porque como vimos en otros artículos publicados como por ejemplo el de búsqueda y captura de iPhone, Apple nos deja la puerta abierta de poder localizar de forma simple y trivial cualquier iPhone o iPad que deseemos. Por supuesto que podemos utilizar lo anteriormente dicho de forma indiscriminada, pero sería un gasto de tiempo no asumible sin conocer de antemano que dispositivo se encuentra detrás de ese objetivo. Es decir, incluso con fines experimentales podríamos estar atacando un dispositivo que es un PC, o un dispositivo Android cofigurado para no contestar paquetes Ping (con lo que se ahorraría la mitad del tráfico), o simplemente un router. En cambio, sí podemos saber con total antelación si ese dispositivo es o no es un iPhone sin posibilidad de error. El truco ya lo he explicado otras veces en el Blog, y parece que Apple no se ha enterado aun del peligro de dejar un puerto abierto a sus dispositivos, en concreto el puerto TCP 62078. Ese puerto se encuentra abierto en absolutamente TODOS los dispositivos con iOS, tanto iPhone como iPad!! Es decir, que si nos encontramos dicho puerto abierto, podemos afirmar que al otro lado tenemos un pobre usuario que no sabe la que le espera.

Aquí se abren dos posibilidades:

-Buscar indiscriminadamente iPhone e iPad escaneando Internet gracias al puerto 62078 como vimso en el artículo de búsqueda y captura
-Conocer la IP del dispositivo de nuestra víctima, y de antemanos saber si es un iPhone/iPad o verificarlo mediante el puerto abierto

 

La primera opción sería muy sencillo, para encontrar cualquier infeliz de forma rápida e indiscriminada tan solo nos bastaría comenzando a escanear el segmento de subred /24 de nuestra propio operador. Casi con toda seguridad en dicho segmento (que sería un total de 256 host) habrá al menos algún iPhone/iPad conectado a la red. Ejemplo:

A) Supongamos que la IP de nuestro teléfono es 32.104.119.125
B) Realizamos un escaneo del puerto 62078 en el segmento /24: 32.104.119.0 – 32.104.119.255

C:\Users\Theliel>nmap -Pn -p62078 -vvv 32.104.119.0-255

Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-12 03:45 Hora de verano romance
Initiating Parallel DNS resolution of 256 hosts. at 03:45
Completed Parallel DNS resolution of 256 hosts. at 03:45, 4.36s elapsed
DNS resolution of 256 IPs took 4.38s. Mode: Async [#: 2, OK: 0, NX: 256, DR: 0, SF: 0, TR: 321, CN: 0]
Initiating SYN Stealth Scan at 03:45
Scanning 256 hosts [1 port/host]
Discovered open port 62078/tcp on 77.208.119.7
Discovered open port 62078/tcp on 77.208.119.25
Discovered open port 62078/tcp on 77.208.119.42
Discovered open port 62078/tcp on 77.208.119.41

C) Como es de esperar casi de inmediato tenemos a nuestras víctimas, ya solo queda comenzar el bombardeo que estimemos oportuno

 

Aunque el primer método es gracioso y podemos ir aniquilando usuario a usuario (sería igualmente simple crear un script en Linux para automatizar todo el proceso, en una noche habríamos dejado sin datos a unos cuantos usuarios de iPhone/iPad), no sería un ataque dirigido. ¿Sería posible posible realizar este bombardeo o Flood contra un objetivo específico? Bueno, aquí el problema estaría en conocer la IP de dicho usuario, si disponemos de ella sí, de lo contrario no. ¿Y es posible conocer la IP de un usuario de iPhone sin que evidentemente nos la de? Aquí ya entra el ingenio de cada uno, y como se dice cada maestrillo tiene su librillo. Si se sabe buscar sí es posible, amen de poder usar diferentes técnicas y/o engaños para obtenerla.

Dejo simplemente algunas ideas al aire que usar sin especificar demasiado, a fin de no darle al posible “Lamer” que lea esto lo necesario para apretar un botón y listo, al menos que pierda el tiempo en buscarse las habichuelas:

-Engaños de cualquier tipo, desde un: “Tio dame el número que sale en la web www.cualesmiip.com”, pasando por entra en esta web (que es mía y registra laIP) y terminando por quiero enseñarte algo dame este dato. Os sorprendería lo incautos que son algunos, sobretodos los usuarios de Apple que precisamente por creerse eso de que sus dispositivos son segurosson los que comenten más irresponsabilidades.
-La mensajería instantánea y programas de videollamadas como Whatapps, Gtalk, Skype, Windows Live Messenger, iMeenseger/FaceTime, Viber… no es complicado gracias a estas herramientas conocer la IP del incauto usuario de iPhone, sin que este jamás sepa por supuesto que fuimos nosotros.
-Cualquier comunicación que se nos ocurra que pueda ser directa entre dispositivo-dispositivo
-En los correos electrónicos siempre hay más información de la que aparentemente hay
-…

Como siempre en la imaginación está el límite.

 

 

Como evitar en lo posible  este tipo de Floods

En primer lugar hay que tener en cuenta que no existe una solución totalmente eficaz con este problema, el propio diseño de Internet hace posible esta técnica. No quiere decir que no podamos hacer cosas para evitarlo en lo posible, pero además de no existir algo eficaz hay que sumarle que cualquier cosa que hagamos nos repercutirá casi siempre en una u otra cosa.

En primer lugar tenemos el dispositivo en sí. La mejor defensa es sin duda alguna tener un buen sistema que pueda protegernos. En este sentido vuelvo a recalcar la cutrería e inexplicable seguridad de los dispositivos de Apple dejando ya no solo el puerto anteriormente nombrado, sino otros!! A los ingenieros de Apple alguien tendría que explicarle el peligro que concierne el tener un puerto abierto al exterior. Esto muchos pueden leerlo y decir: Buaj, que más da… y a esas personas yo les diría. ¿Tu dejas la puerta de tu casa abierta? Pues esto es lo mismo. No quiere decir que un puerto abierto equivale a una muerte anunciada, pero un puerto abierto que de antemano sabemos que existe, para que se usa, expuesto al exterior y que además tan solo usa Apple para sus dispositivos portátiles, es como poner una etiqueta a sus dispositivos que ponga: “Por favor, atáquemen/Piratéemen por aquí”. Eso sin contar que Apple en cualquier momento puede conectarse a dicho puerto para lo que ellos estimen, ya que aunque sabemos que ese puerto se usa para sincronizaciones, quien nos dice que no se usa para algo más. En la práctica, Apple podría estar usándolo para lo que quisiese , y al estar abierto al exterior tendría acceso remoto siempre. En comparación, Android por defecto no posee absolutamente ningún puerto ni TCP ni UDP expuesto, del mismo modo que ningún router lo posee, ni Windows, ni Linux…

En segundo lugar, la mejor forma de acotar el problema sería que nuestro operador de datos nos proporcionase acceso a la red por medio de su red interna, es decir por medio de una IP privada. Este servicio lo usan por ejemplo a día de hoy en España Yoigo o Pepephone (este último ofrece las dos posibilidades). Si nuestro operador nos asigna una IP privada cuando estamos conectados a su red, quiere decir que TODO el tráfico que enviamos y que podría llegarnos pasa antes por sus dispositivos NAT/Firewall. Es decir, sería imposible alcanzar a los dispositivos que se encuentren dentro de esa red privada desde fuera, tan solo obtendríamos en el mejor de los casos la IP pública, y esta nos dejaría a la puerta del Firewall de la compaññía, nuestros intentos serían totalmente ineficaces. No obstante, aun cuando el usuario se encontrase en este escenario no sería invulnerable, ya que podría ser atacado desde dentro de la propia red. Cualquier usuario de su mismo proveedor podría alcanzarlo. Es decir, un usuario iPhone de Yoigo protegido por una IP Privada podría ser totalmente atacado y asaltado por otro usuario de Yoigo, pueseto que estaría conectado a la misma red privada que él, aunque en este caso el asalto tendría que realizarlo desde el propio dispositivo, y por consiguiente tb repercutiría en su propio consumo de datos. Pero el principal problema del segundo método y por el cual tan solo lo usan Yoigo y Pepehone, es que cualquier usuario dentro dentro de una red privada para su acceso a internet tendrá sus servicios muy limitados, sin contar que estarán totalmente controlados por parte de su operador. El usuario detrás de esta red no podrá usar/utilizar una gran cantidad de servicios, comenzando por cualquiera que requiera ejercer de servidor: servidores web/ftp/ssh/samba… también se saben de problemas los usuarios de iPhone detrás de estas redes en sincronizaciones con iCloud, problemas, cortes y retrasos a la hora de usar programaspor VoIP como Skype, Viber… retrasos en programas de mensajería instantánea tipo Whatapp… este es el motivo principal por el cual tan solo Yoigo y Pepephone (que yo sepa ahora mismo) proveen el acceso a Internet por medio de su red privada. El caso de Pepephone no obstante es de señalar y sinceramente de alabar, puesto que permite a sus usuarios por medio de dos APN diferentes el acceso a Internet tanto por IP ública como IP privada, es decir que es el usuario quien puede optar en cualquier momento por cualquiera de estos dos sistemas, estando la elección en manos del usuario a golpe de golpe en la pantalla para cambiar de APN. Bien por el tío Pepe!!

En tercer lugar, aquellos usuarios que disponemos de dispositivos Android podríamos sin mucha dificultad configurar el sistema para evitar al menos conexiones salientes que no deseemos, es decir en el caso de los paquetes Echo Reply, denegar su uso, impedir responder a las peticiones Ping. No se evitaría el problema, pero reduciríamos a la mitad el gasto de datos.

 

 

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.

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.