Rehaciendo flopez.com.mx: La optimización y lo que sigue

Este es el tercer y último post de la serie donde narro los cómos y por qués del último rediseño de flopez.com.mx. Si no los has leído, te invito a que les eches un ojo a los preparativos y a la construcción del sitio usando Middleman.

Calificación de PageSpeed de flopez.com.mx, septiembre de 2015.
Calificación de PageSpeed de flopez.com.mx, septiembre de 2015.

Venciendo a Google Pagespeed

Tener en cuenta la eficiencia desde el inicio del proceso de creación del sitio tuvo un impacto definivo llegado a este punto, cuando subí por primera vez mis archivos al web y pregunté a Google: ¿cuál es mi Pagespeed?

Los puntos más débiles de un sitio en cuanto a la velocidad de carga, que es el enfoque de esta evaluación, suelen ser el tamaño de los recursos (imágenes, CSS, scripts…), su método de carga (sincrónico o asincrónico) y desde dónde se cargan (si desde un CDN confiable o no).

Lo que descubrí en este proceso es que si mantienes la cantidad de recursos externos lo suficientemente baja, el Pagespeed no se verá muy afectado aunque no se sigan todas las recomendaciones.

Pero vayamos paso a paso:

Scripts. El sitio no llama a scripts externos; todo el código está embebido. Esto elimina varios dolores de cabeza.

Imágenes. La página de inicio usa solo cinco imágenes: dos fotografías (la del puente y una foto pequeña para el pie) y tres ilustraciones: el logo del inicio, una pequeña ilustración de cierre al pie y una imagen arriba de la forma de contacto.

Las imágenes fueron optimizadas usando Kraken, que ofrece un excelente servicio gratuito (hay otras alternativas, como el venerable ImageMagick, que no requieren conexión a Internet).

Consideré, para las ilustraciones, usar SVG. Sin embargo, mi logo solo lo tengo rasterizado, y si bien consideré rehacerlo vectorialmente, hice primero pruebas de carga y descubrí que por el momento no sería necesario. Con esto lo decidí: las ilustraciones, pues, son PNG.

Fuentes. Google Fonts ofrece varias maneras de embeber las fuentes. De todas estas, la única que yo recomiendo es, sin embargo, la más complicada: la carga asincrónica mediante Javascript – y el script colocado al final del HTML. Esto evita bloquear la carga de otros recursos, como el CSS y las imágenes, que pueden tener mayor impresión al momento del despliegue inicial de una página.

CSS. Esto consta de dos partes: la fácil/obvia y la truculenta.

La optimización “fácil” (para el CSS y cualquier otro archivo de texto) es la minificación: mediante este proceso se eliminan espacios. En la minificación de Javascript se va un paso más allá y se realizan sustituciones de caracteres, nombres de variables, etc. que suelen tener impactos dramáticos en el tamaño de los archivos. Esto es fácil porque es automático en la gran mayoría de los flujos modernos de creación de sitios web.

La parte “difícil”, específicamente para los estilos, es algo relativamente nuevo. Google pide determinar cuáles estilos son los esenciales para el render “arriba del pliegue” de una página y embeber dichos estilos en el HTML. Autores importantes han hablado del tema e inclusive expresado su inicial desconcierto.

Intenté primero con soluciones automatizadas para determinar qué CSS es crítico, pero no resultaron ser lo que yo esperaba. Terminé, pues, por analizar manualmente el contenido de mi Sass y separarlo en dos archivos: “critical.scss” y “non-critical.scss”, de manera que ambos se compilan en un solo archivo para desarrollo local, pero al subir el sitio solo lo no crítico es cargado externamente; el resto está embebido.

El criterio que usé para separar lo crítico de lo no crítico fue:

  • Todos los estilos del encabezado son críticos. Esto es porque siempre estarían “arriba del pliegue”, por más pequeño que sea un dispositivo.
  • Los colores y la estructura base son críticos, a tal grado que puedan construir una experiencia básica de usuario. A este punto, de mobile first, digamos que me quedo con mobile only.

Por otro lado:

  • Las fuentes especiales son no críticas.
  • Todos los media queries son no críticos.
  • El contenido del pie de página es no crítico.
  • Los contenidos que no es probable que se carguen arriba del pliegue la mayor parte del tiempo son no críticos. Esto incluye, por ejemplo, la forma de contacto.

Gracias a todo lo mencionado, a la fecha el sitio logra 95/100 y 100/100 en móvil, así como 97/100 en desktop, de calificaciones en PageSpeed Insights.

Lo que no he logrado: la mejor configuración del caché del servidor. (Debo hablar con mi proveedor de esto.)

Los pendientes

Aún quiero hacer algunas cosas antes de considerar esta misión terminada:

  • Optimizar mi proceso de desarrollo local. La desventaja de trabajar en Windows en una era en la que el desarrollo front-end se hace sobre todo en Mac: muchas herramientas no están optimizadas para mi configuración local. Así, hay detallitos qué arreglar, como las recargas dinámicas (LiveReload) que no funcionan adecuadamente.
  • Mejorar la forma de contacto. Tanto en su diseño, para mejorar las conversiones, como en su back-end, donde estoy usando un script que no me da los mejores resultados.
  • Mejorar el portafolio. Por alguna razón tuve problemas con la compilación del archivo. También mejoraré la experiencia de usuario en general.
  • Introducir secciones nuevas (de las cuales no adelanto nada :D)
  • Integrar gráficamente este blog al resto del sitio.

Así pues, el proceso continúa, pues el aprendizaje no puede detenerse.

Renovando flopez.com.mx

A estas alturas, todo profesional del web debería saber lo importante que es tener una presencia en línea, construir su propia marca personal. Pero, como a muchos nos pasa, yo he sido un caso crónico del síndrome de “en casa del herrero”.

Así que decidí comenzar a enmendar mis pecados. Acabo de subir la primera versión (muy poco refinada aún) de la nueva imagen de mi sitio web.

Aunque lo considero un pre-alpha, he preferido subirlo de una vez y luego hacerle mejoras incrementales (después de todo soy un creyente de las filosofías ágiles de desarrollo).

Tecnologías usadas

Inicialmente sería solo una página, que hice en simple HTML, confiando mis estilos a Sass y Compass (por supuesto), usando Prepros, pues para mis trabajos personales sigo usando Windows, por cuestiones de balance de costo/beneficio. Pero cuando me di cuenta de que tengo material para algo más robusto, comencé a buscar herramientas generadoras de sitios web simples.

Me decidí en esta ocasión por nanoc, una herramienta muy sencilla que como es basada en Ruby, juega bien con el resto de mi paquete – y máxime que para estas alturas había decidido probar con Haml para manejar mis templates. nanoc me funcionó muy bien al inicio, sobre todo porque así fue fácil editar el contenido en kramdown, uno de los sabores de markdown. (Por cierto, qué bueno que por fin hay un estándar de markdown).

Debo admitir que, al no saber casi nada de Ruby, mi dificultad para integrar compass y nanoc casi me hicieron cambiar mi decisión. Salí avante después de un par de intentos gracias a algunos recursos en línea, aunque mi configuración aún no queda como yo la quiero… habrá que dedicarle algunas noches más.

Decisiones tomadas

El propósito de mi sitio es servir como tarjeta de presentación, más que como currículum. Busqué, pues, sencillez tanto en el look del sitio como en la estructura de las frases en él.

La información completa que se refiere a mi intro cabe en una sola página, la que culmina con una invitación a contactarme; en este punto tradicionalmente iría una forma de contacto pero, dado mi público, me decidí por hacer de Twitter mi medio principal de contacto en línea, por ahora. Veremos cómo funciona.

Otro experimento es que si bien mi sitio es bilingüe, el idioma que tiene prioridad es el inglés. Esto es tanto por posicionamiento del sitio web como de mi propia marca personal: basta con mencionar que uno de los factores que me permiten laborar en Justia es el uso de tal idioma.

A futuro

Una de las secciones de mi sitio (er, bueno, la única “sección” como tal) está dedicada a Three Relics, el juego de mesa que he estado cocinando durante los últimos meses durante ratos libres. Creo que esta es una buena oportunidad para ir desarrollando esta sección y ver cuán eficientemente puedo enseñar a jugar a mis visitantes.

Como dije, el diseño está lejos de satisfacerme, así que habré de pensar más en ello. De igual manera, aún no estoy poniendo esfuerzos de SEO de ninguna manera, pero eso irá cambiando.