Niveles de caché en el alojamiento aceleran la ejecución de PHP, el acceso a la base de datos y la entrega de páginas completas a través de la provisión global mediante servidores edge. Le mostraré cómo funcionan conjuntamente las cachés de opcode, objetos, páginas y CDN, dónde entran en juego y qué ajustes tienen el mayor efecto.
Puntos centrales
- Opcode La caché precompila PHP y reduce la carga de las CPU en cada petición.
- Objeto La caché mantiene los resultados frecuentes de la base de datos en la memoria RAM y guarda las consultas.
- Página La caché entrega el HTML terminado a los visitantes en milisegundos.
- CDN La caché distribuye los contenidos a servidores periféricos de todo el mundo y reduce las latencias.
- Interacción de todos los niveles elimina los cuellos de botella desde el backend hasta el borde.
Qué hacen los niveles de caché
Utilizo cuatro Nivelespara reducir los tiempos de carga y la carga del servidor: opcode, objeto, página y CDN. Cada nivel aborda un cuello de botella diferente y funciona en su propio nivel de la infraestructura. De este modo, ahorro tiempo de CPU al ejecutar código, reduzco las consultas a bases de datos, entrego HTML directamente y acerco geográficamente el contenido al usuario. Primero doy prioridad al mayor cuello de botella y poco a poco voy añadiendo más cachés al resto. Esto despeja Secuencia hace que la optimización sea mensurable y estable.
Opcode Cache: Ejecutar PHP inmediatamente
La caché de opcodes almacena los opcodes PHP precompilados en el directorio RAMpara que el intérprete no vuelva a funcionar con cada petición. Activo OPcache con valores límite razonables para la memoria, la caché de archivos y la revalidación para que las rutas de código calientes estén disponibles permanentemente. Las páginas CMS en particular se benefician porque las llamadas recurrentes ya no activan la compilación. Esto reduce notablemente la carga de la CPU y el tiempo de respuesta del servidor web. Compruebo regularmente las estadísticas de OPcache para analizar la Índice de aciertos de la caché alto.
Caché de objetos: Aliviar la base de datos
La caché de objetos almacena los resultados frecuentes de Consultas en memoria, por ejemplo menús, listas de productos o derechos de usuario. Para ello utilizo servicios en memoria como Redis o Memcached y asigno TTL significativos a los datos volátiles. Esto me permite reducir significativamente los viajes de ida y vuelta a la base de datos, que se mantiene estable, especialmente con mucho tráfico. En WordPress, combino una caché de objetos persistente con exclusiones selectivas para que no se distorsione el contenido personalizado. Si quieres empezar, puedes encontrar una guía compacta en mi artículo sobre Redis para WordPress. Observo el Tasa perdidareajustar las llaves con una vida útil demasiado corta.
Caché de página: Entregar HTML
La caché de páginas crea HTML-páginas que el sistema ha generado dinámicamente. Defino reglas claras: los visitantes anónimos reciben copias estáticas, los usuarios registrados pasan por alto la caché. Durante las actualizaciones, borro específicamente las páginas afectadas para que el contenido permanezca actualizado. Esto merece la pena, especialmente durante los picos de tráfico, porque reduzco la carga del backend prácticamente a cero. En mi Guía de almacenamiento en caché. Compruebo regularmente el Time-To-First-Byte para comprobar el Efecto para verificarlo.
Caché CDN: globalmente rápida
Una CDN lleva los contenidos a Borde-servidor cercano al usuario, reduciendo así la latencia. Almaceno en caché activos como imágenes, CSS y JS y, si es necesario, páginas completas mediante caché de página completa. Las reglas para cookies, cabeceras y parámetros de consulta evitan la entrega incorrecta de contenidos personalizados. Para grupos destinatarios internacionales, acorto notablemente los tiempos de carga y reduzco la carga de mi servidor de origen. Si quiere saber más sobre la configuración, haga clic en mi resumen del Optimización CDN. Mantengo los mecanismos de purga listos para que pueda proporcionar inmediatamente fresco Versiones a entregar.
Comparación de los niveles de caché
El siguiente cuadro clasifica Utilice y efecto para que me dirija primero al nivel correcto.
| Nivel | Almacén | Aplicación típica | Principales ventajas |
|---|---|---|---|
| Caché de opcodes | Servidor (RAM) | Sitios web basados en PHP, CMS | Ejecución más rápida, menos CPU |
| Caché de objetos | Servidor (RAM) | Consultas frecuentes a BBDD en tiendas/CMS | Menos consultas, tiempos de respuesta cortos |
| Caché de página | Servidor y/o CDN | Páginas vistas anónimas | TTFB muy corto, reducción de carga |
| Caché CDN | Servidor Edge | Entrega global de páginas/activos | Baja latencia, alta escalabilidad |
Fijé los niveles en esto Secuencia primero opcode, luego objeto, luego página y por último CDN. Así evito duplicar el trabajo y consigo primero los efectos más notables.
Interacción de los niveles
En mi proceso, el Opcode Almacena en caché el primer PHP sin recompilar. La caché de objetos entrega datos frecuentes desde la RAM, dejando libre la base de datos. La caché de páginas sirve páginas recurrentes directamente y ahorra capas de PHP y DB. Un CDN proporciona contenido cerca del usuario en todo el mundo e intercepta los picos de tráfico. Esta cadena reduce cualquier tiempo de espera porque hago específicamente cada etapa más rápida y reduzco las dependencias. Mantengo esto Ruta transparente para que la depuración siga siendo fácil.
TTL, purga y validación de caché
Perdono conscientemente TTLs para cada nivel, de modo que el contenido no sea ni demasiado antiguo ni demasiado efímero. Para las versiones, utilizo la purga por ruta, etiqueta o clave para purgar específicamente en lugar de borrar todo. Las cachés de borde respetan las señales de control, como el control de caché, el control sustituto o ETag. Para los contenidos personalizados, utilizo cabeceras Vary o reglas de cookies para evitar la mezcla de cachés. Pruebo la invalidación en sistemas de staging antes de colocar campañas más grandes. Esto mantiene el contenido coherenteaunque combine muchos niveles.
Medición: porcentaje de aciertos y fallos
Mido el Tasa de aciertos por separado para cada nivel, de modo que la causa y el efecto queden claros. Para OPcache, compruebo la utilización de la memoria, las revalidaciones y las compilaciones. Para la caché de objetos, controlo los errores por clave y ajusto los TTL. En la caché de páginas, establezco una correlación entre HIT/MISS y TTFB para ver el efecto en los usuarios. En la CDN, controlo las latencias regionales y los índices de aciertos en los bordes para asegurarme de que todos los sitios funcionan de forma fiable. Estas cifras clave controlan mi Optimizaciones.
Casos extremos: contenidos dinámicos
Almaceno mucho en caché las páginas de inicio de sesión, las cestas de la compra o los cuadros de mando personalizados. cauteloso. Trabajo con excepciones, cabeceras sin caché, TTLs cortos o Edge Side Includes (ESI) para subáreas. Los parámetros de búsqueda o las cookies de sesión pueden generar variantes que limito deliberadamente. Las API también se benefician del almacenamiento en caché, pero requieren una invalidación exacta para las versiones. Para los contenidos muy volátiles, utilizo más la caché de objetos que la de páginas. Así que las respuestas siguen siendo correctosin perder velocidad.
Configuración por tipo de alojamiento
En el alojamiento compartido activo OPcache y utilizar una caché de objetos persistente, si está disponible. En entornos VPS o dedicados, proporciono Redis/Memcached, aíslo los recursos y configuro la supervisión. Para la caché de páginas, elijo soluciones del lado del servidor o módulos integrados de la pila. También conecto una CDN si los grupos de destino están distribuidos o hay picos pendientes. Documento todas las reglas de la caché para que los miembros del equipo puedan implantar los cambios con seguridad. Estandarizado Normas evitar errores de configuración.
Seguridad y almacenamiento en caché
Combino CDN-caching con mecanismos de protección como limitación de velocidad y reglas WAF. Esto me permite amortiguar los picos de carga y alejar los patrones maliciosos antes de que lleguen al origen. La terminación TLS en el extremo reduce la latencia y alivia la carga de los sistemas anfitriones. Nunca almaceno en caché contenido sensible, por ejemplo áreas de administración o datos personales. Compruebo los registros con regularidad para que las desviaciones y purgas de caché sigan siendo rastreables. Seguridad Velocidad no son mutuamente excluyentes si las normas son claras.
Encabezado HTTP en detalle: control preciso
Las cabeceras limpias determinan la fiabilidad de las cachés. Yo utilizo Control de la caché como señal primaria y combinarla en función del nivel: public, max-age para navegadores/proxies y s-maxage para cachés compartidas. stale-while-revalidate le permite ofrecer brevemente contenidos obsoletos mientras se actualizan en segundo plano. Con stale-if-error Mantengo el sitio en línea, aunque la fuente no esté disponible temporalmente. ETag y Última modificación ayudan con las consultas condicionales; yo las utilizo específicamente cuando el contenido debe revalidarse con frecuencia en lugar de retransmitirse por completo. Variar Las limito a las dimensiones realmente necesarias (por ejemplo, cookie para usuarios registrados, aceptar codificación para compresión) para que no haya una explosión incontrolable de variantes. Para las cachés de borde utilizo Control sustitutopara controlar los TTL específicos de CDN sin afectar al almacenamiento en caché del navegador.
Calentamiento y precarga de la caché
Para evitar arranques en frío, caliento los cachés proactivo sobre: Tras un despliegue, hago que las rutas importantes, las páginas de categorías y las páginas de destino se rendericen automáticamente y se coloquen en la caché de la página y la CDN. Priorizo en función del tráfico, la relevancia para las ventas y la profundidad de la navegación. Los mapas del sitio, los gráficos de enlaces internos o los registros de los últimos días sirven de fuente. La precarga se regula para no sobrecargar la fuente. En el caso de las cachés de objetos, precargo las agregaciones costosas o las estructuras de autorización para que la primera oleada de usuarios tras un lanzamiento reciba respuestas rápidas de forma constante.
Versionado y eliminación de cachés
Proporciono activos estáticos con Contenido hash en el nombre del archivo (por ejemplo, app.abc123.css). Esto me permite establecer TTL muy largos sin riesgo de bloqueo. En la publicación, sólo cambia la URL, las cachés retienen las versiones antiguas hasta que caducan. Para las respuestas HTML o API, trabajo con Etiquetas de caché o claves estructuradas que permitan una purga selectiva (por ejemplo, todas las páginas de un producto). Cuando el etiquetado no es posible, planifico las purgas por rutas y aseguro que haya suficiente espacio en la caché para que los nuevos objetos puedan colocarse inmediatamente. Importante: nada de no-store en activos, de lo contrario regalo ganancias de rendimiento global.
Evitar la estampida de cachés
Si una clave de uso frecuente queda fuera de la caché, se corre el riesgo de Cocina atronadora-situación. Evito esto con Solicitar coalescenciaSólo se permite calcular a la primera miss, todas las demás esperan su resultado. En las cachés de objetos, establezco bloqueos con un TTL corto para evitar el trabajo duplicado. También utilizo Actualización tempranaSi una clave está a punto de caducar, unos cuantos procesos en segundo plano la renuevan mientras los usuarios siguen recibiendo la versión antigua y válida. Utilizo el jitter (desplazamiento aleatorio) para distribuir los procesos de modo que miles de claves no caduquen al mismo tiempo. A nivel de API, la idempotencia ayuda a permitir las repeticiones sin efectos secundarios.
Personalización, pruebas A/B y variantes
Cuando la personalización es inevitable, la limito a mínimo off. En lugar de variar toda la página, renderizo pequeños fragmentos no almacenables en caché (ESI) o los recargo en el lado del cliente. Con Pruebas A/B Evito las variantes basadas en cookies para todos los activos; de lo contrario, todo acaba en la caché privada del navegador y las cachés compartidas se vuelven inútiles. En su lugar, sólo encapsulo la parte relevante de la página o trabajo con playout del lado del servidor que no rompe la caché de la página. Para la selección de moneda o idioma, defino rutas únicas (por ejemplo, /de/, /en/) en lugar de Accept-Language para que las cachés reciban claves deterministas.
Compresión, formatos y Vary
Gzip o Palito de pan reducen el tamaño de transferencia, pero también influyen en las claves de caché: Mantengo magra la codificación Vary: Accept y me aseguro de que las cachés de los bordes puedan guardar variantes precomprimidas. Optimizo las imágenes con formatos modernos (WebP, AVIF) y tamaños compatibles con los dispositivos. Procuro no establecer ninguna variable innecesaria en los agentes de usuario para evitar una avalancha de variantes. Son mejores unos pocos puntos de interrupción claramente definidos o atributos de imagen responsive que puedan almacenarse en caché de forma limpia. Para los paquetes CSS/JS críticos, utilizo el almacenamiento en caché prolongado más el versionado para servir el tráfico recurrente desde la caché con un coste prácticamente nulo.
El ajuste de OPcache en la práctica
Para OPcache Planifico generosamente la memoria RAM para que los scripts de uso frecuente no se vean desplazados. Controlo el número de revalidaciones y compilaciones; si aumentan, incremento la memoria de guiones u optimizo el autoloader. caché de archivos para la precarga puede reducir los arranques en frío si los despliegues son poco frecuentes. Una estrategia de despliegue consistente es importante: si las marcas de tiempo cambian con frecuencia, OPcache invalida permanentemente - minimizo los cambios innecesarios en muchos archivos al mismo tiempo. Utilizo la precarga para inicializar las clases críticas al principio, de forma que las primeras peticiones se beneficien inmediatamente.
Caché de API y microservicios
Recibir API propio Estrategias de caché. Los endpoints GET con resultados estables obtienen TTLs y ETags claros, mientras que los POST/PUT no son cacheables. Etiqueto las claves según los objetos de dominio (por ejemplo, user:123, product:456) y obtengo la invalidación directamente de los eventos del sistema. Para GraphQL, agrego a nivel de campo y almaceno en caché subárboles frecuentes para mitigar las consultas N+1. Combino los límites de velocidad con el almacenamiento en caché para que las agregaciones caras no se vuelvan a calcular sin control. Las cachés de borde pueden mantener las respuestas de la API a nivel regional siempre que los requisitos de coherencia lo permitan.
Control y observabilidad
Amplío las respuestas Cabecera de diagnóstico (por ejemplo, HIT/MISS, Edad, Revalidar) para ver el comportamiento sobre el terreno. En los registros, correlaciono códigos de estado, TTFB y tiempos de subida; un aumento repentino de MISS con un pico simultáneo de CPU indica un desalojo de la caché o una invalidación defectuosa. Separo los cuadros de mando por niveles: utilización de OPcache, latencias de Redis, tasa de aciertos de la caché de páginas, tasa de aciertos en el borde de la CDN y latencias regionales. Para los lanzamientos, defino los SLO (por ejemplo, TTFB del percentil 95 por debajo de X ms) y los rollbacks si las métricas se inclinan. Complemento las comprobaciones sintéticas con la supervisión de usuarios reales para cubrir dispositivos y redes reales.
Funcionamiento, costes y ampliación
También optimizo los TTL en Aspectos económicosLos TTL de CDN más largos aumentan la tasa de aciertos en el borde y reducen el tráfico de origen, pero reducen las ventanas de purga. Los TTL cortos aumentan la transferencia y la carga. Controlo las purgas finamente (por etiqueta/clave) en lugar de globalmente para evitar arranques en frío en los bordes. En las configuraciones multirregión, tengo en cuenta los tiempos de replicación para que una región no se quede obsoleta mientras la otra ya está fresca. Planifico la capacidad para las estampidas (autoescalado, ráfagas de RAM) y tengo preparadas rutas de emergencia que siguen funcionando con respuestas muy simplificadas incluso en caso de fallos parciales. Esto mantiene el sistema económico y robusto.
SEO y Core Web Vitals
Mejora del uso intensivo de la memoria caché TTFB y posteriormente LCP, lo que repercute positivamente en la satisfacción del usuario y en el presupuesto de rastreo. Es importante que la caché no entregue metadatos, canónicos o variantes de hreflang obsoletos. Desacoplamos la caché HTML de las partes más volátiles y priorizamos la actualización de las páginas críticas (página de inicio, categorías). Para el tráfico de bots, establezco TTL realistas y evito respuestas 304 innecesarias manteniendo el contenido fresco en lugar de revalidar cada petición. Esto mantiene el sitio rápido y consistente, tanto para humanos como para rastreadores.
Brevemente resumido
Organizo Almacenamiento en caché estratégico: acelerar primero el código, luego los datos, después las páginas y, por último, distribuir globalmente. Esta planificación mejora notablemente los tiempos de carga y ahorra costes de servidor. Mantengo los TTL, las purgas y las excepciones claramente documentadas para que los lanzamientos se realicen sin problemas. Métricas como la tasa de aciertos, el TTFB y la latencia de borde guían mis próximos pasos. Si se combinan estos niveles de forma coherente, se crea un sistema rápido, escalable y fiable. Sitios web.
