35 consejos rápidos para mejorar la Performance de tus sites

Imagen por Veri Ivanova en Unsplash

Estos días me metí en la moda de Twitter para hablar un poco sobre Web Performance, un tema que me gusta mucho.

Como las personas interactuaron y cogieron un poco de tracción, decidí transformar los tweets en un artículo para ustedes. ¿Vamos a verlo?

⚡️ Consejo #1: Monitoreo

O @SpeedCurve fue la mejor herramienta que encontré para ayudar a crear una cultura de performance a través del monitoreo. Él te da los insights, apunta cuales son los principales problemas de forma automatizada — e incluso los compara con los competidores.

⚡️ Consejo #2: System Font Stack

A veces la mejor estrategia de font-loading es no cargar ninguna fuente: el tal “System Font Stack”.

  • iPhone = San Francisco
  • Android = Roboto
  • Linux = Ubuntu
  • Windows = Segoe UI

… y así por el estilo. ¡Experiencia nativa para todo el mundo!

System Font Stack

⚡️ Consejo #3: Animaciones

Las animaciones son un excelente recurso para ganar tiempo mientras se carga algo. Ese concepto se llama “Espera activa” y hablo más sobre él en mi talk sobre Psicología de la Performance (adelante hasta el minuto 15:30).

Round App — https://www.behance.net/gallery/19040507/Round-iPhone-app

⚡️ Consejo #4: Request Map Generator

Use herramientas como el Request Map Generator de @simonhearne para auditar los scripts de terceros (analytics, ads, etc) de su site. En la imagen, el mapa de requests del Amazon.

Mapa de requests del Amazon

⚡️ Consejo #5: Performance = Ética + Accesibilidad

La Performance también es una herramienta de ética y accesibilidad. Tenemos el privilegio de ingresar a la web a través de conexiones rápidas e ilimitadas, ero esa no es la realidad de la mayoría. Youtube alcanzó nuevas poblaciones enteras cuando se hizo más ligero.

⚡️ Consejo #6: Resource Hints

Use los Resource Hints para precargar assets o “calentar” la conexión en background. El ‘dns-prefetch’ hace un lookup en el DNS, el ‘preconnect’ hace el handshake y el ‘preload’ carga a la página de destino entera.

⚡️ Consejo #7: Siga especialistas

¡Siga mi lista de especialistas en Web Performance en Twitter para mantenerse al día! 💪🧠

⚡️ Consejo #8: Size Limit

Con el Size Limit se puede saber qué libs son las “big offenders” del tamaño total de su bundle JS. Se puede hasta colocar en su pipeline de CI (Jenkins, Travis, etc.) para que muestre error cuando pase de un cierto límite.

Size Limit apuntando el tamaño de las libs y archivos

⚡️ Consejo #9: Defina un Performance Budget

Puede parecer contraproducente al inicio, pero te va a ayudar a definir de manera clara lo que se debe incluir y remover de su stack o de 3rd-party scripts.

Imagen por: Addy Osmani

⚡️ Consejo #10: Conozca las métricas

Conozca las principales métricas de performance de renderización: FCP, FMP, TTI, FID y otras siglas son muy importantes y necesitan ser seguidas de cerca.

Imagen por Addy Osmani — https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4

⚡️ Consejo #11: No todos los bytes son iguales

100KB de JS “pesan” hasta 100x más que 100KB de una imagen. Mientras una imagen necesita pasar por procesos de decode, rasterize y paint (proceso rápidos), el JS pasa por parse, compile y execute que son muchos mas costosos.

Imagen por Addy Osmani — https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4

⚡️Consejo #12: La performance de los dispositivos varía mucho

Incluso sobre el JS, el tiempo de procesamiento en un celular mediano (MotoG4) es SEIS VECES MAYOR que en un iPhone 8. En un celular de entrada (ALCATEL1X), e VEINTIÚN VECES MAYOR. Salgan de la burbuja personal a la hora de testear la usabilidad.

Imagen por Addy Osmani — https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4

⚡️ Consejo #13: Testee con quien usa el producto

A la hora de testear, tenga en cuenta quién usa el producto. Priorice los perfiles de usuarios y usuarias más populares. Es sólo ingresar en Google Analytics:

Público → Dispositivos Móviles → Dispositivos.

Verá una lista parecida a esta:

Lista de dispositivos en Google Analytics

⚡️ Consejo #14: Optimistic UI

¿Sabe qué pasa cuando hace clic en “like” de Twitter? La respuesta visual aparece incluso antes de la API ser consultada. Trabaje como si todo fuese a salir bien, removiendo estados intermediarios — el nombre de ese concepto es Optimistic UI.

Con Optimistic UI, remueva estados intermediarios> no muestre el loas, vaya directo al éxito.

⚡️ Consejo #15: PRPL

Siga el padrón PRPL:

  • Push los recursos críticos para la ruta de la URL inicial
  • Render la ruta inicial
  • Pre-cache las otras rutas
  • Lazy-load el resto y cree rutas restantes on-demand

⚡️ Consejo #16: Modelo RAIL

Ya que todo aquí son siglas, aproveche para seguir el modelo RAIL de performance:

  • Response (feedback en menos 100ms)
  • Animation (60fps = 16ms por frame)
  • Idle (estado intermediario, bloques de 50 ms)
  • Load (FMP el más rápido posible)

⚡️ Consejo #17: Tree Shaking

Use Tree shaking para eliminar dead code de la aplicación. Todos los module bundlers populares (Webpack, Parcel, Rollup, etc) ya ofrecen ese feature.

Tree Shaking — literalmente.

⚡️ Consejo #18: Scope Hoisting

Ative el Scope Hoisting no Webpack. Él va a identificar cadenas de imports que pueden ser convertidas en una función inline sin comprometer el código.

Scope Hoisting en el Webpack

⚡️ Consejo #19: Code Splitting

Haga Code Splitting de su bundle. La “regla de oro” era reducir todo en un único archivo JS, pero eso está lejos de ser ideal. Envíe lo que la persona necesita solamente cuando lo necesita. Eso es hecho a través de Dynamic Importing — mira la promise:

Dynamic Importing — importe retornando una promise

⚡️ Consejo #20: UnCSS

De la misma forma que puede hacer Tree Shaking en JS, puede usar herramientas como el UnCSS para remover selectores CSS que no son utilizados, algo muy común en bases de código grandes o en component libraries.

⚡️ Consejo #21: Los selectores ni importan

Hablando de CSS, ahí va una 🔥 controversia: optimizar selectores CSS pensando en performance es inútil. No se puede prever el impacto porque o engine del browser reorganiza, divide, colecta y compila los selectores de manera imprevisible.

Quién nunca, ¿no?

⚡️ Consejo #22: ¿Por dónde comenzar?

¡Santo cielo, João, es tanto que no se por dónde empezar!

¡Comience por el @____lighthouse! Los reports son muy intuitivos y ya muestran varios “pastos altos” para cortar.

Google Lighthouse

⚡️ Consejo #23: Font Subsetting

Se puede reducir bastante el tamaño de una fuente usando la técnica de Substetting: remueva los caracteres desnecesarios/ilegibles/de otros alfabetos.

Font Subsetting — remueva los caracteres especiales

⚡️ Consejo #24: FOIT

Cuando se usa custom fonts es importante pensar en la estrategia de carga para evitar el FOIT (Flash Of Invisible Text). Aquí va una guía de Zach Leatherman con algunas estrategias (“FOUT with a class” es mi favorita).

⚡️ Consejo #25: Web Fonts

Hablando de Zach Leatherman, él es la persona que más admiro en el tema de Web Fonts. Èl escribió casi 50 artículos — cuando tenga una duda cobre el asunto, de una hojeada a ese link que su duda probablemente ya fue respondida. You rock, Zach!

⚡️ Consejo #26: WebP

A pesar de que el WebP ofrece un tamaño de archivo menor que el JPEG, este no dispone de progressive loading — o sea, a veces la percepción de performance puede ser inferior. Más allá de eso, es más complejo de ser implementado en función del soporte. ¡Testee con cariño! 💛

⚡️ Consejo #27: Use MozJPEF y nunca use JPEG-XR

Cuando vaya a trabajar con JPEGs, use siempre MozJPEG y habilite progressive loading. No use JPEG-XR en la Web porque no salió bien: o decode trabaja en la main thread junto con el JS y traba todo.

⚡️ Consejo #28: Lazy load en las imágenes

Cargue las imágenes debajo de la primera dobla con lazy load. Existen algunas técnicas: placeholder fixo, placeholder de color dominante, versión de baja calidad (LQIP/SQIP), etc. El @Medium usa LQIP.

Aprenda como hacerlo: https://imagekit.io/blog/lazy-loading-images-complete-guide/

⚡️ Consejo #29: Tiempo subjetivo

El tiempo puede ser dividido de dos maneras: Objetivo y Subjetivo. El primero es medible como un reloj, mientras el segundo es la percepción de como este transcurre. Estudios del @NNgroup muestran que hay métricas de tiempo subjetivo también.

Métricas de tiempo subjetivo: https://es.eventials.com/Globalcode/events/tdconline-portoalegre-2018-stadium-es/

⚡️ Consejo #30: Sea 20% más rápido que su principal competidor

Existe un concepto interesante na Psicofísica llamado Umbral Diferencial que determina a partir de qué punto el cerebro percibe diferencias. En tiempo, ese gatillo es de aproximadamente 20%.

La regla de 20%: https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/#the-need-for-performance-optimization-the-20-rule

⚡️ Consejo #31: Simule 3G y CPUs antiguas

¿Sabía que puede simular 3G y reducir la velocidad del procesador para testear su site como se fuese en un dispositivo antiguo? En la pestaña Performance de Chrome Dev Tools, haga clic en el engranaje y altere las configuraciones.

Chorme DevTools: simule 3G y CPU antiguas

⚡️ Consejo #32: El Save Data request header

Algunos browsers ya ofrecen recursos que adicionan el request header “save-data: on”. Puede identificar eso en el server y en el front-end y ofrecer una experiencia más liviana. Pero acuérdese: más liviana no significa menos features, y sí otra experiencia.

// Front-end
if ("connection" in navigator) {
if (navigator.connection.saveData === true) {
// Implement data saving operations here.
}
}
// Back-end
$saveData = false;
if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
$saveData = true;
}

⚡️ Consejo #33: Más sobre Save Data

Siguiendo con el “save-data”, algunos consejos de lo que se puede hacer:

🔡 remover custom fonts
🙈 remover imágenes irrelevantes
🖼 servir imágenes em menor resolución
🗺 cambiar mapas interactivos por estadísticos
📊 remover herramientas como HotJar y Optimizely

⚡️ Consejo #34: Async y Defer

Use los atributos ASYNC y DEFER para cargar el JS. Con ellos la carga de la página continúa mientras el browser baja el asset, pero en el async él es interrumpido en la ejecución y en el defer la ejecución es pospuesto para después de la carga. Este es mí artículo favorito cerca del tema.

El artículo definitivo sobre Async y Defer : https://flaviocopes.com/javascript-async-defer/

⚡️ Consejo #35: Perfume.JS

Con la lib Perfume.JS podrá medir el First Paint, el First Contentful Paint y el First Input Delay. Ella muestra la performance de los componentes en la timeline del Dev Tools y envía resultados para Google Analytics si usted lo quiere.


¿Le gustaron los consejos?

¡Gracias por leer hasta aquí! Estoy hablando siempre sobre Web Performance — se te interesa puedes seguirme en Twitter o revisar mi site.


La mayor parte del contenido de encima es original de los artículos de Addy Osmani, de Smashing Magazine, de Chrome Developers y otros. Intenté incluir el link de todos, pero avíseme si me olvidé de alguno.