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.

Rehaciendo flopez.com.mx: El proceso y los archivos

Esta es la segunda parte del breve recuento de la más breve reconstrucción de flopez.com.mx. En el post pasado te conté sobre su planeación. Ahora entremos de lleno en la construcción del sitio en sí.

Sitio nuevo, proceso nuevo

En la versión anterior de mi sitio web experimenté con Nanoc. Esta herramienta me permitió trabajar con MarkDown, Sass y Compass, así como Haml para los templates. Nanoc genera el sitio completo de manera estática y su configuración, si no fue la más sencilla, terminó siendo aceptable gracias a la documentación en línea.

Esta vez decidí volver a hacer una evaluación de las diferentes herramientas disponibles para creación de sitios estáticos pequeños. Tras de un par de intentos fallidos, gracias sobre todo a la guía de este post,  encontré a un aliado en Middleman. Me decidí por Middleman por su facilidad de uso y por ser una herramienta madura.

Middleman

Como Nanoc, Middleman proporciona scaffolding de proyectos; te permite usar MarkDown, Sass y Compass desde el inicio. Y, al igual que Nanoc, Middleman está hecho en Ruby y se instala fácilmente mediante gem. (Un poco menos fácil si, como yo, insistes en desarrollar en Windows.)

Middleman incluye una herramienta para línea de comandos, aunque también puedes elegir usar programas de compilación diversos.

La estructura del directorio raíz de flopez.com.mx, generada por Middleman.
La estructura del directorio raíz de flopez.com.mx, generada por Middleman.

La estructura de un proyecto en Middleman es sencilla pero configurable. Por defecto creará una carpeta “source”, donde residan los archivos fuente, y una carpeta “build” que contendrá los archivos compilados, listos para subirse a un servidor.

En mi caso, estoy aprovechando dos características “avanzadas” que Middleman hace sencillo usar. Una es  un “caché buster”: al agregar una cadena aleatoria al nombre de cada archivo, la cual cambia cada vez que éstos son compilados, garantizamos que los visitantes siempre obtengan las últimas versiones, en vez de que el browser use la versión guardada en su caché.

La otra opción que uso permite que las páginas aparte de la inicial simulen estar en sus propios fólders una vez que se suben. Así, un visitante puede entrar a flopez.com.mx/portfolio/ para visitar un archivo que en realidad está en la raíz del sitio y se llama portfolio.html. Esto intenta ser un método de conveniencia para que las URLs sean más fáciles de recordar.

Ya con mi método de construcción definido, terminé de definir el texto de la página inicial, creé el templete del HTML (usando solo ERB en vez de Haml esta vez) y comencé a trabajar en mis estilos.

Una vez más estoy usando Sass y Compass, mis caballitos de batalla. Los estilos del sitio intentan ser lo más sencillos posible, y esto ayudó mucho a la hora de crear una experiencia similar en cualquier dispositivo; el observador notará que las transiciones entre diversos anchos de la página son mínimas.

En lo que a gráficos respecta, solo uso una fotografía que, si bien es ancha, no es muy alta. Ciertamente trato aquí de evitar el “look cinematográfico”, la imagen de intro de pantalla completa que es una tendencia tan actual, pero que perjudica tanto a la eficiencia de los sitios. La imagen funciona como fondo del mensaje introductorio, vinculando definitivamente el lenguaje textual con el visual: la idea de “comunicación” es respaldada por la imagen de un puente (el Golden Gate, ni más ni menos).

Screenshot de flopez.com.mx, septiembre de 2015
El logo y la imagen principal de flopez.com.mx, septiembre de 2015.

El logo… fue al final algo fortuito: es una obra que hace mucho tiempo había encargado a mi estimado Armando Camacho de Cárico Estudio, pero que en su momento decidí no usar. Sin embargo, pude rescatarlo de las entrañas de mis respaldos mientras buscaba información para mi página de portafolios… y descubrí que hoy día es mucho más adecuado a mis necesidades.

Aprovechando cuán codo fui con las imágenes, lo que sí decidí utilizar fue dos tipografías externas: Arimo y Montserrat, usando Google Fonts.

Finalmente, como estaba planeado, la página de inicio culmina en una forma de contacto. Debo reconocer que ésta aún no me convence del todo, pero por lo pronto respeta, al menos, el principio de ser tan corta y clara como sea posible. Procuré usar el estilo “madlibs” que tiene un gran potencial de aumentar conversiones.

En el próximo post, el último de la serie, te comparto algunas técnicas de optimización que le permiten al sitio tener calificaciones casi estelares a los ojos de Google.