Portada
mis comunidades
otras secciones
#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.
#6:
no es por querer inflar mi ego, pero yo intuí esto hace varios meses: http://www.forosdelweb.com/f91/curiosidad-google-655669/#post2714996
Comentarios
#7 que no lo pillas, el también optimiza
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.
no es por querer inflar mi ego, pero yo intuí esto hace varios meses: http://www.forosdelweb.com/f91/curiosidad-google-655669/#post2714996
#13 corrige a #12 que corrige a #9 que apostilla a #7 que corrige a #2
Por si no quedaba claro
#2 esto H_a_ pasado
#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.
#4 Eso es, son bastantes bytes ahorrados por petición. No cierran las etiquetas y (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...
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
#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.
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.
#4, Pero eso no lo hace solo google.
En mi grupo tenemos una biblioteca de funciones js como
ge(s)
o
sa(o,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.
#12 Corrección: optimiCe en lugar de optimiZe.
#14 Según el artículo, afirma que el DTD (publicado por el W3C) de HTML (que no en XHTML) indica que cerrar esos tags es opcional.
#26 Yo me cree un "custom tag" en JSP llamado 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.
Y aún así, cada día me va más lento...
En mi pueblo lo llamo reducir el coste a base de reducir la calidad.
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.
#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.
#30 La solución es tan sencilla como tener los originales bien tabulados y solo quitar espacios, ofuscación... al subirlos.
#43 Para algo existe mod_gzip y se usa en casi todos los lados
http://sourceforge.net/projects/mod-gzip/
Cada carácter eliminado son muchos gigas al día. En google puede generar más tráfico que todo meneame.
#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.
Vale, esto a pasado de una optimización de rendimiento a una obsesión compulsiva.
#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.
Me estoy imaginando que un becario de google se da cuenta de que no se cierran las etiquetas, añade un 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.
#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.
Que listos que son los jodios...
¡No te acostarás sin saber una cosa más!
Google no "sierra"??????????
Pues tendría que ser obligatorio cerrarlas, y que penalizase si no se hace.
#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.
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.
#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.
#20 #21 Ah ok... lo de que era JavaScript me lo pase por alto así porque me dio la gana
Sorry.
Bueno entonces solo dire, eso os pasa por usar Javascript (no me gusta nada, que le voy a hacer jejeje)
#27 Si omitir y el cierre de está soportado en HTML 4, ¿qué más da? Si con ello se puede hacer un ahorro significativo, adelante.
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.
Tiene sentido, pero se podría ahorrar también otros 3 caracteres por cada petición eliminando el www, como lo hace por ejemplo menéame...
#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)
#14 Estás insinuando que Microsoft podría hacer lo mismo que Google... a la hoguera con ambos!! Viva Godgle!
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...
#12 ¿Que no optimiza? ¡Se ahorra un acento entero!
#18, sacrifica rendimiento, pero ahorra tráfico de red. Buena práctica según pa qué
#20, conexiones GPRS con cobertura intermitente, y modem. Prima agilizar la descarga sobre todo lo demás.
Si el único propósito que tiene es enviar un "" 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.
#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.
Google dominará la tierra.
#47 Nuestro pastor y nada nos falta.
¿Google? ¿Quién es google?
Genial, nunca me había parado a pensar en el peso de todos estos elementos para un sitio como Google.
#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.
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.
Es un html de primeros de los 90.
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.
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.
vaya, no sabia que haxia legible el html y xml. De todas formas no se, es una buena costumbre que no cuesta nada hacer, como cerrar tags
#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.