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.

Publicado por

flopez

Desarrollador web con énfasis en front-end y usabilidad. Actualmente trabajo en Justia, Inc.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *