Al principio, una de las primeras cosas que recomiendo a mis clientes para acelerar los sitios web parecerá una paradoja: debe colocar recursos estáticos en su alojamiento, renunciando a la infraestructura CDN de terceros. En esta publicación breve y, espero, muy simple, quiero describir las desventajas de almacenar sus archivos estáticos "al costado" y las tremendas ventajas de alojarlos en mi alojamiento.
De que estoy hablando
Es común que los desarrolladores hagan clic en el enlace a activos estáticos, como bibliotecas o complementos, que se encuentran en sitios y recursos de CDN. Un ejemplo clásico es jQuery.
Hay una serie de ventajas obvias, pero mi objetivo más adelante en el artículo es exponer este enfoque y demostrar que las desventajas son mucho más frecuentes.
(Primero, considere los beneficios).
- Esto es conveniente Esto requiere muy poco esfuerzo para conectar archivos. Copie la línea de código HTML y listo. Fácil
- Tenemos acceso a la CDN. code.jquery.com es suministrado por StackPath, es un CDN. Al conectarnos al contenido de este recurso, obtenemos entregas de calidad CDN, sin cargo.
- Los archivos de usuario ya pueden estar en caché. Si website-a.com enlaza con code.jquery.com/jquery-3.3.1.slim.min.js y el usuario pasa de aquí a website-b.com, que también enlaza con code.jquery.com/jquery-3.3 .1.slim.min.js , entonces el usuario tendrá este archivo en el caché.
Riesgo: caída de velocidad y fallas
No entraré en demasiados detalles en esta publicación. Tengo un artículo completo sobre la viabilidad de un tercero y los riesgos asociados con demoras e interrupciones. Baste decir que si tiene recursos críticos asociados con proveedores de terceros, y si el proveedor sufre bloqueos y una caída en la velocidad o interrupciones, esta es una noticia bastante desagradable para usted. Sufrirás de esto también.
Si tiene CSS de bloqueo de renderizado o JS síncrono alojado en recursos de terceros, continúe y transfiéralos a su propia infraestructura de inmediato. Los activos críticos son demasiado valiosos para dejarlos en servidores de terceros.
Riesgo: terminación del servicio
Esta es una ocurrencia mucho menos común, pero ¿qué sucede si el proveedor decide que necesita suspender el servicio? Esto es exactamente lo que hizo Rawgit en octubre de 2018, hasta el momento (en el momento de escribir esto), una búsqueda cruda en el código de GitHub todavía proporciona más de un millón de enlaces al servicio, que actualmente se está cerrando, y casi 20,000 sitios activos continúan refiérase a eso.
Riesgo: vulnerabilidades de seguridad
Otra cosa a la que prestar atención es una simple cuestión de confianza. Si traemos contenido de recursos de terceros a nuestra página, tenemos que esperar que los archivos que recibimos sean exactamente lo que esperamos recibir, y que hagan exactamente lo que esperamos de ellos.
Imagine el daño que podría hacerse si alguien pudiera obtener el control de un proveedor como code.jquery.com y comenzar a entregar contenido comprometido o malicioso. ¡Da miedo pensarlo!
Integridad de recursos
Debemos rendir homenaje a todos los proveedores de terceros mencionados hasta ahora en este artículo, que están haciendo todo lo posible para garantizar la integridad de los subrecursos (Subresource Integrity - SRI). SRI es el mecanismo por el cual el proveedor proporciona el hash (técnicamente, un hash seguido de la codificación Base64) del archivo específico que espera y tiene la intención de usar. El navegador puede verificar que el archivo que recibió es exactamente lo que solicitó.
<script src="https://code.jquery.com/jquery-3.4.1.slim.min.js" integrity="sha256-pasqAKBDmFT4eHoN2ndd6lN370kFiGUFyTiUHWhU7k8=" crossorigin="anonymous"></script>
Una vez más, si definitivamente necesita conectar contenido estático a un recurso de terceros, asegúrese de que SRI esté activo. Puede conectar SRI usted mismo.
Reconocimiento: negociaciones de red
Uno de los mayores y más urgentes costos en los que incurrimos es el costo de abrir nuevas conexiones TCP. Cada nuevo recurso que necesitamos visitar requiere abrir una conexión, que puede ser muy costosa: resolución DNS, protocolo de enlace TCP, negociación TLS, todo lo cual contribuye, y la historia empeora a medida que la conexión se retrasa.
Daré un ejemplo tomado directamente de la página de inicio de Bootstrap. Indican a los usuarios que adjunten cuatro archivos.
Estos cuatro archivos se encuentran en tres recursos diferentes, es decir, necesitamos abrir tres conexiones TCP. Cuanto cuesta Bueno, con una conexión bastante rápida, el contenido de estos archivos estáticos en el lateral es de 311 ms, o 1.65 veces más lento que al colocarlos en su propio alojamiento.
Al contactar tres fuentes diferentes para el mantenimiento de activos estáticos, colectivamente perdemos los 805 ms innecesarios para las aprobaciones de red.
OK, no da tanto miedo, pero Trainline, mi cliente, descubrió que cuando el retraso se redujo en 300 ms, los visitantes pagaron 8 millones de libras adicionales por año. Esta es una manera bastante fácil de ganar 8 millones.
Simplemente moviendo nuestros recursos a su dominio, eliminamos completamente el costo de las conexiones adicionales.
Para una conexión más lenta, con un retraso más largo, la historia es mucho peor. Para 3G, la versión de terceros es más lenta que la 1.765. Pensé que estaba destinado a hacer nuestro sitio más rápido.
Cuando se conecta con un gran retraso, los costos totales de la red son monstruosos 5.037. Lo que se puede evitar por completo.
Mover archivos a nuestra propia infraestructura reduce el tiempo de descarga de 5.4s a 3.6s.
Si esta no es una buena razón para alojar sus recursos estáticos, no sé qué más llevar.
Preconectar
Naturalmente, el punto principal de mi presentación aquí es que no debe publicar ningún recurso estático en el lateral si puede hacerlo en su alojamiento. Sin embargo, si sus manos están atadas de alguna manera, puede usar la conexión previa de Sugerencia de recursos para abrir proactivamente una conexión TCP a una fuente (s) específica (s): Además, implementarlas como encabezados HTTP será aún más rápido.
Nota Incluso si usa la preconexión, la cantidad de tiempo perdido disminuirá solo un poco: aún necesita abrir las conexiones apropiadas, y es poco probable que los costos se justifiquen, especialmente para conexiones lentas.
Ajuste de cuentas: pérdida de priorización
El segundo cálculo viene en forma de optimización a nivel de protocolo, que extrañamos cuando dividimos el contenido en dominios. Si usa HTTP / 2, lo que debe hacerse, obtiene acceso a la priorización.
Todos los flujos (por lo tanto, recursos) con la misma conexión TCP conservan prioridad, y el navegador y el servidor trabajan en conjunto para construir el árbol de dependencia de todos estos flujos priorizados, de modo que podamos devolver recursos críticos más rápido y posiblemente retrasar la entrega de los menos importantes.
Nota Técnicamente, debido a la fusión de las conexiones HTTP / 2, las solicitudes se pueden priorizar entre sí en diferentes dominios, siempre que compartan la misma dirección IP.
Si distribuimos nuestros recursos en diferentes dominios, tenemos que abrir varias conexiones TCP únicas. No podemos hacer referencias cruzadas de prioridades para estas conexiones, es decir, perdemos la capacidad de entregar archivos de una manera bien pensada.
Al alojar todo el contenido en un solo alojamiento, podemos construir un árbol de dependencia más complejo. Cada hilo tiene su propia ID, ya que pertenecen al mismo árbol. Si proporcionamos la mayor cantidad de contenido posible de un dominio, podemos permitir que HTTP / 2 haga su trabajo y priorizar los activos de manera más completa con la esperanza de una respuesta más rápida.
Almacenamiento en caché
En general, los hosts de recursos estáticos parecen funcionar bastante bien con la configuración de directivas de larga duración. Esto tiene sentido ya que el contenido estático en las URL versionadas (como se indicó anteriormente) nunca cambiará. Esto hace que sea muy seguro y racional aplicar una política de caché razonablemente agresiva.
Sin embargo, este no es siempre el caso, y al colocar de forma independiente sus recursos, puede desarrollar estrategias de almacenamiento en caché mucho más individuales.
Mito: almacenamiento en caché entre dominios
Más interesante es la capacidad de almacenamiento en caché de activos entre dominios. Es decir, si muchos sitios enlazan con la misma versión de jQuery, ubicada en el CDN, entonces seguramente los usuarios ya tienen este archivo en particular en su computadora. Algo así como el intercambio de recursos entre pares. Este es uno de los argumentos más comunes para utilizar un proveedor de activos estáticos de terceros.
Desafortunadamente, no hay evidencia publicada que respalde estas afirmaciones: no hay razón para creer que esto sea cierto. Por el contrario, un estudio reciente de Paul Calvano sugiere que lo contrario puede ser cierto:
Existe una brecha notable entre la antigüedad de la memoria caché de recursos CSS y las fuentes web de terceros y de terceros. El 95% de las fuentes de terceros son anteriores a 1 semana en comparación con el 50% de las fuentes de terceros que tienen menos de 1 semana. Esto proporciona buenas razones para las fuentes web autohospedadas.
En general, parece que el contenido de terceros se almacena en caché peor que el suyo.
Aún más importante, Safari ha deshabilitado por completo esta función debido a las preocupaciones sobre el abuso de la privacidad, por lo que la tecnología de caché compartida podría no funcionar en el momento de este escrito para el 16% de los usuarios en todo el mundo.
En resumen, aunque esto es teóricamente bueno, no hay evidencia de que el almacenamiento en caché entre dominios sea de alguna manera eficiente.
Acceso CDN
Otro beneficio generalizado de contactar a un proveedor de recursos estáticos es que es probable que use una infraestructura poderosa con capacidades CDN: distribución global, escalabilidad, baja latencia y alta disponibilidad.
Como esto es absolutamente cierto, si le importa su rendimiento, debe ejecutar su propio contenido desde la CDN. Con el nivel de los precios de alojamiento actuales, hay muy pocas excusas por las que no está utilizando esto para sus recursos.
En otras palabras: si cree que necesita una CDN para su jQuery, necesitará una CDN para todo.
Aloje recursos estáticos en su alojamiento
De hecho, hay muy pocas razones para dejar sus recursos estáticos en la infraestructura de otra persona. Los posibles beneficios son a menudo un mito, e incluso si no, los compromisos simplemente no valen la pena. Cargar recursos de diferentes fuentes es mucho más lento. En los próximos días, dedique diez minutos a auditar sus proyectos y tome el control de todos los recursos estáticos de terceros.