fpuenteonline

Buenos días Anibal, ese funcionamiento que describes es el que hacen muchos plugins de caché que utilizan disco (donde guardan los html estáticos e incluso en formato gzip) y un rewrite en el htaccess o fichero de configuración del servidor web.

En esas reglas puedes saltar aquellas url que no quieras cachear, por ejemplo las del back-end, o aquellas que vengan con cookies o parámetros GET/POST

Espero te ayude

Saludos

Buenas tardes Mau.

El problema no está en lo que ocupan las imágenes en disco, sino en la base de datos y en la vista «Mosaico».
Trato de explicarme. La diferencia entre la vista normal de la Librería y la vista Mosaico/Rejilla, es que está última está gestionada mediante peticiones AJAX, en concreto, peticiones a wp_ajax_query-attachments, que internamente son peticiones a la base de datos (ordenar por fecha descendente los attachments cada 40 elementos y paginarlos). Es decir, el tiempo de carga del admin-ajax.php (que podrás comprobar vía Chrome), seguramente sea el que esté tardando varios segundos en devolver la respuesta.
Mi primera recomendación entonces es sanear en todo lo posible la tabla que contiene los attachments.
Segunda recomendación es reducir la carga del admin-ajax.php eliminando todo lo posible el heartbeat (poco se va a notar esto)
Para seguir depurando el problema, puedes hacerte tu propio wp_ajax_query-attachments y poner trazas para confirmar que el cuello de botella es la query. Te pego el código para ponerlo en tu functions o plugin de funcionalidades.

add_action(‘wp_ajax_query-attachments’, ‘mauricio_wp_ajax_query_attachments’, 1);
function mauricio_wp_ajax_query_attachments() {
if ( ! current_user_can( ‘upload_files’ ) )
wp_send_json_error();

$query = isset( $_REQUEST[‘query’] ) ? (array) $_REQUEST[‘query’] : array();
$keys = array(
‘s’, ‘order’, ‘orderby’, ‘posts_per_page’, ‘paged’, ‘post_mime_type’,
‘post_parent’, ‘post__in’, ‘post__not_in’, ‘year’, ‘monthnum’
);
foreach ( get_taxonomies_for_attachments( ‘objects’ ) as $t ) {
if ( $t->query_var && isset( $query[ $t->query_var ] ) ) {
$keys[] = $t->query_var;
}
}

$query = array_intersect_key( $query, array_flip( $keys ) );
$query[‘post_type’] = ‘attachment’;
if ( MEDIA_TRASH
&& ! empty( $_REQUEST[‘query’][‘post_status’] )
&& ‘trash’ === $_REQUEST[‘query’][‘post_status’] ) {
$query[‘post_status’] = ‘trash’;
} else {
$query[‘post_status’] = ‘inherit’;
}

if ( current_user_can( get_post_type_object( ‘attachment’ )->cap->read_private_posts ) )
$query[‘post_status’] .= ‘,private’;

// Filter query clauses to include filenames.
if ( isset( $query[‘s’] ) ) {
add_filter( ‘posts_clauses’, ‘_filter_query_attachment_filenames’ );
}

/**
* Filters the arguments passed to WP_Query during an Ajax
* call for querying attachments.
*
* @since 3.7.0
*
* @see WP_Query::parse_query()
*
* @param array $query An array of query variables.
*/
$query = apply_filters( ‘ajax_query_attachments_args’, $query );
$query = new WP_Query( $query );

$posts = array_map( ‘wp_prepare_attachment_for_js’, $query->posts );
$posts = array_filter( $posts );

wp_send_json_success( $posts );
}

Si el cuello de botella, como supongo, es la WP_Query aunque sea insuficiente la limpieza en la base de datos, se puede establecer una estrategia de caché de esa consulta y guardarla por ejemplo en el transient (paginado), invalidando esa caché con un filtro cada vez que se añada un nuevo objeto a la librería. Esto mejoraría muchísimo a partir de la segunda consulta.

Espero que las indicaciones te sirvan.

Abrazo

Hola @sunrans77

El problema por el cual no se muestra el CSS, es que la web está migrada a HTTPS pero algunos recursos, como los CSS, se están intentando servir bajo HTTP.

Revisa que en el tema se estén llamando a todos los recursos con HTTPS y no HTTP. Tras eso, vacía el plugin de caché para que coja los cambios

Saludos