Desde la creación de Internet, el tamaño promedio de los archivos ha ido creciendo constantemente. Lo que comenzó como kilobytes ha progresado a megabytes (sí, plural), y nuestros archivos solo están creciendo.
Si bien este fenómeno no es desconcertante a primera vista, el impacto que tiene en el rendimiento y la capacidad de mantenimiento es terrible. Agregue dispositivos de envejecimiento, restricciones de ancho de banda o velocidades lentas en general ... y tenemos un problema mucho mayor.
Afortunadamente, no solo tenemos control sobre el tamaño de nuestros archivos, sino también sobre cómo se representan nuestras páginas en el navegador. Este tipo de control brinda a los desarrolladores web como nosotros la oportunidad de ayudar a aliviar este problema y optimizar nuestro código para un mejor rendimiento en el proceso.
Entiendo completamente la falta de interés cuando la mayoría de las conexiones a Internet en los EE. UU. Son bastante rápidas actualmente. Quiero decir, si todo funciona bien, ¿para qué molestarse?
El rendimiento y la optimización son más que la rapidez con la que podemos descargar contenido. También hay bastantes beneficios de SEO y UX para tomarse el tiempo de mirar nuestro código. Sin mencionar que disminuir el tamaño de los archivos optimizando nuestro código para un mejor rendimiento tiene la ventaja añadida de disminuir nuestros costos de ancho de banda como hosts y disminuir el uso de ancho de banda (piense en los límites de datos de ISP / celulares) en el nivel de usuario también.
El código modular generalmente agrega relleno en la forma de más opciones. Aquí, queremos pensar modular en términos de combinar tantas piezas comunes de nuestro código como sea posible. Si podemos combinar dos clases de CSS en una y usar menos código para proporcionar el mismo resultado, deberíamos.
La modularidad no es tan importante cuando se trata de HTML y CSS básicos, pero cuando te adentras en el mundo más complejo de JavaScript, tener demasiada tensión puede hacerte daño, especialmente en el móvil.
Las solicitudes de dependencia son, con mucho, el factor más importante para ralentizar la mayoría de las velocidades de carga de páginas. Cada solicitud adicional agrega relleno y otra capa de complejidad al proceso de análisis y descarga. A menudo es fácil olvidarse de que las llamadas a las imágenes de su hoja de estilo también cuentan, así que asegúrese de limitarlas y utilizar métodos alternativos de optimización como sprites o SVG cuando sea posible.
Si bien nos referimos al tema de las dependencias externas, si su sitio web es lo suficientemente grande como para requerir unas pocas docenas de solicitudes como mínimo ... Puede que sea hora de considerar el uso de un CDN. Usar una CDN para distribuir su contenido no reducirá el tamaño de los archivos ni los tiempos de carga tanto como la eliminación de solicitudes HTTP adicionales en conjunto, pero es probable que elimine al menos las conexiones lentas del servidor fuera de la ecuación.
Debería haber una diferencia muy marcada al comparar sus bases de código de nivel de desarrollo y producción. Dar este paso solo a veces puede ver la mayor disminución en el tamaño de los archivos en todos los ámbitos.
Hoy en día es típico ver a los desarrolladores referirse a su entorno de "producción" o "desarrollo", especialmente en proyectos a gran escala. Pero también es útil en el extremo más pequeño de las cosas. La mayor diferencia entre los dos entornos se puede ver con la compresión de imágenes y la minificación / compresión del código. Al final, queremos que nuestro entorno de producción sea lo más ágil y rápido posible, mientras que nuestro entorno de desarrollo debe ser el mismo, solo la optimización de compresión de imagen / código.
Usar las herramientas integradas como la compresión "Guardar para web" de Photoshop puede ser un buen punto de partida para las imágenes. Hay una gran cantidad de conocimiento para ser explorado en otra parte también con conversaciones sobre formatos de imagen, algoritmos de compresión, control de calidad y mejores prácticas.
Para el código, el mejor uso de la compresión generalmente depende del idioma con el que está trabajando. También es muy debatible si la compresión del código ayuda o perjudica a otras personas que intentan comprender su código, pero esa es una conversación para otro momento. Cuando se trata de HTML y CSS simples, utilizo servicios como Compresor html de Google y el Compresor YUI para CSS.
A veces, el código que estamos escribiendo es el más lento de la cadena. Ineficaz CSS o JavaScript inflado puede dañar los tiempos de carga más de lo que piensas. Esta Mozilla La publicación entra en gran detalle sobre la importancia de escribir selectores de CSS simplificados y explica cómo los renderizan los navegadores. En resumen, escribir la ruta exacta en una cadena de selectores es mucho menos eficiente que simplemente usar el selector más pequeño identificable. Ambos dirigen el diseño al mismo elemento, este último simplemente hace el trabajo mucho más rápido.
JavaScript puede ser incluso peor que el CSS mal escrito, y en muchos casos se pasa por alto fácilmente. ¿Cuántas veces ha copiado y pegado una biblioteca JS externa en su proyecto sin realmente profundizar en la fuente misma? Typekit es un maravilloso ejemplo de esto, ya que cuando sus servidores se detienen, puede hacer que una página web con sus fuentes se ponga de rodillas y cause 30 segundos adicionales o incluso minutos de tiempo extra de carga.
Afortunadamente, tales eventos suceden raramente, pero es una buena práctica llamar a JavaScript último si es posible, como es el caso de Google Analytics. Al hacerlo, el navegador puede analizar a través de los archivos principales (CSS, solicitudes HTTP, etc.) y mostrar el marcado, antes de que JavaScript comience a desacelerar.
De acuerdo con nuestro objetivo de escribir selectores de CSS más simples y mantener la hinchazón al mínimo, escribir HTML eficiente también debería ser una prioridad.
Los restablecimientos de CSS a menudo se dirigen a todos los elementos comunes e imponen el estilo de "reinicio". Entonces, incluso si no está apuntando a ese div adicional, es probable que siga ralentizando las cosas al tener que tener su relleno y margen de restablecimiento al mínimo. Por lo general, un div extra o dos no le hará daño. Solo cuando comienzas a terminar con docenas de ellos las cosas se vuelven locas. Con la introducción de más elementos en las especificaciones de HTML5, también tenemos mucha más flexibilidad en esta área.
Google ha convertido en una prioridad el poner a Internet en forma colectivamente en forma. Con el fin de ocupar posiciones destacadas dentro de sus resultados de búsqueda, las páginas ahora deben prestar atención crítica a muchos atributos diferentes sobre cómo se representan. Llamar a demasiados recursos externos, tener imágenes absurdamente grandes, o incluso tener JavaScript mal escrito puede hacer que un sitio caiga en el ranking.
Afortunadamente, todo esto es con buena intención ya que sus requisitos para un buen ranking de búsqueda se basan en buenas prácticas de desarrollo. Google también ofrece un guía muy en profundidad para optimizar diferentes aspectos de su sitio para un mejor SEO, que también promueve fantásticas prácticas de desarrollo al mismo tiempo.
Al optimizar nuestro código, no solo debemos pensar en el tamaño de los archivos, sino también en cómo se leerá; ya sea por navegadores o incluso por otros humanos. El uso móvil también debe tenerse en cuenta, ya que muchos proveedores de servicios aplican forzados de datos muy restrictivos en estos días.
Por lo tanto, aunque puede tomar más tiempo realizar esta optimización, sin duda es una tarea que vale la pena ya que no solo ofrece un mejor rendimiento en el navegador y en el móvil, sino que también ofrece la posibilidad de promover mejores prácticas de desarrollo e incluso obtener un mayor rango de contenido en buscadores como Google.
La próxima vez que te prepares para el lanzamiento, lanza tus imágenes a un motor de compresión ... ¡Te sorprenderá cuántos megabytes puede ralentizar!
Foto principal, imagen de velocidad modular a través de Shutterstock.