DietPress

FAQ

¿Para qué sirve realmente la caché de páginas? ¿La necesito?

Cada vez que alguien visita tu sitio, WordPress consulta la base de datos, ejecuta tus plugins, genera la página a partir de tu tema y la envía. Para un visitante que no ha iniciado sesión el resultado es siempre el mismo hasta que cambies algo, por lo que repetir todo ese proceso supone un trabajo innecesario.

La caché de páginas realiza el proceso una sola vez y almacena el código HTML resultante en el disco. El siguiente visitante obtiene ese archivo, sin pasar por la base de datos, el tema ni la mayor parte del tiempo de carga. Suele ser la mayor mejora de velocidad que puede conseguir un sitio WordPress, y también es lo que permite que un plan de alojamiento pequeño se mantenga a flote cuando una entrada tiene éxito en las redes sociales.

Necesitarás una, a menos que tu proveedor de alojamiento ya te la proporcione. DietPress detecta los proveedores de alojamiento gestionado más habituales y te avisa cuando sea así.

¿Qué es el acelerador, debería activarlo?

Normalmente, la caché de páginas sirve la copia almacenada mediante PHP, tan pronto como WordPress ha cargado los plugins. Esto evita tener que recurrir a la base de datos y al tema, pero no al inicio de WordPress en sí, y en un sitio con muchos plugins, ese inicio es lo que más recursos consume una página almacenada en caché.

El acelerador también elimina ese inicio. En Apache, DietPress escribe un bloque de reglas en tu archivo .htaccess, marcado como “Page Cache by DietPress”, y el servidor sirve la copia almacenada por sí mismo, sin iniciar PHP ni WordPress en absoluto. Esa es la forma más rápida de servir una página. En nginx, que no lee el archivo .htaccess, la pestaña “Cache” te proporciona las mismas reglas para que las pegues en la configuración de tu servidor.

El servidor también sirve las páginas a los teléfonos. Con la caché móvil independiente activada, cada dirección tiene una copia optimizada para teléfonos y otra para computador, y las reglas seleccionan la adecuada mediante la misma prueba que utiliza WordPress, por lo que lo que PageSpeed mide en dispositivos móviles es la copia servida. Esas páginas se envían con una cabecera “Vary”, de modo que una CDN o un proxy situado delante mantiene separadas las dos versiones.

Actívalo cuando la caché de páginas esté funcionando, si tu sitio funciona con Apache (con mod_rewrite y mod_headers, que casi todos los servidores de alojamiento tienen) o con nginx, que es donde se ha realizado la medición. LiteSpeed lee las mismas reglas que Apache, y ahí es donde la prueba determina si funcionan. Se comprueba en tu página de inicio en el momento en que lo activas: si el servidor no sirve esa página por sí mismo, con sus encabezados y con el esquema correcto, las reglas se desactivan de nuevo y la pestaña indica el motivo. Todo lo que las reglas no modifican (un visitante que ha iniciado sesión, una URL con una cadena de consulta, una recarga forzada) sigue siendo servido o reconstruido por PHP, exactamente igual que sin esta función.

Las páginas almacenadas siguen caducando a tiempo, incluso en un sitio con una caché tan bien gestionada que WordPress apenas ejecuta sus tareas programadas: cada copia está vinculada con el nombre de cada hora en la que sigue siendo válida, y el servidor solo busca la actual. La única excepción es la noche en que se atrasa el reloj del servidor, momento en el que una copia puede seguir sirviéndose hasta una hora más. Esos nombres adicionales son también la razón por la que una copia de seguridad que incluya wp-content/cache puede crecer: excluye esa carpeta, como ya hacen la mayoría de los plugins de copias de seguridad, ya que una copia de seguridad que no conserve enlaces duros almacena cada nombre como un archivo.

¿El acelerador ignora mi plugin de seguridad?

En parte, y conviene saber cómo. El servidor responde antes de que se ejecute cualquier código PHP, por lo que cualquier acción que realice un plugin de seguridad en PHP no detecta esas visitas: ya sea el bloqueo de una dirección IP, la limitación de velocidad, un filtro de bots o una comprobación de ataque. Las reglas que un plugin de seguridad escribe en tu archivo .htaccess, o en la configuración del servidor, siguen aplicándose: un bot que esas reglas bloquean sigue recibiendo su error 403 en una página que sirve el servidor, mientras que un cliente que solo está bloqueado en PHP obtiene la página almacenada en caché. Lo mismo ocurre con un sitio cerrado a nivel de servidor, por dirección IP o con contraseña: en Apache, solo se puede acceder a las copias almacenadas a través de la dirección de su página, que esas reglas protegen. En nginx, consulta la siguiente pregunta. Las páginas nunca se sirven de esta forma a un visitante que haya iniciado sesión o que tenga un carrito.

Si tu sitio funciona con la parte de PHP de un plugin de seguridad para visitantes anónimos, desactiva el acelerador. Ten en cuenta que, incluso sin él, la caché de la página responde muy rápido, antes de que muchos plugins de seguridad ejecuten sus comprobaciones.

¿Cómo puedo usar el acelerador en nginx?

nginx no lee los archivos .htaccess, por lo que DietPress no puede escribir las reglas por ti. Con el caché de páginas activado, la pestaña “Caché” las muestra en cuatro partes, cada una con un comentario que indica dónde deben colocarse en la configuración de tu sitio web: dos dentro del bloque “server”, una al principio de la sección “location” que gestiona tus páginas y otra en la sección “location” que pasa los archivos PHP a PHP-FPM. Pégalas, comprueba la configuración con nginx -t, recarga nginx y, a continuación, activa el acelerador, que las prueba en tu página de inicio antes de permanecer activo. Las reglas también cierran la carpeta de caché, a la que, de otro modo, nginx permitiría el acceso a cualquiera a través de su dirección. Una cosa que debes comprobar antes de pegarlas: las reglas de acceso dentro de tu bloque “location” (allow, deny, auth_basic o auth_request) no se aplican a las páginas servidas desde la caché, ya que nginx reenvía la solicitud antes de examinarlas. Muévelas al bloque “server” o repítelas dentro de la “location” de la parte 2, tal y como indica su comentario.

Si más adelante modificas una exclusión, las cookies que impiden el acceso a los visitantes, la caché móvil independiente o el tiempo que los navegadores conservan las páginas, la pestaña indicará que las reglas han cambiado: vuelve a pegarlas y actualiza nginx. En un alojamiento gestionado en el que no puedas editar la configuración de nginx, desactiva el acelerador y la caché de páginas seguirá funcionando mediante PHP.

¿Cómo compruebo que esté funcionando el acelerador?

Abre una página en una ventana privada y comprueba las cabeceras de respuesta en las herramientas de desarrollo de tu navegador: “X-DietPress-Cache: HIT-STATIC” significa que el servidor la ha servido sin PHP, HIT significa que PHP la ha servido desde la caché y MISS significa que se ha generado. La primera visita a una página tras un cambio siempre es un MISS. La opción “Probar la caché ahora” de la pestaña “Caché” realiza la misma comprobación por ti en la página de inicio. Desactiva el acelerador si el servidor falla al servir esa página (con un error, con una copia a la que le faltan las cabeceras o con algo que no sea la página almacenada por DietPress), mientras que WordPress sigue generándola correctamente. Cuando el acelerador está activado pero no puede ejecutarse, la prueba indica el motivo y, si el servidor sigue respondiendo por sí mismo desde la caché, elimina los nombres bajo los que el servidor encuentra las páginas almacenadas.

¿Cómo se han medido los datos de velocidad que aparecen en la descripción? ¿Puedo repetirlos?

En una instalación local de WordPress 7.1 con Astra, WooCommerce y 29 plugins activos, con PHP 8.5 y Apache. Cada URL se solicitó dos veces para el “calentamiento” y, a continuación, quince veces seguidas al servidor web, y se calculó la mediana. Las visitas por segundo se obtuvieron a partir de 300 solicitudes, con diez en curso a la vez, tras indicar al plugin de seguridad del sitio que no las limitara. Lo único que varió entre las tres columnas fueron los ajustes de caché de página y del acelerador, con el mismo contenido y en la misma sesión.

Puedes repetirlo en tu propio sitio con cualquier herramienta que registre el tiempo hasta el primer byte. Desde un terminal, curl -o /dev/null -w "%{time_starttransfer}\n" https://tudominio.com/ una docena de veces con la caché desactivada y, a continuación, otra docena con ella activada, y compara las medianas en lugar de un único valor. Hazlo sin haber iniciado sesión, ya que tus propias visitas nunca se almacenan en caché.

Dos advertencias necesarias. Una instalación local no tiene latencia de red, por lo que los milisegundos absolutos son inferiores a los que se observarán en producción, donde el ahorro suele ser mayor, no menor. Además, estas cifras no dicen nada sobre la puntuación de Lighthouse: esta mide principalmente lo que hace el navegador con tu tema y tus scripts una vez que la página se cargó, lo cual es un problema distinto de la rapidez con la que responde tu servidor.

¿Qué es el CSS crítico y por qué es importante?

Un navegador no mostrará nada hasta que haya descargado todas las hojas de estilo de la página. Esos archivos bloquean la visualización: el visitante se queda mirando una pantalla en blanco mientras se descargan.

El CSS crítico es el pequeño subconjunto de reglas necesarias para mostrar en pantalla lo que se ve a primera vista. DietPress lo incluye directamente en la página, de modo que el navegador pueda mostrarlo de inmediato y cargar el resto de los estilos posteriormente. Es la solución habitual para la advertencia “eliminar recursos que bloquean la visualización” de PageSpeed Insights, y mejora el Largest Contentful Paint, uno de los Core Web Vitals que mide Google.

¿Para qué sirve aplazar la ejecución de JavaScript?

Por defecto, una etiqueta de script detiene el navegador: descarga el archivo, lo ejecuta y solo entonces continúa leyendo la página. Un tema con media docena de scripts en la sección “head” puede retrasar la primera visualización durante un segundo o más.

Los aplazamientos indican al navegador que siga cargando la página y que ejecute los scripts una vez que haya terminado. No se elimina nada ni se carga nada más tarde de lo previsto, simplemente deja de bloquear la carga. DietPress gestiona el orden de las dependencias por ti y te permite excluir cualquier script que no funcione correctamente, ya sea desde los ajustes o mediante un filtro.

¿Por qué debería alojar Google Fonts en mi propio servidor?

Hay dos razones. Velocidad: una fuente de fonts.gstatic.com requiere una nueva consulta de DNS, una conexión TCP y un protocolo de enlace TLS con un dominio con el que el navegador nunca se ha conectado, y la segmentación de la caché del navegador implica que el visitante no se beneficia de haber descargado esa fuente en otro sitio. Privacidad: al servirlas desde Google, se transfiere la dirección IP de tu visitante a Google, lo que los tribunales alemanes y otros tribunales europeos han dictaminado que constituye una infracción del RGPD.

DietPress descarga las fuentes que utiliza tu tema a tu propia carpeta de archivos subidos y modifica las hojas de estilo para que apunten a esa ubicación. Si algo falla vuelve a recurrir a Google de forma discreta, por lo que nunca falta ninguna fuente.

¿Qué es la carga selectiva?

Los plugins suelen cargar sus archivos CSS y JavaScript en todas las páginas de tu sitio, independientemente de si la página los utiliza o no. Un plugin de formularios de contacto carga sus scripts en cada entrada del blog; un plugin de carruseles carga sus bibliotecas en páginas que no tienen carrusel, y WooCommerce carga su carrito en tu página “Acerca de”.

DietPress detecta qué páginas utilizan realmente cada uno de ellos y elimina el resto, en el caso de WooCommerce, Contact Form 7, la biblioteca de bloques, Slider Revolution, TablePress, Smash Balloon, Formidable Forms y Everest Forms. Las páginas creadas con un maquetador como Elementor conservan todo, ya que su contenido no se puede leer desde la base de datos y, al tener que adivinar cuál es, es ahí donde surgen los problemas.

¿Qué es la caché de navegador y en qué se diferencia de la caché de páginas?

Almacenan en caché elementos distintos según el usuario. La caché de páginas almacena el código HTML en el servidor, para que al siguiente visitante se le muestre sin necesidad de volver a generar la página. La caché de navegador indica al navegador de cada visitante que guarde las imágenes, los estilos, los scripts y las fuentes en su propio equipo, para que en su segunda visita apenas tenga que descargar nada.

Necesitas ambas cosas, y no se solapan. DietPress te permite configurar el tiempo que se conservan cada uno de los tipos de archivos: medios, estilos y scripts, y fuentes, cada uno por separado, ya que la respuesta adecuada varía en cada caso.

¿Para qué sirve la opción “Dejar que los navegadores mantengan el HTML” y por qué el valor por defecto es cero?

Determina durante cuánto tiempo el navegador de un visitante puede reutilizar la propia página, a diferencia de sus imágenes y estilos. El valor cero, “Revalidar siempre”, no equivale a no enviar nada en absoluto.

Si no recibe respuesta alguna, el navegador asigna una duración propia, que suele ser aproximadamente una décima parte de la vida útil del documento. En el caso de una página antigua, esto puede suponer horas, y es algo que escapa totalmente a tu control. Con la opción “Revalidar siempre”, el navegador realiza la consulta cada vez, y la respuesta habitual es un “304 Not Modified” de unos pocos cientos de bytes, por lo que la página tampoco se vuelve a descargar: consigues casi todo el ahorro y nada de la información obsoleta.

Actívalo solo para un sitio que realmente casi nunca cambie, y ten en cuenta la contrapartida: una modificación tardará ese tiempo en llegar a cualquiera que ya haya visitado la página, ya que su navegador ni siquiera lo solicitará. Esto se envía como cabecera HTTP en lugar de como regla .htaccess, por lo que también funciona en nginx, y las páginas servidas desde la caché también lo respetan, tanto si las sirve PHP como el servidor. Por encima de cero también le indica a una CDN o a un proxy situado delante del sitio que puede conservar la página, algo a lo que no llega una purga en DietPress.

¿Qué diferencia hay entre ligera, moderada y estricta?

Por riesgo, no por importancia. La opción “Ligera” es segura en cualquier sitio: incluye cosas que nadie echa de menos, como el script de emojis o la etiqueta de Windows Live Writer. La opción “Moderada” merece que le eches un vistazo primero, ya que algún plugin o tema podría utilizarla, como oEmbed o jQuery Migrate, por ejemplo. La opción “Estricta” depende de lo que haga realmente tu sitio: desactivar los comentarios, las fuentes RSS o todo un tipo de contenido solo tiene sentido si realmente no los utilizas.

Cada opción explica qué hace y qué problemas podría causar, y la pestaña “Pesa” analiza tu sitio y solo te recomienda lo que te conviene, para que nunca tengas que adivinar nada.

¿Qué son las Core Web Vitals? ¿Esto ayuda a mejorarlas?

Son los tres parámetros que utiliza Google para evaluar la experiencia de usuario de una página: la rapidez con la que aparece el contenido principal (LCP), la rapidez con la que la página responde a un clic (INP) y el grado de desplazamiento de los elementos durante la carga (CLS).

DietPress hace las tres cosas. La caché de páginas y la precarga reducen el tiempo hasta el primer byte y hasta el elemento más grande, aplazar la ejecución de JavaScript y recortar lo que se carga deja libre el hilo principal para responder a los clics, y agregar el ancho y la altura a las imágenes que carecen de ellos evita que el diseño se desplace a medida que se cargan.

¿Es cero configuración?

Sí, si es lo que quieres. Las optimizaciones de rendimiento están por defecto, así que solo tienes que activarlas y listo. La diferencia es que ahora puedes afinar todo y, si lo deseas, poner WordPress a dieta desactivando las características que no utilices.

¿Romperá mi sitio?

Las optimizaciones de rendimiento están diseñadas para que sean seguras y se han probado en muchos sitios. Las opciones de dieta solo aplican cambios cuando activas explícitamente cada selector, y cada opción incluye una descripción de a lo que podría afectar. Si algo falla desactiva el selector. Al desactivar el plugin se restablece el comportamiento por defecto de WordPress.

¿Cómo funciona el alojamiento local de las fuentes de Google?

Al activarlo (pestaña “Ligera”, sección “Rendimiento”), DietPress detecta las hojas de estilo de Google Fonts que tu tema pone en cola, descarga la hoja de estilo y sus archivos de fuentes una sola vez, los almacena en tu carpeta de archivos subidos y los sirve desde tu propio servidor. Los visitantes ya no se conectan a Google (las fuentes se cargan más rápido y se cumple con el RGPD, ya que no se envían datos de los visitantes a terceros). Si falla alguna descarga las fuentes siguen cargándose desde la CDN de Google. Las copias locales se actualizan al cambiar de tema y se eliminan al desactivar la opción o el plugin. Las fuentes incluidas en el código de un tema fuera del sistema estándar de WordPress no se ven afectadas.

La carga selectiva ha eliminado algo que mi sitio necesita

Cada módulo de carga selectiva solo elimina los recursos cuando no se detecta su contenido de destino, pero existen configuraciones poco habituales: un minicarrito en la cabecera programado manualmente, un formulario insertado mediante AJAX, un carrusel generado por el tema o un tema clásico que reutiliza los estilos de los bloques en todas partes. Desactiva el conmutador correspondiente o utiliza los filtros de exclusión (dietpress_selective_{module}_has_content, dietpress_selective_page_hides_content, dietpress_selective_wc_keep_cart_fragments, dietpress_selective_cf7_has_form, dietpress_selective_blocks_dequeue) para conservar exactamente lo que tu sitio necesita.

Las páginas creadas con Elementor, así como cualquier solicitud a la que se aplique una plantilla del maquetador de temas de Elementor, se dejan al margen a propósito: su contenido se almacena en la base de datos, fuera del alcance del análisis de contenido.

¿Los módulos TablePress y Smash Balloon quitan algo de la cola?

No. Ambos plugins ya cuentan con su propio modo de carga condicional, desactivado por defecto en los casos que cubren, y esos dos módulos simplemente lo activan para los visitantes. El propio plugin carga entonces su hoja de estilos cuando se muestra una tabla o un feed, por lo que nada puede quedarse sin aplicar estilos. El módulo de Formidable Forms retira el plugin de la cola, pero vuelve a activar el pie de página de reserva del propio plugin por la misma razón.

¿Qué hace exactamente el módulo de Slider Revolution?

Desactiva la opción “Incluir bibliotecas globalmente” de Slider Revolution en cada visita, sin guardar nada y sin modificar tu configuración. A partir de ahí, Slider Revolution decide por sí mismo, exactamente como si hubieras desactivado esa opción en su configuración global: carga sus bibliotecas en modo de vista previa, cuando hay uno de sus shortcodes en el contenido, cuando su widget está activo y en cualquier página que hayas incluido en su propia “Lista de páginas en las que incluir las bibliotecas de RevSlider” . DietPress solo agrega los casos que su comprobación pasa por alto, como un shortcode dentro de un widget de texto o una página de archivo. Si ya has desactivado tú mismo esa opción, el módulo no hace absolutamente nada y tu lista de páginas sigue siendo la que manda.

Hay algo que debes saber: con la carga global desactivada, la función PHP add_revslider() que algunos temas utilizan para mostrar un carrusel desde una plantilla no se carga y, en su lugar, muestra un aviso. Así es como se comporta Slider Revolution por sí solo, y la solución es la que indica en su documentación: agregar esas páginas a su lista.

¿Por qué una de las opciones aparece atenuada o me dice que no hace nada?

Porque, de momento, no puede hacer lo que dice, y es mejor avisarte de ello que dejarte activar una característica que no funciona. Pueden pasar dos cosas. Una opción no está disponible cuando entraría en conflicto con otra o interferiría con otro plugin: “Desactivar el mapa del sitio XML de WordPress” cuando un plugin genera su propio mapa del sitio además del nativo, o “Desactivar la carga diferida nativa” y “Desactivar el atributo fetchpriority” cuando “Mejorar los atributos de carga de imágenes” está activado y ya establece esos atributos por su cuenta. Y una opción simplemente indica que no tiene ningún efecto cuando otra opción ya lo cubre: los controles de las fuentes RSS granulares mientras “Desactivar TODAS las fuentes RSS” está activado, o las subopciones de .htaccess mientras el interruptor principal está desactivado. Esas opciones siguen siendo utilizables, por lo que puedes configurarlas antes de activar el interruptor principal.

Todo lo que hayas guardado se conserva. Una opción que no se pueda aplicar no se desactiva sin tu conocimiento: permanece guardada y vuelve a activarse en cuanto cambie lo que la bloquea.

¿Es compatible con plugins de caché y CDNs?

Sí. DietPress funciona junto con otros plugins de caché e incluye las cabeceras CORS y Vary para garantizar una compatibilidad total con las CDN. Cuando se utiliza una CDN o un proxy, la caché de la página necesita que WordPress sepa cuándo llega una visita a través de HTTPS, al igual que el resto de WordPress: cuando las cabeceras del proxy no coinciden con el HTTPS que detecta WordPress, esas visitas quedan excluidas de la caché, y la pestaña “Caché” explica por qué y cómo solucionarlo.

Algo fue mal tras la activación

Si un plugin o un tema no encola los scripts correctamente, la opción “defer” de JavaScript podría afectar a su funcionamiento. Puedes desactivar esa opción o utilizar el filtro dietpress_skip_defer_script_handles. Si aparece un error 500 edita tu archivo .htaccess y elimina los bloques que comienzan por # BEGIN Page Cache by DietPress y # BEGIN DietPress (o # BEGIN Zero Config Performance si has actualizado desde la versión 2.x y las reglas aún no se han reescrito), o desactiva la opción “Reglas del servidor .htaccess” y el acelerador de caché de página.

¿Por qué hay páginas que no se almacenan en caché?

Abre DietPress y ve a la pestaña “Caché”. Escribe o selecciona una página en el campo de la sección de vaciado, o déjalo vacío para la página de inicio, y pulsa “Probar la caché ahora”: el sitio solicita esa página como lo haría un visitante anónimo y te indica si el servidor la ha servido, si PHP la ha servido desde el disco, si se ha reconstruido, si se ha omitido (con el motivo exacto) o si una caché situada delante del sitio ha respondido antes que WordPress. También puedes activar WP_DEBUG y leer la última línea del código fuente HTML de una página: DietPress escribe allí el motivo, por ejemplo, que la respuesta estableció una cookie o que un plugin declaró la página no almacenable en caché. Una página que se ha almacenado no recibe ningún comentario. Y si compruebas el encabezado X-DietPress-Cache en las herramientas de desarrollador de tu navegador, desmarca primero la opción “Desactivar caché”: si está marcada, al igual que con una recarga forzada, el navegador solicita una copia nueva y DietPress reconstruye la página a propósito, por lo que muestra “MISS”. Una recarga normal se sirve desde la caché.

Las tres causas habituales son: un plugin que almacena una cookie en cada visita (un banner de consentimiento, algunos scripts de análisis), una página que es verdaderamente personal (carrito, proceso de pago, “Mi cuenta”, una entrada protegida con contraseña) y un directorio de caché en el que el servidor no puede escribir. El panel de estado informa de la tercera causa por sí mismo. En un sitio web detrás de un proxy o una CDN existe una cuarta causa: las cabeceras del proxy que no coinciden con el HTTPS que detecta WordPress impiden que esas visitas se almacenen en la caché. Esas visitas se excluyen antes de que se genere la página, por lo que no aparecen en el código fuente HTML, salvo cuando WordPress detecta el HTTPS más adelante en la solicitud, en cuyo caso el comentario indica que el HTTPS cambió tras la consulta a la caché. En cualquier caso, la pestaña “Caché” te informa de ellas y te indica cómo solucionarlo.

He publicado un cambio y los visitantes siguen viendo la página antigua

Al publicar, editar, eliminar o cambiar el nombre de una entrada, se vacía con todo lo que la incluye, y al aprobar un comentario se vacía la caché de la entrada a la que pertenece. Al cambiar el tema, los menús, los widgets, los enlaces permanentes o los ajustes de la página de inicio se vacía toda la caché, al igual que al activar o actualizar cualquier plugin.

Si un cambio realizado fuera de WordPress (directamente en la base de datos o mediante un importador) no se muestra, utiliza el botón de vaciar de la pantalla “Caché de páginas”. Además, compruébalo primero en una ventana privada: DietPress solicita a los navegadores que no almacenen el HTML, pero una caché de navegador muy activa, una CDN o una caché de alojamiento delante del sitio quedan fuera de su control.

¿Funciona con WooCommerce?

Sí. WooCommerce marca el carrito, la página de pago y “Mi cuenta” como no almacenables en caché, y DietPress respeta esa marca en lugar de deducirlo a partir de la URL, por lo que sigue funcionando si se mueven o se renombran esas páginas. Además, a cualquier visitante que tenga un carrito de WooCommerce o una cookie de sesión se le muestra el sitio web en tiempo real en todo momento, por lo que el minicarrito de la cabecera nunca muestra el carrito de otra persona. Una tienda en modo “Próximamente” no se almacena en caché en absoluto.

¿Puedo usarlo junto a mi otro plugin de caché o con la caché de mi alojamiento?

Con otro plugin de caché de páginas no, y DietPress tampoco te lo permite: dos cachés de páginas en el mismo sitio sirven el HTML obsoleto del otro, y el resultado es muy difícil de diagnosticar. Si está activo W3 Total Cache, WP Super Cache, LiteSpeed Cache, WP Fastest Cache, Cache Enabler, Surge, WP Rocket o cualquiera de los aproximadamente treinta plugins similares, la opción permanece desactivada e indica cuál de ellos es. Los plugins de caché de objetos, como Redis Object Cache, son algo diferente y no suponen ningún problema.

Con una caché de alojamiento web (Kinsta, WP Engine, SpinupWP, Cloudways y otros) es posible pero no suele ser una buena idea, ya que al vaciar una no se vacía la otra. DietPress detecta las más habituales y, mientras su caché de página está activada, te pide que marques una casilla de confirmación en la ficha de caché de página antes de activar la suya propia. Con la caché de página de DietPress activada, las páginas que almacena indican a las cachés anteriores que no las guarden, de modo que cada página se almacena en caché en un solo lugar. Si la prueba de la pestaña “Caché” indica que ha respondido una caché anterior al sitio, vacía esa caché una vez. En los servidores LiteSpeed el plugin LiteSpeed Cache es la otra opción natural, ya que almacena en caché a nivel de servidor, así que utiliza uno de los dos. El acelerador de DietPress lee allí las mismas reglas que en Apache, y su prueba indica si LiteSpeed sirve las páginas almacenadas sin PHP.

¿Se sirve caché a los usuarios conectados?

Nunca, y no hay forma de cambiarlo. Lo mismo ocurre con cualquier persona con un carrito, una publicación desbloqueada protegida con contraseña o un comentario pendiente de moderación.

¿Puedo personalizar las optimizaciones si soy desarrollador?

Sí. Consulta los filtros que aparecen en la descripción (los hooks dietpress_*). El caché de páginas agrega dietpress_cache_bypass, dietpress_cache_bypass_request, dietpress_cache_bypass_accept, dietpress_cache_bypass_cookies, dietpress_cache_ignored_params, dietpress_cache_exclude_urls y dietpress_cache_post_urls, la acción dietpress_cache_purge_all y la función dietpress_purge_page_cache( $url ). Al definir DIETPRESS_DISABLE_CACHE como “true”, se desactiva el motor sin desactivar nada. Con el acelerador activado, sus reglas y los nombres de las páginas almacenadas se eliminan la próxima vez que un administrador abra el escritorio.

Con el acelerador activado, las cookies, los tipos de medios y los patrones de URL que devuelven esos filtros se escriben en las reglas del servidor, por lo que un valor agregado solo en algunas solicitudes, o solo en la parte visible de la web, no llega a ellas. Una llamada de retorno a dietpress_cache_bypass_request, o a wp_is_mobile con la caché móvil independiente activada, impide que el acelerador se ejecute, ya que el servidor no puede ejecutar ese código.