#3#1 Es que al no cerrar los tags, por la noche le entra frio a google y se pone constipado. Seguro que tambien anda descalzo por la casa para no ponerse las zapatillas.
#4#2 Cierto, se trata de milisegundos y ahorrarse unos pocos bytes en cada petición, pero con la carga (número de peticiones por segundo) que tienen, seguro que ahorran un huevo en transferencia de datos.
#5#4 Eso es, son bastantes bytes ahorrados por petición. No cierran las etiquetas <html> y <body> (12 bytes), y eliminan todos los espacios en blanco y saltos de linea innecesarios. Con los espacios en blanco y saltos de linea se ahorrarán mucho más que con ese par de etiquetas...
#12#6, creo recordar que esto ya se hacía hace más de una año. #9 puede que #7 optimize, pero eso a ti no te sirve para escribir "el" en lugar de "él" #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.
#14 Eso en mi pueblo es saltarse el estándar a la torera... Pero como lo hace Google, es cool. Si lo hiciera el buscador de Microsoft... otro gallo cantaría.
#18 Pues a mi no me parece una buena práctica, lo haga Google o lo haga Jesucristo en su web oficial. Como bien dice #14, como lo hace el dueño de internet, pues no pasa nada.
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
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#17 ¿refactorin a lo gochuzo? ¿para qué si puede saberse? El nombre de los metodos no es que importe demasiado a la hora de compilarlo... Y francamente, no creo que un mega arriba o abajo en texto sea tan importante, cuando en un proyecto grande lo que pesa no es precisamente la letra.
#21#20 Pues la técnica que comenta aquí el compi puede ahorrar un 67% de peso en los archivos javascripts; que además, no son compilados, sino que son interpretados directamente por el navegador.
#23#18 Dí que sí, la página de Google es un parche mal parido. El código debe ser horrible de mantener, deben usar herramientas automatizadas.
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.
#25#12 Realmente ocupa menos el que él, el vs él y si lo pones sin hacerlo de esta manera es ascii vs ascii extendido, de todas todas el ocupa menos que él.
#26 Tiene bastante sentido. Y no sólo es cuestión de cerrar etiquetas, sino usar b en lugar de strong, y similares, además de no declarar el documento y, como traca final, la famosa limpieza de espacios en blanco, que es, quizá, una de las cosas que más desacelera la velocidad de carga.
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.
#27#5
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)
#29 Por lo tanto ninguna pagina de Google puede pasar los criterios de la W3C XHTML estricto.¿no?
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.
#30 lo siento pero yo un código sin espacios en blanco y tabulados me parece un infierno. Mientras que el código de mi web lo tenga que retocar yo no pienso quitar ese tipo de cosas, más que por mala leche por legibilidad. Es una buena costumbre que habría que arraigar, que luego ves unas cosas que dan dolor de estómago.
#31#26 Yo me cree un "custom tag" en JSP llamado <t:trim> que simplemente eliminaba los espacios en blanco innecesarios.
#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.
#34 lo se, pero si, por ejemplo quiero hacer cambios con algun complemento de firefox de forma no permanente como firebug, o cosas así, prefiero ver el código tabulado y con espacios.
#35 334 Firebug te "formatea" el html para hacerlo legible. Por ejemplo, menéame quita todas las tabulaciones y usa renglones kilométricos (un tag siempre es de una línea), pero con firebug se lee bastante bien. Otra cosa es la ofuscación del JS...
#40 Pues dudo que sea por optimización, si así fuera, no usarían javascript intrusivo en cada link, las funciones JS no las embeberian en el mismo HTML, o sacarían el CSS a un archivo aparte, eso si que ahorraría de verdad.
#41 Me estoy imaginando que un becario de google se da cuenta de que no se cierran las etiquetas, añade un </html> y genera tal sobre coste que hace quebrar la compañía, amen de producir toneladas de CO2 y elevar la temperatura de la tierra dos grados.
#43 Debería modernizarse el protocolo.
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.
#45#12 Sin acentos puedes codificar el texto en 7 bits ahorrando un bit por caracter.
#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.
#46#44#45 ¡Caray! no lo sabia, gracias.
Pero entonces la diferencia al eliminar el cierre del tag es aún más insignificante. Curioso que aun así compense.
#50#24 No, no insinuaba eso. Está claro que cualquiera podría hacerlo... ¡generemos código feo!
#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.
#51 Si el único propósito que tiene es enviar un "</html>" de menos me parece una tontería. Al principio pensé que sería por algún detalle técnico, pero si es simplemente eso, pues lo dicho.
blog.bug.gd/2009/06/27/the-highest-traffic-site-in-the-wo... 
¡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"
#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
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
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
#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.