add_header Cache-Control \"max-age=31536000, immutable\";<\/code><\/div>\nSi est\u00e1 usando Nginx, simplemente agregue el comando:<\/p>\n
A partir de ahora, el navegador tiene derecho a almacenar en el cach\u00e9 los recursos hasta por un a\u00f1o (lo cual es casi para siempre). El nuevo par\u00e1metro “inmutable” indica que el recurso no va a cambiar.<\/p>\n
Por supuesto, surge la pregunta: \u00bfy si necesitamos cambiar el recurso almacenado? La respuesta es simple: cambie su direcci\u00f3n URL.<\/p>\n
Por ejemplo, puede agregar una versi\u00f3n a un nombre de archivo. Para los documentos HTML, este m\u00e9todo tambi\u00e9n es aplicable, pero, como regla general, se utiliza un per\u00edodo m\u00e1s corto de almacenamiento en cach\u00e9 (por ejemplo, un minuto o una hora).<\/p>\n
<\/p>\n
Compresi\u00f3n de datos<\/h3>\n
Una pr\u00e1ctica obligatoria es la compresi\u00f3n de cualquier informaci\u00f3n de texto cuando se transfiere desde el servidor al navegador. La mayor\u00eda de los servidores web tienen una implementaci\u00f3n de respuestas en gzip-compression.<\/p>\n
Sin embargo, la activaci\u00f3n de una compresi\u00f3n simple no es suficiente.<\/p>\n
Primero, la relaci\u00f3n de compresi\u00f3n es ajustable y debe estar cerca del m\u00e1ximo.<\/p>\n
En segundo lugar, se puede usar la compresi\u00f3n est\u00e1tica, es decir, precomprimir archivos y colocarlos en el disco. Luego, el servidor web buscar\u00e1 la versi\u00f3n comprimida y la har\u00e1 llegar de inmediato.<\/p>\n
En tercer lugar, se puede utilizar algoritmos de compresi\u00f3n m\u00e1s eficientes: zopfli (compatible con gzip) y brotli (un nuevo algoritmo de compresi\u00f3n). Brotli solo funcionar\u00e1 con HTTPS.<\/p>\n
Como estos algoritmos (especialmente zopfli) son costosos cuando se trata de comprimir, siempre los usamos en la versi\u00f3n est\u00e1tica.<\/p>\n
Para maximizar el efecto de la compresi\u00f3n de archivos, el proceso de \u201cminificaci\u00f3n\u201d se aplica de manera preliminar: elimina traducciones innecesarias de cadenas, espacios y otros caracteres innecesarios. Este proceso es espec\u00edfico para cada formato. Adem\u00e1s, se debe comprimir otros datos de texto en el sitio.<\/p>\n
<\/p>\n
Usando el CDN<\/h2>\n
<\/p>\n
Aplicar el CDN (red de entrega de contenido) para la aceleraci\u00f3n del sitio web es una medida muy punlicitada, que tiene un mont\u00f3n de marketing en torno a su esencia tecnol\u00f3gica.<\/p>\n
<\/p>\n
Teor\u00eda: el porqu\u00e9<\/h3>\n
Inicialmente, los CDN se dise\u00f1aron para descargar los canales de Internet de los sitios web de medios de difusi\u00f3n. Por ejemplo, cuando se ve un video en vivo, varios miles de espectadores crean una carga muy pesada en el ancho de la banda del servidor.<\/p>\n
Adem\u00e1s, se pensaron para garantizar la calidad ininterrumpida de la comunicaci\u00f3n con grandes clientes y la eliminaci\u00f3n del servidor que es extremadamente dif\u00edcil (debido a retrasos e inestabilidad de la red).<\/p>\n
La soluci\u00f3n a este problema fue crear un CDN, es decir, una red distribuida a la que los clientes (por ejemplo, los espectadores) estaban conectados, y los hosts de esta red ya est\u00e1n en el servidor (origen). Al mismo tiempo, el n\u00famero de conexiones al servidor se redujo a uno (de varios), y el n\u00famero de conexiones al CDN podr\u00eda llegar a millones debido al almacenamiento en cach\u00e9 del contenido de la red.<\/p>\n
Hoy en d\u00eda, la mayor\u00eda de los CDN se posicionan como un medio para acelerar los sitios web, principalmente al reducir la distancia entre el contenido y el cliente (el visitante del sitio).<\/p>\n
<\/p>\n
Posibles efectos<\/h3>\n
\u00bfC\u00f3mo se puede acelerar un sitio usando CDN?<\/p>\n
S\u00ed, de hecho, por regla general, el usuario se conecta al servidor de red m\u00e1s cercano (seg\u00fan su tiempo de acceso) y obtiene un r\u00e1pido procesamiento para establecer la conexi\u00f3n TCP y TLS. Adem\u00e1s, si el contenido est\u00e1 en el servidor CDN, el usuario puede recibirlo r\u00e1pidamente. Por lo tanto, la carga en nuestro propio servidor se reduce.<\/p>\n
En segundo lugar, el CDN no puede simplemente distribuir contenido sin cambios, sino optimizarlo por su lado y entregarlo en una forma m\u00e1s compacta: este comprime im\u00e1genes, aplica compresi\u00f3n a la prueba, entre tantas otras pr\u00e1cticas. Debido a tales optimizaciones, puede obtener un tiempo de descarga m\u00e1s corto.<\/p>\n
<\/p>\n
Desventajas del uso de CDN<\/h3>\n
Las desventajas, como de costumbre, siguen tras las ventajas: el objeto puede no estar en la memoria cach\u00e9 del nodo CDN. Por ejemplo, a\u00fan no se ha solicitado o no se puede almacenar en cach\u00e9 (como un documento HTML). En este caso, tenemos retrasos adicionales entre el nodo CDN y nuestro servidor.<\/p>\n
A pesar de que las CDN est\u00e1n dise\u00f1adas para acelerar el acceso al sitio, hay situaciones en las que la ruta de la red ser\u00e1 menos \u00f3ptima que sin la CDN. Es especialmente importante para las CDN globales, para lo cual Rusia no es un mercado prioritario.<\/p>\n
Finalmente, las redes de entrega de contenido son sistemas muy complejos, donde los bloqueos, la inestabilidad y otros problemas tambi\u00e9n son posibles en todas partes. Usando CDN, agregamos un nivel m\u00e1s de complejidad.<\/p>\n
<\/p>\n
Nosotros optimizamos los resultados<\/h2>\n
<\/p>\n
Digamos que usted logr\u00f3 alcanzar una buena velocidad en su sitio web. Los usuarios y los propietarios del lugar est\u00e1n contentos. \u00bfSignifica que puede olvidarse del problema de la velocidad? Por supuesto que no. Por supuesto no. Para lograr una calidad constante en el trabajo del sitio, debe monitorear el sitio web<\/a> de forma permanente.<\/p>\n <\/p>\n
Soporte de aceleraci\u00f3n<\/h3>\n
Cualquier proyecci\u00f3n web en vivo se actualiza regularmente, los cambios ocurren tanto en plantillas comunes (temas de dise\u00f1o, interfaces) como en contenido. Adem\u00e1s, el c\u00f3digo fuente (tanto en cliente como en servidor) est\u00e1 cambiando activamente.<\/p>\n
Cada cambio puede afectar la velocidad del sitio. Para monitorear este impacto, se debe implementar un sistema de monitoreo de velocidad sint\u00e9tica de sitio sint\u00e9tico en la etapa de desarrollo. Por lo tanto, los problemas de velocidad pueden ser interceptados antes de que los usuarios los noten.<\/p>\n
Para optimizar el contenido entrante o nuevo, se requiere la integraci\u00f3n de procedimientos de optimizaci\u00f3n en el sistema de gesti\u00f3n de contenido. En primer lugar, esto se refiere al procesamiento de im\u00e1genes.<\/p>\n
La aceleraci\u00f3n de sitios es un \u00e1rea muy din\u00e1mica; est\u00e1n surgiendo nuevos est\u00e1ndares y su soporte por parte de los navegadores est\u00e1 cambiando. Por lo tanto, es importante auditar peri\u00f3dicamente la tecnolog\u00eda del proyecto, los procesos y el software utilizado.<\/p>\n
<\/p>\n
Monitoreo de la velocidad real del usuario<\/h3>\n
Las pruebas sint\u00e9ticas en condiciones ideales de laboratorio son muy \u00fatiles para evaluar los cambios en el c\u00f3digo fuente, pero no son suficientes. Al final, queremos que el sitio funcione r\u00e1pido para usuarios reales. Para recopilar estos datos, hay un control de velocidad en el lado del usuario (RUM – monitoreo real del usuario).<\/p>\n
Para organizar el RUM, basta con conectar uno de los sistemas de an\u00e1lisis web (Yandex.Metrica, Google Analytics) y ver informes sobre el momento de la descarga del sitio. Para obtener datos m\u00e1s detallados y precisos, se pueden usar servicios especializados de monitoreo de velocidad.<\/p>\n
<\/p>\n
Conclusiones<\/h3>\n
El tema de velocidad del sitio web es extenso y afecta muchos aspectos del desarrollo y soporte de una aplicaci\u00f3n web: desde el c\u00f3digo del servidor hasta el contenido del mismo. Esto significa que obtener buenos resultados es imposible sin involucrar al equipo de desarrollo.<\/p>\n
Lo m\u00e1s importante: recuerde a los usuarios y tenga en cuenta las diversas condiciones para usar el sitio.<\/p>\n
La aceleraci\u00f3n del sitio es un proceso que ocurre con diferente intensidad a lo largo del ciclo de vida del proyecto.<\/p>","protected":false},"excerpt":{"rendered":" Todos saben que un sitio web lento es malo. Cuando una plataforma de este tipo se frena al cargar, surgen problemas serios en la soluci\u00f3n de las tareas cotidianas. A veces es simplemente molesto. A menudo, el frenado del sitio es un colapso, y con este existe un servicio negativo: las personas no esperan…","protected":false},"author":10380808,"featured_media":3348,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"pages-templates\/pages-minitools-3.php","meta":[],"categories":[60],"tags":[],"_links":{"self":[{"href":"https:\/\/test.sitechecker.pro\/es\/wp-json\/wp\/v2\/pages\/1063"}],"collection":[{"href":"https:\/\/test.sitechecker.pro\/es\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/test.sitechecker.pro\/es\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/test.sitechecker.pro\/es\/wp-json\/wp\/v2\/users\/10380808"}],"replies":[{"embeddable":true,"href":"https:\/\/test.sitechecker.pro\/es\/wp-json\/wp\/v2\/comments?post=1063"}],"version-history":[{"count":0,"href":"https:\/\/test.sitechecker.pro\/es\/wp-json\/wp\/v2\/pages\/1063\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/test.sitechecker.pro\/es\/wp-json\/wp\/v2\/media\/3348"}],"wp:attachment":[{"href":"https:\/\/test.sitechecker.pro\/es\/wp-json\/wp\/v2\/media?parent=1063"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/test.sitechecker.pro\/es\/wp-json\/wp\/v2\/categories?post=1063"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/test.sitechecker.pro\/es\/wp-json\/wp\/v2\/tags?post=1063"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}