{"id":20746,"date":"2026-08-17T18:25:40","date_gmt":"2026-08-17T16:25:40","guid":{"rendered":"https:\/\/webhosting.de\/http-cache-control-header-richtig-einsetzen-web-optimierung\/"},"modified":"2026-08-17T18:25:40","modified_gmt":"2026-08-17T16:25:40","slug":"como-utilizar-correctamente-el-encabezado-cache-control-de-http-optimizacion-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/http-cache-control-header-richtig-einsetzen-web-optimierung\/","title":{"rendered":"C\u00f3mo utilizar correctamente el encabezado HTTP \u00abCache-Control\u00bb para una optimizaci\u00f3n web eficaz"},"content":{"rendered":"<p>Te voy a ense\u00f1ar c\u00f3mo configurar el encabezado HTTP <strong>Control de la cach\u00e9<\/strong> lo utiliza de forma espec\u00edfica para reducir los tiempos de carga, ahorrar solicitudes y gestionar eficazmente las cach\u00e9s del navegador. Obtendr\u00e1s directrices claras, combinaciones \u00fatiles y ajustes pr\u00e1cticos para HTML, CSS, JS, im\u00e1genes y API, sin tener que ir a ciegas, sino con <strong>concreto<\/strong> En unos sencillos pasos.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<p>Los siguientes aspectos fundamentales te guiar\u00e1n sin duda hacia una r\u00e1pida y <strong>fiable<\/strong> Estrategia de cach\u00e9.<\/p>\n<ul>\n  <li><strong>max-age<\/strong> como temporizador: controla el tiempo de conservaci\u00f3n en segundos<\/li>\n  <li><strong>p\u00fablico\/privado<\/strong>: determina qui\u00e9n puede almacenar datos en cach\u00e9<\/li>\n  <li><strong>no-cache<\/strong> vs. <strong>no-store<\/strong>: revalidar en lugar de prohibir<\/li>\n  <li><strong>ETag<\/strong> y <strong>\u00daltima modificaci\u00f3n<\/strong>: Las descargas condicionales ahorran datos<\/li>\n  <li><strong>Versionado<\/strong> + <strong>inmutable<\/strong>: cach\u00e9s largos sin residuos hist\u00f3ricos<\/li>\n<\/ul>\n\n<h2>Conceptos b\u00e1sicos: \u00bfPara qu\u00e9 sirve el encabezado Cache-Control?<\/h2>\n<p>El encabezado contiene instrucciones que determinan si se env\u00eda una respuesta en el <strong>Cache<\/strong> puede estar. Distingo entre las cach\u00e9s del cliente en el navegador y las cach\u00e9s compartidas, como los servidores proxy o las CDN, que suelen dar servicio a varios usuarios y, por lo tanto, suponen una <strong>Eficacia<\/strong> . Mientras que el encabezado \u201eExpires\u201c, ya obsoleto, utiliza una fecha, yo utilizo en \u00abCache-Control\u00bb intervalos de tiempo relativos mediante \u00abmax-age\u00bb, lo cual es menos propenso a errores. De este modo, determino cu\u00e1nto tiempo un recurso permanece \u00abactualizado\u00bb y si debe revalidarse antes de su uso. De este modo, me reservo la opci\u00f3n de controlar los contenidos din\u00e1micos y de mantener los archivos est\u00e1ticos almacenados localmente durante mucho tiempo.<\/p>\n<p>Cache-Control se aplica tanto en las respuestas como en las solicitudes, lo que me resulta \u00fatil para la revalidaci\u00f3n, por ejemplo, en combinaci\u00f3n con ETag o Last-Modified para <strong>Condicional<\/strong> Solicitudes. Por ejemplo, establezco valores agresivos para los activos sin modificar y reglas conservadoras para el HTML. Esta separaci\u00f3n garantiza que las solicitudes posteriores procedan, en la medida de lo posible, de la cach\u00e9 del navegador y, por lo tanto, la <strong>Carga del servidor<\/strong> disminuye. Es importante que haya una coordinaci\u00f3n planificada para no bloquear recursos sin querer ni agotarlos antes de tiempo. Quien tenga en cuenta estos principios sentar\u00e1 las bases para unos tiempos de carga cortos y unas reglas claras en el comportamiento de la cach\u00e9.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/weboptimierung-cachecontrol-4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Directivas importantes explicadas de forma clara<\/h2>\n<p>Con <strong>max-age<\/strong> Establezco la vida \u00fatil de un recurso en segundos, contados a partir de su entrega. Para im\u00e1genes, CSS, JS y fuentes, suelo elegir 31536000 (un a\u00f1o), de modo que en las visitas posteriores se utilice casi todo de forma local. Para las p\u00e1ginas HTML establezco un tiempo m\u00e1s corto, unos 300 segundos, o las combino con la revalidaci\u00f3n, para que los cambios se vean r\u00e1pidamente. Una validez prolongada sin versionado de archivos conduce f\u00e1cilmente a que queden versiones antiguas en la cach\u00e9, por lo que var\u00edo los nombres de los archivos en cada lanzamiento. De este modo, combino una actualizaci\u00f3n rigurosa con <strong>alta<\/strong> Porcentaje de aciertos en la cach\u00e9.<\/p>\n<p>Las directivas <strong>p\u00fablico<\/strong> y <strong>privado<\/strong> controlar qui\u00e9n puede almacenar en cach\u00e9. Asigno el valor \u00abP\u00fablico\u00bb a los contenidos sin personalizaci\u00f3n, para que tambi\u00e9n los servidores proxy y las CDN los almacenen en cach\u00e9. Asigno el valor \u00abPrivado\u00bb cuando solo el navegador del usuario debe conservar una copia, por ejemplo, en las p\u00e1ginas de cuentas. De este modo, evito que los datos personales acaben en cach\u00e9s compartidas y all\u00ed <strong>salirse mal<\/strong>. Esta distinci\u00f3n evita problemas y protege la informaci\u00f3n confidencial.<\/p>\n<p><strong>no-cache<\/strong> A menudo se interpreta err\u00f3neamente: no proh\u00edbe el almacenamiento, pero exige una revalidaci\u00f3n con el servidor antes de volver a utilizar el contenido. Esto resulta adecuado para contenidos que cambian con regularidad, sin necesidad de recargarse por completo cada vez que se acceden. Con ETag o Last-Modified, el cliente guarda los datos localmente y solo comprueba si siguen estando actualizados. De esta forma, evito bytes innecesarios y, aun as\u00ed, mantengo la <strong>Contenido<\/strong> fresco. Sin embargo, para datos altamente sensibles, la opci\u00f3n \u00abno-cache\u00bb resulta demasiado laxa.<\/p>\n<p><strong>no-store<\/strong> Es la medida m\u00e1s estricta, ya que proh\u00edbe cualquier tipo de almacenamiento en el navegador y en los servidores proxy. Lo utilizo para p\u00e1ginas de inicio de sesi\u00f3n, procesos de pago o documentos con datos confidenciales. De este modo, no quedan copias en carpetas temporales que puedan caer accidentalmente en manos equivocadas. Cuando utilizo \u00abno-store\u00bb, suelo combinarlo con \u00abmax-age=0\u00bb para evitar cualquier reutilizaci\u00f3n <strong>excluir<\/strong>. En este caso, la seguridad prima sobre el rendimiento.<\/p>\n<p><strong>debe revalidarse<\/strong> Obliga a consultar al servidor tan pronto como expire el plazo. Si el servidor deja de estar disponible, la cach\u00e9 no debe seguir sirviendo el recurso sin m\u00e1s. Esta directiva es adecuada para \u00e1mbitos en los que la coherencia es m\u00e1s importante que una estrategia de tolerancia a fallos flexible. La utilizo cuando los datos obsoletos podr\u00edan dar lugar a decisiones err\u00f3neas. La regla establece claramente <strong>Car\u00e1cter vinculante<\/strong> durante el proceso.<\/p>\n\n<h2>Directrices ampliadas para las cach\u00e9s compartidas y la fiabilidad<\/h2>\n<p>Adem\u00e1s de la configuraci\u00f3n b\u00e1sica, utilizo <strong>s-maxage<\/strong>, <strong>stale-while-revalidate<\/strong> y <strong>stale-if-error<\/strong>, para gestionar de forma espec\u00edfica los servidores proxy y las CDN, y ofrecer a los usuarios un servicio fluido incluso en caso de incidencias. <em>s-maxage<\/em> Establece un TTL propio solo para las cach\u00e9s compartidas (los navegadores lo ignoran). As\u00ed, por ejemplo, puedo mantener un tiempo de cach\u00e9 corto en el navegador (max-age=600), pero m\u00e1s largo en el per\u00edmetro (s-maxage=86400). <em>stale-while-revalidate<\/em> permite que las cach\u00e9s sigan sirviendo contenidos caducados durante un tiempo determinado, mientras que la actualizaci\u00f3n ya se est\u00e1 llevando a cabo en segundo plano. <em>stale-if-error<\/em> se activa en caso de errores (por ejemplo, 500\/tiempo de espera agotado) y protege la experiencia del usuario mostrando una versi\u00f3n ligeramente anterior, en lugar de mostrar un error grave.<\/p>\n<p>Un modelo pr\u00e1ctico para respuestas de API p\u00fablicas que rara vez se modifican o para mapas de sitio en formato JSON tiene el siguiente aspecto: <code>Cache-Control: public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600<\/code>. De este modo, los navegadores se mantienen relativamente actualizados, las CDN son eficientes y los usuarios no notan ni breves interrupciones ni retrasos en las revalidaciones. Dejo deliberadamente al margen de estas directrices flexibles las \u00e1reas cr\u00edticas o personalizadas.<\/p>\n\n<h2>Interacci\u00f3n con \u00abExpires\u00bb, \u00abETag\u00bb y \u00abLast-Modified\u00bb<\/h2>\n<p>Utilizo <strong>Expira en<\/strong> Como \u00faltimo recurso, ya que Cache-Control permite un control m\u00e1s preciso y tiene prioridad cuando ambos est\u00e1n configurados. Con ETag proporciono una huella digital \u00fanica del recurso, de modo que el navegador pueda iniciar una revalidaci\u00f3n sencilla mediante If-None-Match. \u00abLast-Modified\u00bb proporciona la fecha y la hora de la \u00faltima modificaci\u00f3n y funciona en combinaci\u00f3n con \u00abIf-Modified-Since\u00bb. Ambas opciones ahorran ancho de banda, ya que, si el contenido no ha cambiado, el servidor solo devuelve el estado 304. Esta interacci\u00f3n mantiene los datos cerca del usuario y reduce <strong>Viajes de ida y vuelta<\/strong>.<\/p>\n<p>\u00bfLo compro? <a href=\"https:\/\/webhosting.de\/es\/paquete-de-optimizacion-de-la-validacion-de-la-cache-de-peticiones-condicionales-http\/\">Solicitudes condicionales<\/a>, los costes por visita a la p\u00e1gina se reducen considerablemente, sin que ello impida la publicaci\u00f3n de contenidos nuevos. Esta t\u00e9cnica complementa los valores \u00abmax-age\u00bb reducidos en HTML y garantiza que las visualizaciones est\u00e9n actualizadas. En cambio, en el caso de los recursos con control de versiones, me baso sobre todo en una validez prolongada y evito validaciones innecesarias. De este modo, aligero la carga del <strong>Servidor<\/strong> y agiliza notablemente las visitas posteriores. En definitiva, se crea una ruta de datos optimizada con reglas claras.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/WebOptimizationCacheControl1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>ETag\/Last-Modified en la pr\u00e1ctica: potente, d\u00e9bil y escalable<\/h2>\n<p>En configuraciones distribuidas, me aseguro de que los ETags <em>coherente<\/em> se calculen en todas las instancias. Los ETags basados en archivos que incluyen inodos provocan fallos innecesarios en los cl\u00fasteres. Por eso, en Apache configuro deliberadamente el c\u00e1lculo de ETag:<\/p>\n<pre><code># Apache: ETags coherentes para archivos est\u00e1ticos\nFileETag MTime Size\n# Opcional: eliminar el ETag predeterminado y establecer una l\u00f3gica propia\n\n  #Header unset ETag\n<\/code><\/pre>\n<p>En Nginx, a menudo basta con <code>etag activado;<\/code> para archivos est\u00e1ticos. Para <em>din\u00e1mico<\/em> Yo mismo genero los ETags de las respuestas, idealmente como un hash del cuerpo de la respuesta. Si necesito tolerancia ante peque\u00f1os cambios (por ejemplo, marcas de tiempo formateadas), utilizo <strong>ETags d\u00e9biles<\/strong> (<code>W\/\"...\"<\/code>), que permiten reconocer contenidos sem\u00e1nticamente id\u00e9nticos a pesar de las diferencias en los bytes. Como opci\u00f3n alternativa, utilizo \u00abLast-Modified\u00bb, por ejemplo, con la fecha de actualizaci\u00f3n del registro. Importante: ETag y Last-Modified <em>al mismo tiempo<\/em> No pasa nada por ofrecerlo: el cliente elige qu\u00e9 es lo que admite.<\/p>\n\n<h2>C\u00f3mo utilizar Vary correctamente: personalizaci\u00f3n sin problemas de cach\u00e9<\/h2>\n<p><strong>Variar<\/strong> determina qu\u00e9 encabezados de solicitud se incluyen en la clave de cach\u00e9. Mantengo \u00abVary\u00bb deliberadamente sencillo: <em>Aceptaci\u00f3n de codificaci\u00f3n<\/em> es el valor predeterminado (Gzip\/Brotli), <em>Aceptar idioma<\/em> solo si doy respuestas espec\u00edficas sobre la lengua. De <em>Vary: User-Agent<\/em> No lo recomiendo, porque hace que el tama\u00f1o de la cach\u00e9 se dispare. Si los contenidos dependen de las cookies, prefiero <strong>privado<\/strong> o <strong>no-store<\/strong>, en lugar de tener que gestionar un gran n\u00famero de reglas de Vary. En el caso de los recursos, elimino las cookies innecesarias siempre que sea posible, para que <strong>p\u00fablico<\/strong>-El almacenamiento en cach\u00e9 en el borde entra en funcionamiento. Si utiliza una autenticaci\u00f3n de API mediante encabezados, puede <em>Vary: Autorizaci\u00f3n<\/em> evitar que las cach\u00e9s compartidas mezclen las respuestas de distintos usuarios; sin embargo, a menudo ocurre que <strong>privado<\/strong> La opci\u00f3n mejor y m\u00e1s clara.<\/p>\n<p>Compruebo en DevTools si se establece \u201eVary\u201c de forma involuntaria (por ejemplo, por culpa de middlewares), ya que un \u00abVary\u00bb demasiado amplio reduce enormemente la tasa de aciertos. Unos pocos encabezados, elegidos a conciencia, mantienen la cach\u00e9 manejable y <strong>eficiente<\/strong>.<\/p>\n\n<h2>Estrategias seg\u00fan el tipo de contenido<\/h2>\n<p>Distingo claramente entre contenidos est\u00e1ticos y din\u00e1micos para poder aprovechar las ventajas de ambos. Los recursos est\u00e1ticos tienen una vida \u00fatil prolongada y se identifican claramente mediante nombres de archivo versionados. Trato el HTML y los contenidos personales con mayor cautela, para que los cambios est\u00e9n disponibles r\u00e1pidamente y los datos no acaben en cach\u00e9s err\u00f3neos. Clasifico las API seg\u00fan la frecuencia de los cambios y la sensibilidad de la informaci\u00f3n. Esta clasificaci\u00f3n aporta <strong>Velocidad<\/strong> sin poner en riesgo la confidencialidad y <strong>Correcci\u00f3n<\/strong>.<\/p>\n<p>La siguiente tabla resume los ajustes m\u00e1s pr\u00e1cticos y muestra sus ventajas de un solo vistazo.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Tipo de recurso<\/th>\n      <th>Ejemplo de encabezado<\/th>\n      <th>Por qu\u00e9<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>CSS\/JS\/Im\u00e1genes\/Fuentes<\/td>\n      <td>Cache-Control: public, max-age=31536000, immutable<\/td>\n      <td>Uso prolongado de <strong>Cach\u00e9 del navegador<\/strong>, menos solicitudes<\/td>\n      <td>Nombrar los archivos con versiones para mantener un sistema ordenado <strong>Rodando<\/strong> Actualizaci\u00f3n<\/td>\n    <\/tr>\n    <tr>\n      <td>HTML no personalizado<\/td>\n      <td>Cache-Control: no-cache, must-revalidate (o max-age=300)<\/td>\n      <td>La actualidad sigue siendo elevada, mientras que el volumen de datos sigue siendo reducido<\/td>\n      <td>Con ETag\/Last-Modified para una f\u00e1cil <strong>revalidaci\u00f3n<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>HTML personalizado<\/td>\n      <td>Cache-Control: private, no-cache, must-revalidate<\/td>\n      <td>No se almacena en cach\u00e9s compartidas<\/td>\n      <td>Proteger los datos de la sesi\u00f3n y <strong>Fugas<\/strong> Evite<\/td>\n    <\/tr>\n    <tr>\n      <td>API est\u00e1ticas \/ que cambian raramente<\/td>\n      <td>Cache-Control: public, max-age=3600<\/td>\n      <td>Alta tasa de aciertos en muchos casos <strong>Clientes<\/strong><\/td>\n      <td>Mant\u00e9n la flexibilidad para realizar implementaciones frecuentes<\/td>\n    <\/tr>\n    <tr>\n      <td>API muy din\u00e1micas \/ sensibles<\/td>\n      <td>Cache-Control: no-store, max-age=0<\/td>\n      <td>No se deben almacenar datos confidenciales<\/td>\n      <td>Directo <strong>Actualidad<\/strong> en lugar de riesgo<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>En el caso de galer\u00edas de im\u00e1genes, paquetes grandes de JS o fuentes web, los valores altos de \u00abmax-age\u00bb se amortizan r\u00e1pidamente. Para ello, presto atenci\u00f3n a las cadenas de versi\u00f3n en los nombres de los archivos, para que los usuarios nunca vean paquetes obsoletos. El HTML se mantiene conciso y recurre a la revalidaci\u00f3n, de modo que incluso las peque\u00f1as correcciones en los textos o los precios se publiquen r\u00e1pidamente. Las API siguen sus propias reglas en funci\u00f3n del perfil de uso y de la necesidad de cambios. Esta combinaci\u00f3n ofrece resultados duraderos <strong>flota<\/strong> Visitas a la p\u00e1gina y ahorra <strong>Ancho de banda<\/strong>.<\/p>\n\n<h2>SPA frente a MPA: HTML de \u00edndice corto, recursos largos<\/h2>\n<p>En el caso de las aplicaciones de una sola p\u00e1gina, considero que la <em>\u00cdndice HTML<\/em> de vida especialmente corta (p. ej.,. <code>no-cache, must-revalidate<\/code> o <code>max-age=60<\/code>), ya que controla qu\u00e9 versi\u00f3n de los paquetes se carga. Por el contrario, todos los chunks, fuentes e im\u00e1genes compilados est\u00e1n estrictamente versionados y reciben <code>p\u00fablico, max-age=31536000, inmutable<\/code>. De esta forma me aseguro de que una nueva versi\u00f3n con el HTML de \u00edndice actualizado haga referencia inmediatamente a los nuevos nombres de archivo correctos, mientras que los usuarios actuales siguen utilizando el <em>grandes<\/em> Recuperar los recursos de su cach\u00e9 local.<\/p>\n<p>Las cadenas de consulta como m\u00e9todo para evitar el almacenamiento en cach\u00e9 (<code>?v=123<\/code>) Solo lo utilizo cuando no es posible cambiar f\u00e1cilmente los nombres de los archivos. Es mejor utilizar nombres de archivo \u00fanicos (hashes), ya que segmentan las cach\u00e9s de forma m\u00e1s precisa y generan menos casos especiales.<\/p>\n\n<h2>Configuraci\u00f3n del servidor: Apache y Nginx<\/h2>\n<p>En Apache, suelo configurar los encabezados en el archivo <strong>.htacceso<\/strong>, siempre que el m\u00f3dulo mod_headers est\u00e9 activo. A los recursos est\u00e1ticos les asigno una validez prolongada, mientras que el HTML se trata de forma m\u00e1s estricta. En Nginx lo hago en bloques \u00ablocation\u00bb, a menudo junto con la directiva \u00abexpires\u00bb como alternativa. Compruebo cada cambio con DevTools en la pesta\u00f1a \u00abRed\u00bb para ver los valores reales de los encabezados. De este modo evito reglas err\u00f3neas que, de lo contrario, podr\u00edan acarrear costosas <strong>Consultas err\u00f3neas<\/strong> generar.<\/p>\n<pre><code># Apache (.htaccess)\n\n  \n    Header set Cache-Control \"public, max-age=31536000, immutable\"\n  \n\n  \n    Header set Cache-Control \"no-cache, must-revalidate\"\n<\/code><\/pre>\n<pre><code># Nginx (bloque de servidor)\nlocation ~* \\.(jpg|jpeg|png|gif|css|js|woff2?)$ {\n    expires 365d;\n    add_header Cache-Control \"public, immutable\";\n}\n\nlocation ~* \\.(html)$ {\n    add_header Cache-Control \"no-cache, must-revalidate\";\n}\n<\/code><\/pre>\n<p>Me aseguro de que no haya reglas contradictorias en los servicios de nivel superior que interfieran con estos encabezados. Por ejemplo, una CDN de nivel superior puede establecer sus propios TTL, lo cual debo controlar de forma deliberada. Si todos los niveles coinciden, los recursos se mantienen fiables. <strong>localizable<\/strong> y coherente. Si se revisa todo con cuidado, se evitan largas sesiones de depuraci\u00f3n. Unas peque\u00f1as comprobaciones ahorran mucho trabajo m\u00e1s adelante <strong>Tiempo<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/futuristic-web-optimization-7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pr\u00e1cticas de CDN y proxy: configuraci\u00f3n de \u00abs-maxage\u00bb y estrategias \u00abStale\u00bb<\/h2>\n<p>Para las cach\u00e9s de borde, a\u00f1ado lo siguiente a la configuraci\u00f3n del servidor: <em>s-maxage<\/em> as\u00ed como las directivas Stale. Ejemplo de Apache:<\/p>\n<pre><code># Apache: Reglas optimizadas para CDN\n\n  \n    Header set Cache-Control \"public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600\"\n<\/code><\/pre>\n<p>Y en Nginx:<\/p>\n<pre><code># Nginx: Optimizaci\u00f3n de la cach\u00e9 compartida\nlocation ~* \\.(json|xml|map)$ {\n    add_header Cache-Control \"public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600\";\n}\n<\/code><\/pre>\n<p>Muchas CDN respetan estas directrices directamente. Si tu capa perif\u00e9rica espera encabezados propios (por ejemplo, encabezados sustitutos), reproduzco all\u00ed la l\u00f3gica y mantengo claramente separadas la estrategia del navegador y la de la cach\u00e9 compartida. Gracias al control de versiones, rara vez necesito purgas; si las necesito, las planifico como una intervenci\u00f3n peque\u00f1a y espec\u00edfica.<\/p>\n\n<h2>Casos especiales: redireccionamientos, p\u00e1ginas de error y flujos de trabajo de formularios<\/h2>\n<p><strong>Redireccionamientos:<\/strong> Las respuestas 301 pueden almacenarse en cach\u00e9 seg\u00fan la especificaci\u00f3n. Cuando configuro redireccionamientos temporales (302\/307), asigno tiempos de vida (TTL) claros o configuro deliberadamente <code>no-store<\/code>, para que nada quede fijado de forma definitiva. Las rutas 301 permanentes pueden tener un TTL moderado; en ese caso, los cambios se realizan de forma deliberada y coordinada.<\/p>\n<p><strong>P\u00e1ginas con errores:<\/strong> Las respuestas 404\/410 pueden almacenarse en cach\u00e9 durante un breve periodo de tiempo (por ejemplo,. <code>max-age=60<\/code>), para reducir la carga de los bots. Con los de 500, dependiendo del entorno, <code>stale-if-error<\/code> activa, para que los usuarios prefieran ver una p\u00e1gina antigua que funcione antes que un mensaje de error.<\/p>\n<p><strong>PUBLICAR\/Descargar:<\/strong> Por lo general, las respuestas a las solicitudes POST no se almacenan en la cach\u00e9 del navegador. Para las exportaciones de archivos que contienen datos personales (por ejemplo, facturas), configuro sistem\u00e1ticamente <code>no-store<\/code> adem\u00e1s de una entrega segura (por ejemplo, Content-Disposition), para que nada se mantenga almacenado por error. Por el contrario, las descargas grandes no personalizadas (por ejemplo, versiones nuevas) pueden aprovechar de forma \u00fatil las cach\u00e9s p\u00fablicas durante mucho tiempo.<\/p>\n\n<h2>Evite los errores t\u00edpicos<\/h2>\n<p>Muchos confunden <strong>no-cache<\/strong> con \u201esin cach\u00e9\u201c, lo que genera una carga innecesaria. Como bien has le\u00eddo, \u00abno-cache\u00bb permite el almacenamiento en cach\u00e9, pero exige la revalidaci\u00f3n. Otro error cl\u00e1sico: valores de \u00abmax-age\u00bb muy largos sin versionado en CSS o JS, lo que mantiene archivos obsoletos. La falta de separaci\u00f3n entre el HTML y los recursos est\u00e1ticos merma la velocidad, ya que el HTML rara vez puede almacenarse en cach\u00e9 de forma agresiva. Quien ignore esto, ralentiza la <strong>Experiencia del usuario<\/strong> de.<\/p>\n<p>Los conflictos entre el servidor, la CDN y la aplicaci\u00f3n sabotean los efectos del almacenamiento en cach\u00e9 sin que nos demos cuenta. Por eso, comprueba las sobrescrituras y los niveles intermedios cuando los encabezados cambien \u201ecomo por arte de magia\u201c. En estos casos, resulta \u00fatil analizar la l\u00f3gica y la cadena de respuestas para detectar prioridades err\u00f3neas. Una lista de comprobaci\u00f3n concisa y los errores m\u00e1s comunes relacionados con <a href=\"https:\/\/webhosting.de\/es\/http-cache-headers-sabotear-el-almacenamiento-en-cache-cachefix\/\">Sabotear la cabecera de la cach\u00e9<\/a> facilitan el control. Establecer prioridades claras evita <strong>Efectos secundarios<\/strong> en las implementaciones.<\/p>\n\n<h2>Hacer cuantificable la mejora del rendimiento<\/h2>\n<p>Eval\u00fao los efectos de Cache-Control mediante m\u00e9tricas como el TTFB, el LCP y el n\u00famero de <strong>Solicitudes<\/strong> por visita a la p\u00e1gina. Un vistazo a DevTools me permite ver si los archivos proceden de la \u201ecach\u00e9 del disco\u201c o de la \u201ecach\u00e9 de memoria\u201c. Lighthouse, WebPageTest y otras herramientas similares indican si el almacenamiento en cach\u00e9 del navegador funciona de forma consistente. Realizo mediciones antes y despu\u00e9s de cada cambio para poder ver claramente las mejoras reales. Esta disciplina garantiza las optimizaciones <strong>comprensible<\/strong> y con un objetivo claro.<\/p>\n<p>Las im\u00e1genes de gran tama\u00f1o, las fuentes web y los paquetes tienen un impacto especialmente notable, ya que no se vuelven a cargar en visitas posteriores. Para ello, el c\u00f3digo HTML permanece cerca del servidor, de modo que los usuarios reciben r\u00e1pidamente los nuevos contenidos. Las API se benefician notablemente cuando las rutas m\u00e1s utilizadas tienen un TTL moderado. Los resultados se traducen en tiempos de carga m\u00e1s cortos, un menor volumen de datos y una carga del servidor m\u00e1s estable. Quien compruebe esto de forma sistem\u00e1tica, ahorrar\u00e1 a largo plazo. <strong>Recursos<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/WebOptimierung4102.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Service Worker y cach\u00e9 HTTP: evitar que funcionen en contra<\/h2>\n<p>Si utilizo un Service Worker, su estrategia debe coincidir con mis encabezados HTTP. Para los recursos est\u00e1ticos y versionados, lo m\u00e1s adecuado es \u201ecache-first\u201c con un TTL largo y <em>inmutable<\/em> Excelente. Para HTML o datos de API que cambian con frecuencia, prefiero \u201enetwork-first\u201c o \u201estale-while-revalidate\u201c, para que los usuarios vean las respuestas r\u00e1pidamente y la informaci\u00f3n actualizada llegue sin demora. Importante: el Service Worker debe respetar las revalidaciones (transmitir \u00abIf-None-Match\u00bb\/\u00abIf-Modified-Since\u00bb), en lugar de retener el contenido de forma artificial.<\/p>\n<p>Adem\u00e1s, quiero dejar claro lo siguiente: la cach\u00e9 HTTP ya puede encargarse de gran parte del trabajo; el Service Worker complementa ese comportamiento, no lo sustituye. De este modo, la depuraci\u00f3n y el funcionamiento siguen siendo manejables.<\/p>\n\n<h2>Comprender las directivas del lado de la solicitud<\/h2>\n<p>Las solicitudes tambi\u00e9n pueden controlar el almacenamiento en cach\u00e9. <code>Cache-Control: no-cache<\/code> en <em>Solicitar<\/em> fuerza una revalidaci\u00f3n en el servidor, <code>max-age=0<\/code> es parecido. <code>no-store<\/code> En la solicitud se proh\u00edbe el almacenamiento de la respuesta a lo largo de la cadena. Para los casos sin conexi\u00f3n, se puede <code>solo si est\u00e1 en cach\u00e9<\/code> Puede resultar \u00fatil: en ese caso, el cliente solo acepta respuestas procedentes de la cach\u00e9. Este mecanismo resulta \u00fatil en aplicaciones que deben ofrecer una experiencia definida incluso con una conexi\u00f3n d\u00e9bil.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/WebOptimization_9254.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Buenas pr\u00e1cticas para tu flujo de trabajo<\/h2>\n<p>Empezar\u00e9 por hacer un balance: qu\u00e9 tipos de archivos hay, cu\u00e1les est\u00e1n personalizados y cu\u00e1les rara vez cambian. A continuaci\u00f3n, aplicar\u00e9 reglas de forma diferenciada para que los activos permanezcan mucho tiempo en el <strong>Cache<\/strong> y el HTML se mantenga actualizado. Las cadenas de versi\u00f3n en el nombre del archivo eliminan el riesgo de paquetes obsoletos y permiten tiempos de ejecuci\u00f3n m\u00e1s r\u00e1pidos. Durante las ventanas de mantenimiento peri\u00f3dicas, compruebo los encabezados y las tasas de visitas para detectar las tendencias con antelaci\u00f3n. Esta rutina mantiene el sitio <strong>performante<\/strong> y predecible.<\/p>\n<p>Documento las configuraciones de forma breve y clara, para que los cambios futuros no provoquen errores involuntarios. Los scripts de implementaci\u00f3n actualizan autom\u00e1ticamente los hash de los archivos, para que no se me olvide ning\u00fan paso. Para las versiones, utilizo implementaciones con alcance limitado para comprobar el comportamiento en el entorno real. La informaci\u00f3n obtenida de la monitorizaci\u00f3n y los registros se incorpora directamente a las reglas de encabezado. De este modo, la estrategia se mantiene realista y <strong>eficaz<\/strong>.<\/p>\n\n<h2>Control de versiones y activos inmutables<\/h2>\n<p>A\u00f1ado hash a los nombres de los archivos, por ejemplo, app.20260817.js, y luego establezco \u00abpublic\u00bb, \u00abmax-age=31536000\u00bb, <strong>inmutable<\/strong>. De este modo, el navegador sabe que el archivo nunca cambia \u201esilenciosamente\u201c y se ahorra tener que volver a validarlo. En la siguiente versi\u00f3n, el archivo recibe un nuevo nombre, lo que hace que el navegador cargue exactamente la nueva versi\u00f3n. As\u00ed evito que haya versiones obsoletas tras una implementaci\u00f3n. Esta t\u00e1ctica encaja bien con muchas <a href=\"https:\/\/webhosting.de\/es\/estrategias-de-control-de-cache-http-alojamiento-cachemaster\/\">Estrategias de control de cach\u00e9<\/a> las m\u00e1s diversas pilas.<\/p>\n<p>Para HTML no utilizo \u00abimmutable\u00bb, porque la p\u00e1gina cambia a menudo y quiero una revalidaci\u00f3n flexible. Lo mismo se aplica a las respuestas de las API con datos variables. Las fuentes y las im\u00e1genes grandes son las que m\u00e1s se benefician, ya que los usuarios las utilizan varias veces en distintos dispositivos. Sigue siendo importante una asignaci\u00f3n completa de los hash a las versiones. La documentaci\u00f3n y una clara <strong>Nombres<\/strong> evitar confusiones en el equipo y en las configuraciones.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/weboptimization-header-8274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pasos pr\u00e1cticos para la comprobaci\u00f3n y la depuraci\u00f3n<\/h2>\n<p>Abro DevTools y, en la pesta\u00f1a \u00abRed\u00bb, reviso los encabezados de la respuesta para comprobar Cache-Control, ETag, Expires y <strong>Variar<\/strong> para comprobarlo. Al volver a cargar la p\u00e1gina sin cach\u00e9 (Ctrl+F5), puedo ver si las reglas se aplican realmente. A continuaci\u00f3n, la cargo normalmente y compruebo qu\u00e9 elementos se obtienen de la cach\u00e9. En el caso de los proxies y las CDN, compruebo los encabezados como \u00abAge\u00bb o \u00abX-Cache\u00bb, si est\u00e1n disponibles. Estas comprobaciones detectan conflictos y errores <strong>Prioridades<\/strong> r\u00e1pidamente.<\/p>\n<p>A nivel de servidor, comparo la configuraci\u00f3n y los registros para detectar discrepancias. Un error frecuente: una aplicaci\u00f3n a\u00f1ade encabezados a posteriori y anula las reglas del servidor. En los procesos de CI\/CD, compruebo autom\u00e1ticamente los encabezados en el entorno de prueba para evitar sorpresas en el sistema en producci\u00f3n. Si surgen problemas, recurro temporalmente a TTL cortos hasta que se localiza la causa. Con pruebas claras, me aseguro de que <strong>Controlar<\/strong> sobre el comportamiento del almacenamiento en cach\u00e9 en todas las capas.<\/p>\n\n<h2>La realidad de los navegadores: tipos de almacenamiento y limpieza<\/h2>\n<p>Los navegadores distinguen entre cach\u00e9 de memoria y cach\u00e9 de disco. Los archivos peque\u00f1os que se utilizan con frecuencia se benefician de la cach\u00e9 de memoria (accesos extremadamente r\u00e1pidos), mientras que los recursos de gran tama\u00f1o suelen almacenarse en el disco. Los dispositivos m\u00f3viles limpian la cach\u00e9 de forma m\u00e1s agresiva; por eso no preveo ninguna estrategia que se base exclusivamente en una persistencia muy prolongada en el navegador, sino que me aseguro de contar con buenas v\u00edas de revalidaci\u00f3n. <em>inmutable<\/em> Aunque evita revalidaciones innecesarias, esto solo es as\u00ed mientras la entrada no se haya eliminado por falta de espacio.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/futuristic-web-optimization-7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Para llevar<\/h2>\n<p>Establecer <strong>Control de la cach\u00e9<\/strong> Aplica de forma selectiva: tiempos de vida largos y la propiedad \u00abimmutable\u00bb para los activos versionados; reglas prudentes y revalidaci\u00f3n para el HTML y los contenidos personales. Combina \u00abmax-age\u00bb con \u00abETag\u00bb o \u00abLast-Modified\u00bb para ahorrar ancho de banda y garantizar la actualidad. Comprueba todos los niveles, incluida la CDN, para que las reglas no se contrarresten entre s\u00ed. Evita utilizar \u00abno-store\u00bb por puro instinto y recurre a \u00e9l solo cuando la protecci\u00f3n de datos sea una prioridad absoluta. Con una separaci\u00f3n clara por tipo de contenido, un control de versiones coherente y una medici\u00f3n continua, conseguir\u00e1s p\u00e1ginas notablemente m\u00e1s r\u00e1pidas y mantendr\u00e1s la <strong>Soberan\u00eda<\/strong> sobre tu actividad de geocaching.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprende a utilizar correctamente los encabezados HTTP \u00abCache-Control\u00bb para mejorar el almacenamiento en cach\u00e9 del navegador y la optimizaci\u00f3n web. Nos centraremos en estrategias de cach\u00e9 seguras y eficaces.<\/p>","protected":false},"author":1,"featured_media":20739,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[679],"tags":[],"class_list":["post-20746","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-seo"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"172","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Cache-Control","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20739","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20746","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20746"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20746\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20739"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20746"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20746"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20746"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}