Desarrolladores vs. Administradores de Sistemas

Como algunos ya sabéis yo de formación soy Administrador de Sistemas, aunque en general estos últimos 10 años me he dedicado principalmente a desarrollar. Pero estos últimos meses (principalmente desde principios de año) estoy dedicando la mayor parte del tiempo a dirigir y organizar proyectos y, sobre todo, a ejercer de SysAdmin. Como decía, había tenido ya experiencia en combinar ambas historias, pero en general la parte de sistemas siempre venía respaldada por alguien y yo “intentaba mirar” en vez de trabajar.

Ahora eso ha cambiado y me ha llevado a plantearme estos dos estilos de vida conjuntamente y por separado. Y es que he de decir que, aunque sea un trabajo algo más duro el de Administrador de Sistemas, no cabe duda que en general la satisfacción personal es mucho mayor.

La cuestión es que en el día a día, el desarrollador suele encontrarse puntos de dificultad pero que creo que son relativa. Una cosa clara, hablo de desarrollador y no de maquetador, que es otra historia (esto sí que hace ya un par de años que intento no tocar ni una línea de código). Volviendo al tema, desarrollar, hoy en día es muy sencillo. Que conste que yo sigo programando con el Notepad++ y sin frameworks ni mierdas varias de esas. Podemos discutirlo, por ahora siempre he ganado yo; los frameworks se supone que te han de aliviar el trabajo pero, cuando luego voy a pedirles algo a los desarrolladores que hagan un cambio se vislumbra el drama porque “eso lo hace el framework así y tocarlo es complicado”. No, no es complicado, simplemente sobrecargas la función, o creas una función nueva y se acabó, porque si te digo que eso ha de ser así (por SEO, por WPO, por eficiencia o por lo que sea, es así). También he de reconocer que en general desarrollar depende de cada uno. Cuando pasan años y veo algún trozo de código que he hecho yo lo reconozco al momento. Supongo que mi código tiene mi firma. Para acabar, también creo que la parte de desarrollo, aunque siempre hay alguien presionando por “las fechas” es algo que puede llegar a ser muy laxo, porque simplemente cuando vas a comenzar el desarrollo, te sobras con unas cuantas semanas de más y tan a gusto.

En cambio la administración de sistemas es bastante distinta. En general hay dos tipos de actuaciones: el “ha petado todo” y el “hay que actualizar”. En general las dos situaciones son bastante mierdas. Cuando falla algo, normalmente hay que arreglarlo “para ya”. Esto implica unos niveles de estrés bastante duros ya que sueles tener a moscas cojoneras molestando y revoloteando a tu alrededor. Por desgracia la gente no parece percatarse de que en la mayoría de los casos cuando algo falla tú ya te has dado cuenta porque te han llegado 10 correos avisando de que nosequé está fallando.

La otra situación, la de los mantenimientos tiene su parte positiva y su parte negativa. La positiva es el I+D. La evolución en la parte de la programación suele producirse cada unos pocos años y los saltos no son muy grandes (yo podría programar con lo mismo que aprendí en 2001) pero en cambio la parte de infraestructura suele ser distinta. Las máquinas van evolucionando cada poco tiempo (cada 6 meses suele haber servidores más potentes) y hay que ir adaptando el software al hardware para sacar el máximo provecho.

Por poner un ejemplo, en estos dos últimos meses que he podido ponerme un poco más a fondo con Varnish creo que he hecho hasta 5 versiones nuevas de la configuración. A veces es un simple cambio de una cifra, otras veces es añadir una funcionalidad completamente nueva, pero en cualquier caso pueden llegar a ser varias horas (o días) dedicados a intentar rascar un poco de aquí y de allá para que todo funcione mejor. Yo no conozco a muchos programadores que tras acabar un proyecto vuelvan a abrir el programa y se revisen el código en busca de mejoras (y que conste que me incluyo, aunque sí que de tanto en tanto me pongo a revisar código para optimizarlo de alguna manera).

Sé que muchos lusers #BOFH no van a entender la mitad de lo que digo (ni falta que hace) pero creo que necesitaba desahogarme un poco después de unos días en los que entre unos (desarrolladores) y otros (administradores) están acabando conmigo…

RFC6596: The Canonical Link Relation

Una de las maravillas de Internet es que cuando algo se va a estandarizar acaba convirtiéndose en un “RFC”. Estos documentos, cuando se aprueban, son las bases para crear un montón de cosas. Por ejemplo tenemos el RFC1945 Hypertext Transfer Protocol – HTTP/1.0, el RFC2616 Hypertext Transfer Protocol – HTTP/1.1 o el RFC5988 Web Linking que son los documentos (aburridos, eso sí) en los que se especifica prácticamente el funcionamiento de “las webs”.

Pues ahora ha aparecido el RFC6596: The Canonical Link Relation en el que se habla sobre el “famoso” rel-canonical propuesto por Google hace ya un tiempo y que prácticamente todos los buscadores y otros servicios ya utilizan. Es importante este documento porque, aunque por ahora son recomendaciones, establecen una serie de cosas que se estandarizan con el resto de documentos estándar de Internet.

El canonical se plantea como un nuevo tipo de relación para designar los IRI (Internationalized Resource Identifier) como preferente sobre recursos con contenido duplicado.

Para comenzar, el canonical ha de identificar una URL original (de la duplicada) o una suprapágina que incluya todos los contenidos desde los que son enlazados.

  • Página índice del contenido IRI.
  • Consolidar distintas URL del IRI.
  • Mostrar la página como la representativa del IRI.

La URL que ha de aparecer en el rel-canonical ha de ser:

  • Una URL relativa.
  • La propia URL (auto-referencia).
  • Una URL de otro hostname/dominio.
  • Con un esquema distinto (http, https, ftp…).
  • Una suprapágina (ver a continuación)
  • La URL de la página a la que se haría una redirección (302, 33 o 307).

El caso de las suprapáginas es un caso especial. La idea es que si tenemos un artículo que está dividido en varias páginas, pero tenemos una página donde está todo el contenido, se podría apuntar a esta. Es decir, si tenemos una “pagina-1.html”, “pagina-2.html” y “pagina-todo.html”, el página-1 y página-2 podrían apuntar a página-todo ya que es una página que dispone de toda la información del resto. En cambio, la página 2 no podría apuntar a la página 1, ya que la primera no dispone de la información de la segunda.

Para asegurarse de que las máquinas lo entienden, el canonical ha de:

  • Sólo puede haber un rel-canonical por página, ya que no se considera que pueda haber más de una URL con autoridad.
  • No se debe usar cuando la redirección es permanente (para ello usar una redirección 300 o 301)
  • Una URL que apunta a otra URL que no sea ella misma (es decir, que no se pueden hacer “múltiples saltos” a través del canonical).
  • No se puede apuntar a una página que devuelve un código 4xx (o sea, que la página no existe).
  • Como decía antes, las multipáginas no pueden apuntar a la primera de ellas, ya que se perdería la información de las siguientes.

En el caso de que se haga un uso impropio de estos casos, el canonical será ignorado como si no existiera.

Implementaciones actuales:

Sin duda que el rel-canonical se convierta en un estándar y que venga documentado de la forma que viene documentada da pie a hacer un muy buen uso del mismo y aclarar ciertas dudas que se producían con el mismo.

Velocidad del Sitio en Google Analytics

Lo que al principio había que añadir de forma manual al código de Google Analytics desde hace meses es ya una funcionalidad integrada. Los que revisáis el WPO de vuestro sitio sabéis que en Analytics existe la pestaña de Contenidos -> Velocidad del Sitio pero que estos datos son “poco fiables”.

Voy a poner un poco más de situación. Hoy en día hay 3 lugares en Google para hacer mediciones de tiempos de carga. El más antiguo es el de Webmaster Tools, dentro de Salud -> Estadísticas de rastreo. Aquí hay 3 gráficos, y el último hace referencia al Tiempo de descarga de una página (en milisegundos). Esta gráfica viene a ser el tiempo que Googlebot tarda en llegar a tu sitio, descargar el contenido e irse. Esta cifra debería estar por norma general entre los 200 y 500 milisegundos para ir bien, y como muy alto sobre los 1.000 milisegundos (es decir, 1 segundo). Esta gráfica sobre todo es sensible a problemas de conectividad.

El segundo lugar donde encontramos información sobre el estado de la velocidad de carga es también en Webmaster Tools, pero en la pestaña Labs -> Rendimiento del sitio. En este caso los datos son muy poco fiables ya que las estimaciones se toman según datos de la Google Toolbar. Teniendo en cuenta que la Toolbar hoy en día no existe oficialmente para Chrome, Firefox o Opera, el tipo de usuario que nos deja es el de Explorer, que es alto, pero ya no es tan significativo. Estos datos por lo tanto son muy poco fiables ya que en general las cifras están muy hinchadas.

Para acabar tenemos la opción más razonable y fiable, ya que los datos lo aportan los propios usuarios que navegan por el sitio web, y son “la realidad” del sitio (ni mediciones genéricas de barras, ni del propio Google). Como decía, esta información está en Contenidos -> Velocidad del Sitio. Aquí tenemos muchos datos:

  • Tiempo medio de carga de página: Este es el tiempo desde que se lleva la petición hasta que la página queda cargada completamente (con imágenes, publicidad y todo).
  • Tiempo medio de redireccionamiento: Este es el tiempo que se lleva desde que se pide la página hasta que se empieza a descargar la información de la página final. Si hay páginas intermedias que redireccionan, se cuenta aquí.
  • Tiempo medio de búsqueda de dominio: Es el tiempo que se lleva la búsqueda de las DNS para una petición. Si hay muchas peticiones DNS distintas, el tiempo se eleva.
  • Tiempo medio de conexión de servidor: Es el “famoso” connect. Va relacionado con la configuración del servidor y la conectividad.
  • Tiempo medio de respuesta de servidor: Es el “famoso” waiting. Suele ir relacionado con el tiempo de proceso de la página, de caché y de comienzo de envío.
  • Tiempo medio de descarga de la página: Es el “famoso” send. El tiempo que va desde que se manda el primer byte hasta que se manda el último byte del contenido.

Hay dos temas a tratar con esta información. La primera de ellas es que os recomiendo hacer comparativas por país. En general los datos varían muchísimo dependiendo del país desde el que el usuario se conecta. Por ejemplo, si tu sitio web en general es para españoles en España y tienes tus servidores físicamente en España, es probable que los tiempos sean muy bajos; en cambio, si filtras el tráfico por México es probable que los tiempos se disparen. Esto básicamente es por un tema de física (sí, de eso que te enseñan en el cole y que piensas que nunca usarás) ya que por mucha velocidad de la luz que lleve la fibra óptica, desde España hasta México hay muchísimos kilómetros de cable que hacen que “todo vaya más lento” (lento puede ser tranquilamente 1 o 2 segundos, nada más).

Otro tema importantísimo: los datos que se recogen suelen rondar el 1% de las visitas, por lo que la muestra suele ser bastante pésima. Pero esto tiene una solución bastante clara: hay que decirle a Google que la muestra sea mayor. ¿Cómo se hace esto? Añadiendo una pequeña línea de código más al código de Google Analytics (esto que os pongo es para el asíncrono) de forma que haga un muestreo mayor. Para decidir qué porcentaje hay que poner, hay que hacer un cálculo más o menos basado en unas 100.000 visitas/día (que es la cifra que documenta Google). Si tienes hasta 100.000 visitas/día puedes marcar un muestreo del 100%. En caso de tener más pues la idea es que la muestra sea siempre de aproximadamente 100.000, es decir, que si tienes 200.000 visitas/día la muestra debe ser del 50%, si tienes 1 millón de visitas/día pues del 10%.

_gaq.push(['_setSiteSpeedSampleRate', 100]);
_gaq.push(['_trackPageview']);

En este caso el “100” que aparece en la variable setSiteSpeedSampleRate hace referencia al porcentaje de muestreo. Personalmente no os recomiendo que os paséis de poner las cifras que os he dicho porque Google parece estar controlando bastante la cantidad de información que se recoge y quién hace un uso excesivo (recordad que hay unos términos y condiciones de uso, y que si os pasáis os pueden dar un toque de atención).

Otra pregunta interesante que se os puede estar pasando por la cabeza es… ¿de dónde saca Google estos datos? Pues depende de varias cosas, principalmente del navegador. Hay datos que los saca directamente de la Resource Timing API. El resto los saca de las mediciones que hace el propio navegador (de ahí que esto sea sólo un muestreo y no fiabilidad del 100%).

Ahora que sabes cómo medir los tiempos de carga de tu sitio web ¿no vas a dedicar unos minutos a optimizar algunos de ellos?

WebPerf Barcelona: Magento

Este jueves (pasado mañana) tenemos de nuevo evento de Web Performance, en esta ocasión para Magento. Una vez más contamos con la colaboración de La Salle donde contaremos con dos ponentes que tratarán la optimización de este, muchas veces, problemático (en cuanto a rendimiento) software de comercio electrónico.

El evento, como decía, será en La Salle Barcelona, de 19:00 a 21:00 en la sala de actos de la facultad de Arquitectura (Edifici St. Josep – Auditori, Quatre Camins 2). Te puedes apuntar para asistir de forma gratuita.

Los ponentes son Manel Doménech (SysAdmin de Onestic@onestic) y Jordi Rosell (Einnova@jrosell) que nos explicarán los entresijos de este sistema y cómo optimizarlo. Entre otros temas que se tratarán, tenemos:

  • Rendimiento de Magento
  • Magento y Cloud
  • APC y Memcached
  • Combinación JS y CSS
  • Ineficiencia en módulos
  • Configuración de infraestructura
  • Uso de caché
  • Eliminar consultas innecesarias
  • Cuellos de botella con xhprof

Para aquellos que no puedan asistir (porque la distancia no lo permite o porque quiere ver el partido de la Eurocopa) se podrá seguir en directo por streaming. También se puede seguir el evento por twitter desde @WebPerfES y por el hashtag #webperf, a quién también podéis dirigir preguntas y/o consultas a los ponentes.

SEO, los NewgTLD y tirar el dinero

Hoy la ICANN ha presentado lo que va a ser la revolución de Internet: nuevos dominios. Me hace gracia esto, porque se han presentado más de 2000 solicitudes (de las que han quedado algo más de 1900 finalmente) y, digo que me hace gracia porque esta “revolución” ya la vimos hace algunos años con el lanzamiento de dominios genéricos como los INFO, BIZ, NAME o PRO.

A ver, dentro de lo que cabe, y teniendo en cuenta que Internet es un mercado capitalista, no me desagrada que una empresa pueda “comprar” su propia extensión de dominio, pero con cabeza. Tiene muchísimo sentido un .GOOGLE, creando cosas como search.google, o mail.google. De la misma forma veo servicios similares con un .BING, un .EBAY o un .TWITTER, pudiendo tener tu javiercasares.twitter como cuenta personal. Empresas como .NOKIA podrían tener su 3210.nokia (una web que tendría un peso muy grande en la historia de Internet si se hubiera creado cuando apareció ese gran terminal).

Otra posibilidad interesante viene en algunos dominios más o menos genéricos que puedan convertirse en un dominio más. Por ejemplo los .BLOG, los .ART y similares, que podrían venderse por 10 euros (o 100 euros) y ser un dominio “más”. Siempre con cierta lógica.

Pero cuando ya nos vamos a organismos gubernamentales e incluso no gubernamentales creo que la cosa se desmadra. Y antes de explicar porqué voy a poner un pequeño listado de los dominios que se han pedido desde empresa/organismos españoles:

.BARCELONAMunicipi de Barcelona
.BBVABANCO BILBAO VIZCAYA ARGENTARIA
.BCNMunicipi de Barcelona
.CATALONIAGeneralitat de Catalunya
.EUSPuntueus Fundazioa
.GALAsociación puntoGAL
.LACAIXACAIXA D’ESTALVIS I PENSIONS DE BARCELONA
.MADRIDComunidad de Madrid
.MANGOPUNTO FA
.MOVISTARTelefónica
.SEATSEAT
.SENERSener Ingeniería y Sistemas
.TELEFONICATelefónica
.TERRATelefónica
.ZARAINDITEX

Puedo entender que BBVA o La Caixa quieran sus dominios, sobre todo por un tema de ofrecer seguridad y evitar problemas de phishing, si no es por eso, es tirar el dinero. Puedo entender que galleos y vascos quieran sus dominios “culturales”, al igual que ha ocurrido en otros casos, como el .CAT. Entiendo que Telefónica, como empresa líder de Internet los quiera, aunque sólo sea por darles un juguete a la gente de I+D, puedo, y aquí ya empiezo a tener muchísimas dudas, entender lo de Zara y Mango, aunque no les veo ningún sentido, la verdad, pero donde ya me rasca es MADRID, BARCELONA, CATALONIA y BCN. Lo siento, pero que estén jugando con mis impuestos es que me supera. A mi me da igual lo que digan los políticos (con que no se han gastado -que no invertido- dinero en solicitarlos) pero por si no lo saben, mantener un dominio en línea es muy caro. Puede suponer millones de dólares anuales en infraestructura y en que sea decente. Otra cosa es… ¿tendré derecho a usar un dominio .BARCELONA o .CATALONIA como catalán que soy? Se ha solicitado un dominio “porque sí” sin explicar el porqué. Querer tener el .CATALONIA sólo para promocionar Catalunya me parece un engaño de los políticos, porque… ¿se creen que va a posicionar mejor en Google o qué? Tengo experiencia (demostrable, con papeles) de la inoperancia, ignorancia y agujeros financieros que han dejado algunos políticos responsables de la solicitud de alguno de estos dominios.

Haciendo un inciso: los nuevos dominios NO VAN A POSICIONAR MEJOR. Y no lo digo yo, lo dice ya hasta Google.

Ahora, para cambiar un poco de tema pero seguir en la línea, me he entretenido un rato y me ha hecho gracia sacar una lista de los dominios que han solicitado algunas empresas:

  • Google: グーグル (Google en japonés), BOOK, CLOUD, GLE, GMAIL, GOOG, GOOGLE, GUGE, NEXUS, ANDROID, BOO, EST, FOO, LOL, SITE, SRL, STORE, WEB, ARE, DAD, DOCS, GMBH, HOW, NEW, PAGE, YOU, CAR, CHROME, FAMILY, FYI, GBIZ, ING, PLAY, RSVP, 谷歌 (Google en chino), BUY, DCLK, FLY, FREE, KID, MAIL, SEARCH, TEAM, APP, CPA, DDS, DEV, DRIVE, FILM, GAME, MOTO, SHOP, CHANNEL, CORP, DAY, EAT, HOME, MED, MOM, SOY, SPOT, DOG, DOT, EARTH, ESQ, HERE, MOVIE, PLUS, VIP, AND, GOO, INC, LLP, MOV, PHD, TUBE, WOW, BABY, LLC, MAP, PROF, SHOW, TALK, TOUR, YOUTUBE, みんな (“todo el mundo” en japonés), DIY, HANGOUT, LOVE, MBA, PET, TECH, ZIP, ADS, BLOG, CAL, FUN, LIVE, MEME, MUSIC, PROD
  • Amazon: AMAZON, APP, AUDIBLE, AUTHOR, AWS, BOOK, BOT, BOX, BUY, CALL, CIRCLE, CLOUD, COUPON, DEAL, FIRE, IMDB, KINDLE, PRIME, SILK, ZAPPOS, DEV, DRIVE, FAST, FREE, GAME, GOT, GROUP, HOT, JOT, JOY, KIDS, LIKE, MAIL, MAP, MOBILE, MOI, MOVIE, MUSIC, NEWS, NOW, PAY, PIN, PLAY, READ, ROOM, SAFE, SAVE, SEARCH, SECURE, SHOP, SHOW, SMILE, SONG, SPOT, STORE, TALK, TUNES, VIDEO, 亚马逊 (Amazon), 家電 (“electrónica de consumo”), 通販 (“compras online”), 食品 (“comida”), アマゾン (Amazon), クラウド (cloud), ストア (Store), セール (Sale), ファッション (fashion)‚ ポイント (point), 書籍 (book), TUSHU, WANGGOU, WOW, YAMAXUN, YOU, YUN, ZERO
  • Apple: APPLE
  • FIAT: FIAT, ALFAROMEO, LANCIA, MASERATI, FERRARI, ABARTH
  • Intel: INTEL, ULTRABOOK
  • Microsoft: AZURE, BING, DOCS, HOTMAIL, LIVE, MICROSOFT, OFFICE, SKYDRIVE, SKYPE, WINDOWS, XBOX
  • Symantec: ANTIVIRUS, CLOUD, NORTON, PROTECTION, SECURITY, SYMANTEC
  • VeriSign: كوم (.com en árabe), ком (.com en cirílico), कॉम (.com en deva), नेट (.net en deva), 大拿 (.net en hans), 点看 (.com en hans), 點看 (.com en hant), 닷넷 (.net en hang), 닷컴 (.com en hang), קוֹם (.com en hebreo), コム (.com en kana), คอม (.com en thai)
  • Intel: FLICKR, YAHOO
  • GoDaddy: CASA, GODADDY, HOME

Creo que de los más listos hay que destacar Verisign, que lo que hace es ampliar el mercado de los .COM y .NET a otros tipos de codificación.

En fin… Google en su línea de querer quedarse la mayor parte de dominios, y sobre todo, en la lista de dominios presentados mucho, pero que mucho “abusón” que quiere hacer negocio creo que en gran parte del todo por el todo.

Eso sí, tengo ganas de ver esos que se gastan 1 millón de dólares para montar la infraestructura de los .CASINO y que luego no les funcione el SEO… a ver cómo se ponen a llorar (aunque supongo que como estarán podridos de pasta, les dará igual).

SEO y textos alternativos

Decenas de veces te habrán dicho que si quieres posicionar imágenes en Google hay que poner bien los textos alternativos (el famoso “alt”) en las imágenes. Pero ¿es esto cierto? ¿Cuándo y cómo hay que usar los textos alternativos?

Ahora que llega el HTML5, el W3C, organismo que establece los estándares de los sitios web, han planteando un documento llamado técnicas para ofrecer textos alternativos útiles en el que se explica con bastante detalle el cómo hay que redactar esos textos y en qué casos.

Hay que tener presente que los textos alternativos se plantearon inicialmente como una forma textual que representa a las imágenes (pero no al contenido del mismo). Básicamente estos textos aparecen cuando el “lector” no carga la imagen (lo que incluyen navegadores sólo-texto, robots de búsqueda, reconocimiento de voz…).

Para comenzar, nos ofrecen algunas buenas prácticas básicas:

  • Ha de ofrecer la misma información que el contenido de la imagen.
  • Si una imagen ofrece una función específica (como un enlace gráfico) hay que describir esto.
  • Debe ser un texto breve / conciso.
  • Hay que escribir según el contexto. Una misma imagen puede tener distintos textos según se use.
  • Evitar texto redundante que pueda haber en otros puntos de la página.

Pero, aunque hay estas buenas prácticas, también hay una serie de “obligaciones” (entre comillas… digamos que recomendaciones requeridas):

  • Cuando un enlace es sólo una imagen: La imagen como texto alternativo sería el texto que pondrías en el enlace si no hubiera esa imagen.
  • Gráficas (diagramas, mapas, etc…): Como texto alternativo describiremos el proceso, los datos o la localización según corresponda. Puede ser un texto “largo”. También se puede enlazar a una parte de la web donde haya un bloque que incluya la descripción (en este caso sí que se vería en otra parte de la web).
  • Texto en imágenes: pues casi ni que decir que el texto alternativo es el mismo texto de la imagen.
  • Imágenes decorativas: Simplemente se deja en blanco el texto alternativo, ya que eso no aporta nada.

Otra opción interesante en general es que si queremos proveer mucha información sobre una imagen relacionarla de alguna manera con un enlace en el que se informe concretamente de lo que es o hay en ella.

En aquellas imágenes a las que no hay que prestar ningún tipo de atención (por ejemplo un pixel que cuenta visitas o similar) hay que indicar como alto y ancho de la imagen 0, y el alt debe ponerse pero debe estar en blanco.

En el caso de los iconos podemos encontrarnos varias situaciones. Por ejemplo, si un icono va acompañado del texto / enlace al que hace referencia el propio icono, en este caso deberíamos dejarlo en blanco. En cambio, si el icono va acompañado de un mensaje más largo, el icono sí que podría llevar un indicativo de qué significa (por ejemplo, algo como “Alerta!”).

Cuando usamos la nueva etiqueta de “figure”, que incluye el “figcaption”, en este último se incluye qué es la imagen, y en el texto alternativo podríamos indicar la descripción propia de la imagen.

De la misma forma podríamos usar las imágenes obtenidas con una cámara web (webcam). En este caso estaría bien indicar de alguna forma en el texto alternativo la fecha y hora de la imagen tomada además de una descripción de lo que aparece en la misma (aunque esto, si es automatizado, puede ser difícil). En el caso de que tras la imagen haya esa explicación, el texto alternativo sólo sería necesario indicar la localización y cuándo se tomó.

En el caso de múltiples imágenes que confirma una única, en general lo ideal es que toda la información se ponga siempre en la primera de las imágenes.

Otro caso de imagen es el que nos encontramos en los CAPTCHA. En estos casos hay varias opciones… en general los captchas siempre han de ir acompañados de un método alternativo que no sea visual (puede ser sonoro). En este caso indicaremos en el texto alternativo que se utilice el otro método.

Los logos o insignias han de incluir por norma general a lo que hacen referencia (no haría falta incluir que es el logo, simplemente el nombre o empresa). Si el nombre de lo que hacen referencia viene a continuación no haría falta incorporarlo en el texto alternativo. En algunos casos (cuando el logo se utilice por temas informativos y no como referencia al propio en sí), entonces se incorporará una descripción de lo que es el logo en sí, de las formas, colores y similares que incluye.

Para acabar, cuando una imagen se utiliza “inline” (o sea, en un texto sustituyendo a una palabra o concepto), el texto alternativo será el concepto o texto que sustituye, de forma que si leemos el texto de forma seguida, ignorando la imagen, el texto tenga sentido completo.

Cambiando ya de nivel, los textos alternativos largos (los cortos serían aquellos que sustituyen a una palabra o similar) deberían ser como máximo de 75 a 100 caracteres. Esto es válido tanto para el “alt” como para los “figcaption”.

¿Y qué ocurre con el “title”? Pues básicamente que no se debería continuar usando. El title no ha de incluir un texto alternativo, sino que es un elemento visual, y como elemento visual no es compatible con todos los dispositivos. Es por esto que es más recomendable usar el “figcaption” como sustituto del “title”.

Vigencia de Google Page Speed y Yahoo! YSlow

Estos días se están haciendo revisiones en algunos sitios de la validez que tienen los puntos que definió Steve Souders hace ya algunos años (entre dos y tres) para saber si siguen vigentes, teniendo en cuenta que los navegadores han evolucionado exponencialmente estos últimos años. Hay que tener en cuenta que las herramientas de Google Page Speed y de Yahoo! YSlow se basan en estos datos pero… ¿siguen siendo vigentes los resultados de estas herramientas? Creo que la respuesta es que en algunos casos no.

Comencemos repasando los de Yahoo! (que al final es la plantilla en la que se basan ambos), que fueron los primeros en aparecer y los que creo que no han evolucionado ni actualizado.

  • Minimize HTTP Requests: Creo que no cabe duda de que esto siempre será válido… cuantas menos peticiones, menos tiempo se pierde.
  • Use a Content Delivery Network: Esto ya no es tan importante, aunque hay que hacer muchos matices. Deja de ser importante generalizarlo a menos que tengas mucho tráfico internacional muy distribuido; si tu tráfico es de un mismo país mayoritariamente, tener un CDN no aporta nada. Tener tráfico internacional en un CDN es interesante siempre que las URL sean las mismas independientemente de la localización.
  • Add an Expires or a Cache-Control Header: Esto también es siempre algo a realizar, incluso si se trata de contenidos dinámicos ya que habría que indicar un tiempo “cero”.
  • Gzip Components: Más que obligar a usar gzip, diría que hay que gestionar bien las cabeceras. Por ejemplo, las imágenes en JPEG no tiene sentido volver a comprimirlas con gzip ya que ya van comprimidas por norma general, por lo que los beneficios son mínimos. Para la parte de contenidos “textuales” (HTML, JavaScript, CSS…) sí que es algo más que recomendable aplicar siempre.
  • Put Stylesheets at the Top: Esto también sigue siendo vigente ya que el navegador es importante que sepa cuanto antes lo que ha de maquetar. Incluiría que es recomendable no usar CSS inline.
  • Put Scripts at the Bottom: No lo tendría tan presente ya que hay que analizar cada caso en cada JavaScript. Hay que tener en cuenta que existen dos tipos y formas de cargar los scripts, ya sean bloqueantes o no, por lo que los “no bloqueantes” hay que colocarlos en la cabecera, junto a los asíncronos, y los “sí bloqueantes” incluirlos al final de la página.
  • Avoid CSS Expressions: Obvio. Además, tengo entendido que Internet Explorer 10 ya no acepta este tipo de códigos, así que un problema menos.
  • Make JavaScript and CSS External: Y, además, como decía antes, evitar los CSS o JavaScript “inline”.
  • Reduce DNS Lookups: En general se le da muy poca importancia a las DNS. A parte de decir que se hagan la menor cantidad de peticiones posibles a las DNS, intentar no usar CNAME y demás, habría que analizar bien qué sistema de DNS utilizar y cómo distribuirlo.
  • Minify JavaScript and CSS: Y además de los CSS y JS, ampliaría la cuestión a intentar minimizar el tamaño de los HTML e incluso de los XML (y de cualquier cosa que tenga “tags”.
  • Avoid Redirects: Esto también tiene sus cosas… Si bien es cierto que hay que evitar al máximo las redirecciones, creo que es “obligatorio” evitarlas en las páginas de destino principales (como puede ser el dominio principal, que al entrar redirija) pero focalizarlo todavía más en algunas situaciones que pueden generar problemas, como tener URL de imágenes que siempre hacen redirecciones, o CSS o JavaScript que se cargan en cada página. Yo excluiría la “navegación” de este punto.
  • Remove Duplicate Scripts: Esto creo que es obvio.
  • Configure ETags: Sí y no. Está bien tener activados los ETags, ya que es el mejor sistema para no tener que re-cachear nada ya que son peticiones mucho más sencillas pero sólo en aquellos elementos que en principio tienden a ser estáticos, como imágenes, scripts y similares. Hacer esto en contenidos como HTML (a menos que sean ficheros HTML físicos) no tiene mucho sentido.
  • Make Ajax Cacheable: Una vez más, depende… en general el AJAX se utiliza para elementos que son muy dinámicos, por lo que cachear no suele tener mucho sentido en estos casos. Lo que sí que hay que plantearse es que el AJAX sea llamado por peticiones GET (y no POST) y que el formato sea JSON (mejor que XML).
  • Flush the Buffer Early: Si bien es cierto que hay un momento clave (que es el de cambiar del head al body, hay que analizar muy claramente los momentos en los que hacer un flush ya que por lo general pierde sentido si no es en ese momento (otro momento sería el de antes de los scripts del final de la página).
  • Use GET for AJAX Requests: Como ya comentaba antes.
  • Post-load Components: Suele tener sentido con las imágenes, aunque de forma limitada solo a aquelas grandes (no se puede aplicar a iconos y similares). Es el llamado “lazy load” y básicamente plantea que, en el momento en el que el usuario tenga la necesidad de ese contenido, se haga la llamada; como ejemplo sería que, en el momento en el que el usuario llegue a la parte de la pantalla (si es larga, pues cuando baja) se cargue la imagen para verla, pero no antes.
  • Preload Components: Este método no es necesario en la mayor parte de los sitios web, ya que son de contenidos y no se puede predecir el comportamiento del usuario. De todas formas sí que se puede plantear hacer una carga de un JS o CSS pequeño para que el usuario comience a ver y trabajar con la página y después cargar un CSS y JS mayor que sirva para todo el resto del sitio. Aplicarlo suele ser bastante complejo y los beneficios son discutibles.
  • Reduce the Number of DOM Elements: En general los sitios no tienen un exceso de elementos DOM. Además, el HTML 5 ya suele implicar una reducción debido a que el webmaster no ha de poner “identificadores” a las etiquetas. En general es algo difícil de controlar.
  • Split Components Across Domains: Está bien plantear el Domain Sharding, pero teniendo en cuenta que los navegadores actuales han pasado de una media de 2-3 peticiones/hostname a una media de 6 peticiones/hostname esta situación queda bastante diluida.
  • Minimize the Number of iframes: Yo diría algo así como: ¡muerte al iframe!
  • No 404s: Creo que esto se ha tomado mal por muchos. La sensación que tengo (al menos esto sí es útil) es que desde el HTML no se hagan llamadas a elementos que devuelven un código 404. Por ejemplo, una llamada a una imagen que no existe, ya que esto genera un bloqueo por parte del navegador. No habría que confundirlo con tener enlaces en tu web a páginas que no existen y devuelven un 404 (que claro está, es mejor no hacerlo, pero no es un problema de rendimiento propiamente dicho).
  • Reduce Cookie Size: Obvio.
  • Use Cookie-free Domains for Components: Básico.
  • Minimize DOM Access: Cuanto más 1.0 sea la página mejor… ya que la página se muestra y así se queda. En cambio, todo lo dinámico implica un sobre esfuerzo por parte del navegador que si no está bien optimizado puede hacer que los scripts bloqueen el programa.
  • Develop Smart Event Handlers: Esto va relacionado con lo anterior. Si te pones y lo haces, hazlo bien. Obvio.
  • Choose over @import: El problema de esto era en los navegadores de finales de los 90. Ahora tampoco tiene mucho sentido, aunque es lógico que vaya más lento ya que implica otra llamada HTTP, con lo que ello supone.
  • Avoid Filters: Como decía antes, Internet Explorer 10 ya se ha cargado esto, así que otro tema menos.
  • Optimize Images: Básico.
  • Optimize CSS Sprites: Lo incluyo en lo de las imágenes… es básico que un Scrite esté bien hecho, sin espacios entre iconos y poniendo las imágenes de forma que el tamaño de la imagen sea el mínimo.
  • Don’t Scale Images in HTML: Básico… hoy en día con la tecnología que tenemos se pueden hacer varias versiones (de tamaño) de una imagen de forma automática o al vuelo y dejarla cacheada.
  • Make favicon.ico Small and Cacheable: Y comenzaría diciendo que simplemente haya un favicon.ico en la carpeta raíz, aunque ocupe “0 bytes”, para que no genere errores 404.
  • Keep Components under 25K: Hoy en día los móviles han evolucionado mucho y las cachés pueden ser tranquilamente de 1 MB, por lo que esto ha quedado completamente desfasado.
  • Pack Components into a Multipart Document: Inútil en general.
  • Avoid Empty Image src: De sentido común.

Si revisamos las de Google Page Speed nos damos cuenta de que esta información sí que ha sido evolucionada y en general va adaptándose a lo actual. En general creo que lo de Yahoo! es básico, y lo que expone Google es más técnico en algunos detalles:

  • Leverage browser caching: En este tema tengo ciertas dudas… lo que indica tiene lógica pero en determinados tipos de fichero puede convertirse en un problema. De todas formas he de acabar de hacer pruebas (en principio estas próximas semanas) así que ya veré.
  • Leverage proxy caching: Sentido Común, nuevamente. Hay que tener presente cómo funcionan los proxies
  • Optimize the order of styles and scripts: Importantísimo. Los scripts bloquean, por lo que si podemos hacer hasta 6 llamadas simultáneas hay que ordenar los elementos de forma que no se bloqueen entre ellos. De esta forma estaría bien plantearse si cruzando CSS y JS podemos conseguir esto.
  • Avoid document.write: Este sistema bloquea muchísimo la carga de las página, ya que hasta que nos e finaliza la misma no se ejecuta, por lo que puede rehacer todo el diseño. Si se usa, que sea en funciones, pero no en el código fuente.
  • Prefer asynchronous resources: Obvio. Ya lo he comentado en varias ocasiones.
  • Remove unused CSS: Obvio, pero. En ocasiones da la sensación de que te estén diciendo que hay que usar un fichero JS y CSS por página, lo que implicaría un aumento de peticiones a corto plazo… Siguiendo con la filosofía de reaprovechar código, en este caso sí que eliminar código que no se use, pero que no se use en ninguna parte de todo el sitio, no de esa página en concreto.
  • Minify HTML: Antes lo dije, pero en lo de Yahoo! no lo comentan.
  • Use efficient CSS selectors: Difícil pero no imposible. Los selectores pueden complicarse, pero con un poco de trabajo se puede conseguir un uso eficiente de ellos. Hay que intentar evitar selectores universales, e intentar ir siempre a lo más específico. Muy recomendable un documento de Mozilla sobre la eficiencia para CSS.
  • Specify image dimensions: Por si no queda claro, ya sea con los parámetros del HTML o a través de CSS.
  • Specify a character set: Básico. Aunque los servidores ya devuelven el contenido en una codificación por defecto, es mejor indicar la meta-etiqueta que informa del ISO o UTF que se está usando.
  • Make landing page redirects cacheable: Error. Las URL han de ser las mismas ya que no hay que diferenciar URL entre escritorio o móvil. Mediante sistemas de web-proxy es fácil conseguirlo.

NOTA: en la parte de Google, los elementos que son igual que en Yahoo! ni los comento.

Entre los análisis de Google Page Speed y de Yahoo! YSlow, ahora mismo el que da información más apurada de lo que es la realidad vendría a ser el de Google Page Speed, pero, hay que recordar que esto son simples directrices, y que aunque estas herramientas se “quejen” no significa que lo que hay está mal, ya que todo tiene una razón de ser. Está bien analizar los mensajes que se dan, pero no siempre hay que corregirlos y obtener un 100/100 de puntuación.

Ontologías, HTML, Microdatos, Schema.org y RDFa

Allá por el año 2000 comencé a escuchar sobre la Web Semántica. Cuando apareció el término de la Web 2.0 muchos se apresuraros a decir que la Web 3.0 sería esa web semántica que tantos años hemos estado añorando. Y es probable que sea así ya que últimamente los motores de búsqueda se están poniendo la pilas en lo que se refiere a adaptar ontologías, lo que puede dar un empujón a este tema en un corto-medio plazo.

Las ontologías, aunque la Wikipedia lo define de una manera, viene a ser el “meterle semántica al HTML”. Esta semántica, claro está, ha de ser un estándar, para que todo el mundo que habla de ese tema lo hable de la misma forma, y de la misma forma ha de existir un sistema que todo el mundo sepa escuchar, como ya hablé sobre las herramientas para microdatos. Además, si unimos todo esto a que el propio HTML5 define todo esto como “microdatos” (para simplificarlo y crear un estándar) creo que ya tenemos la bomba de relojería.

Hoy, por no ir más lejos, se ha acabado la implementación del “bug” de Firefox llamado Implement HTML Microdata API (que no es bug, sino funcionalidad), lo que significa que en cosa de unas semanas tendremos la implementación oficial en el navegador, y es probable que el resto (Chrome y Opera) lo implemente en breve. Gracias a esto podremos exportar información de una web a un calendario, a una agenda y otras tantas cosas.

Pero, ¿por qué hablo de esto? Básicamente porque tengo la sensación de que mucha gente cree que los microdatos y similares son sólo los que nos podemos encontrar en Schema.org, y eso no es cierto, ya que esta propuesta se basa en ontologías que otras empresas, organizaciones o plataformas han ido definiendo a lo largo de los últimos años. Los ejemplos más claros son los de hCalendar y hCard, implementados como Event y Organization / Person.

Pero lo que muchos no conocen es que por ejemplo el schema de Product está basado en el ProductOrService, el schema de GeoCoordinates se basa en el de Location o que el de Offer se basa en el de Offering.

Lo más interesante de todo es, además de la lista completa de los que de alguna manera se están estandarizando bajo Schema.org que incluyen un montón de elemento, existe una lista de propuestas que suelen basarse en algunas ontologías que se están “fabricando” por la red. Esta lista de propuestas incluyen ofertas de trabajo, comentarios, aplicaciones de software, programación de televisión y radio, deportes, cómics y novelas, salud, API, código de programación, Real Estate

La gracia de todo esto es encontrar por la red plantillas base para comenzar a informar a las máquinas de los contenidos que tiene nuestro sitio, basándose, como decía antes, en cosas que haya ya por la red. Por ejemplo, tenemos ya disponibles las de deportes con la Sport Ontology propuesta por la BBC, la de Venta de Vehículos o la de Tickets. Además, en general todo viene acompañado con ejemplos y métodos de implementación.

Aunque sin duda a mi lo que más de ha gustado ha sido encontrar una herramienta que acabe estandarizando todo a un formato único, ya que tener código en RDFa, RDF con XML, Microdatos y otros tantos acaba siendo una locura, por lo que un RDF Translator es la mejor solución para convertir el código, personalmente, hacia los MicroData.

Pero esto no es lo único que hay. Seguro que en su día han usado alguno de los vocabularios de SemanticWeb que son clásicos ya y se han dado por buenos.

Fórmula para Domain Sharding

Uno de los problemas habituales en el Domain Sharding es decidir en qué subdominio colocar cada una de las imágenes… esta fórmula tiene que gestionarse de forma que o sea lineal (es decir, primero 3 elementos por subdominio, luego 3 elementos en el subdominio siguiente…) o han de ser aleatorios. Personalmente siempre he planteado que la primera opción es la mejor, pero eso impediría que una misma imagen pueda estar en más de un sitio, a parte de implicar problemas de contenido duplicados.

¿Cuál es la mejor solución entonces? Quizá la segunda, con una fórmula que sea lo más simple pero funcione. Un ejemplo sería este:

function getDomainShard($url, $subdominios) {
  return strlen($url) % $subdominios;
}

Básicamente lo que hacemos es pasar la dirección URL, la cantidad de subdominios y te devolvería un número con el que montar la nueva URL.

Los análisis nos dan esta tabla:

NavegadorConexiones
por Host
Conexiones
Simultáneas
Sugerencia
de Sharding
Chrome 186213
Chrome 196172
Chrome 206162
Firefox 116284
Firefox 136406
Internet Explorer 86355
Internet Explorer 96355
Internet Explorer 106355
Opera 116325
Opera 126355
Safari 5.16355
Safari 5.26305

Teniendo en cuenta que el dominio principal no hay que contarlo, la recomendación media es de usar 4 subdominios en modo Domain Sharding.

Herramientas para Microdatos

Hace ya un tiempo que los Microdatos (en general más conocidos como Microformatos y por el sistema Schema.org) vienen pegando fuerte y los buscadores los están teniendo bastante en cuenta a la hora de dar formato a algunos resultados de búsqueda concretos.

La cuestión es que si queremos verificar si estamos haciéndolo bien hay muy pocas formas de hacerlo, pero se puede. Las principales herramientas las ofrecen los propios buscadores aunque podemos encontrar alguna más:

Google Rich Snippets Testing Tool

En principio es la herramienta más trabajada. Permite introducir una URL que Google descarga y verifica, e incluso si tiene un formato específico para ella lo formatea a modo de ejemplo, además de permitirte subir un código de HTML y analizarlo para ver si es correcto.

Aquí un ejemplo de receta de cocina y de persona.

hay que tener en cuenta que Google sólo “pinta” diferente algunos resultados, algunos tipos y no todos los formatos de Schema, así que si lo que quieres es un resultado especial, no uses formatos que se aceptan, sino que usa un formato que se dibuje distinto…

Bing Markup Validator

La herramienta sólo permite en este caso el indicar una URL. Los resultados son simplemente mostrar la codificación, pero no muestra la información que usa el buscador.

Yandex Microformat validator

Es una mezcla entre el de Google y el de Bing. Permite tanto URL como código fuente pero en este caso sólo muestra la codificación pero no cómo quedaría en los resultados de búsqueda.

Hay que tener en cuenta que estos sistemas no dejan de ser una pequeña evolución de lo que es el propio RDFa, lo que significa que si queremos realmente analizar toda la meta información que nuestra página puede tener (a parte de estos “controlados”) podemos irnos un paso por encima y utilizar algunas herramientas como:

RDFa Validator

Este validador va un poco más allá ya que revisa cualquier tipo de elemento de valor añadido sobre metatags, enlaces, imágenes, etc… Además, permite indicar una dirección URL, subir un fichero o introducir un trozo de código fuente para analizar.

Un ejemplo, la misma dirección de las recetas que ponía con Google…

Living Validator

Este podría definirse como “el validador”, ya que revisa prácticamente todo lo que se le pone por delante, desde el código HTML hasta… las propias imágenes que se incluyen en el sitio web…

Volviendo al ejemplo de las recetas de cocina…

Como resumen, existen ciertas estadísticas de uso ya de algunos de estos formatos, tanto los pre establecidos desde hace años como de los nuevos en el sistema Síndice. Según este sistema lo que más se utiliza es el “vcard” y el “geo” como sistemas más o menos estándar y que tengan cierto significado.