278meneos
Google no cierra sus tags HTML, a propósito [ENG]
blog.bug.gd/2009/06/27/the-highest-traffic-site-in-the-world... por nade el 29-06-2009 08:06 UTC, publicado el 29-06-2009 10:10 UTC
Por lo visto lo hace para arañar unos cuantos milisegundos a la carga de sus páginas.
¡No te acostarás sin saber una cosa más! :)
#9 puede que #7 optimize, pero eso a ti no te sirve para escribir "el" en lugar de "él" xD
#4 tiene mucha razón, pueden precer insignificantes, pero teniendo en cuenta el ancho de banda que usa google, seguro que eso se traduce en un ahorro de miles de dólares al mes.
Por si no quedaba claro xD
En mi grupo tenemos una biblioteca de funciones js como
ge(s){return document.getElementById(s);}
o
sa(o,n,a,v){o.setAttributeNS(n,a,v);}
Vamos, programamos normalmente y luego pasamos el código por una especie de ofuscador que lo reduce enormemente, pero dejando algo medio legible.
De todas formas, seguro que ellos lo tienen muy bien estudiado, pero yo pensaba que saltarse tags aumentaba el coste de la carga, pues el navegador tendría que buscar donde cerrar estos tags.
Yo en mis webs cerraré tags que nunca he abierto, solo para joder xD
EDIT:
#17 Pero esa práctica es positiva, lo importante es guardar las fuentes. Lo que sería equivalente a lo que hace google es que te dejaras las llaves de cerrar funciones antes de declarar unas nuevas... claro que eso el navegador no te lo permite hacer.
#20, conexiones GPRS con cobertura intermitente, y modem. Prima agilizar la descarga sobre todo lo demás.
Pero vamos, no entiendo cómo Google puede proclamarse protector de los estándares y no aplicarlos a ninguno de productos. Ni uno pasa el test de la W3C, ni su simplista página web.
;)
Yo tuve mi época de limpiar los espacios en blanco en todos los html y css que escribía pero, total, por una milésima de segundo no me voy a tirar ahí tanto rato para nada.
Pues que eliminen los espacios en blanco que no son estandar, pero no las etiquetas.
#6
Cambiar la b por strong no deberia hacerse, aunque es cierto que la hace la mayoria de la gente (aunque estos no lo hagan por velocidad, si no porque ni siquiera saben que existe "strong" y cual es la diferencia de una a otra)
Sí, la calidad del código, que no se ajusta a un puto estándar -aunque el navegador trague, que no debería, verás tú cómo se hacía código de calidad-.
Las cosas bien hechas bien parecen.
La pregunta es, ¿y esto pasara a ser estándar o aceptado por la W3C?
Prefiero la idea de comprimir las paginas en su envío y que el navegador las descomprima con gzip, al menos se rige al estándar que empezamos así y acabamos con cosa inteligibles y el xhtml se ideo para evitar eso.
#14 No se salta el estándar, usa HTML y no XHTML. En el HTML no es obligatorio cerrar todos los tags, mientras que en XHTML, al ser un subconjunto de XML, es obligatorio. C&P de la wikipedia:
Las diferencias entre HTML y la primera generación de XHTML (es decir, XHTML 1.x) son menores ya que, principalmente, están destinados a conseguir la conformidad con XML. El cambio más importante es el requisito de que el documento esté bien formado y que todas las etiquetas estén explícitamente cerradas, como se requiere en XML.
Es un html de primeros de los 90.
En lugar de enviar HTML en texto plano porque no usar un html.gz comprimido que se descomprima en el cliente?
La diferencia de velocidad y consumo de ancho de banda sería bestial. Hoy en día el procesamiento para descomprimir texto plano es rapidísimo, sobretodo en gzip.
sourceforge.net/projects/mod-gzip/
#43 Ya se suele hacer la compresión gzip. Google supongo que lo hará en servicios que le compense ya que hay que tener en cuenta que la compresión tiene unas cabeceras que también pesan algo.
También se ahorra tiempo enviando todos los archivos javascript y CSS compilados en un sólo archivo. Este archivo se puede crear automáticamente a partir de las fuentes y así en vez de por ejemplo 10 conexiones haces sólo 2 o 3.
Pero entonces la diferencia al eliminar el cierre del tag es aún más insignificante. Curioso que aun así compense.
Bueno entonces solo dire, eso os pasa por usar Javascript :P (no me gusta nada, que le voy a hacer jejeje)
#31 y #37 Entonces rectifico lo de saltarse el estándar a la torera. Pero sigo pensando lo mismo del resto de la frase.
De todas formas, me parece una cosa bastante "guarra". Si se utiliza compresión gzip supongo que no se ahorrarán tantos bytes como se ahorrarían en texto plano. Pero está claro que cualquier optimización, por pocos bytes que sean, no les viene nada mal para reducir el caudaloso tráfico que generan.