Ajax tarda 10 veces más de lo que debería/podría

9 feb 2012, 21:45:53
Vistas: 25.3K
Votos: 55

Me he encontrado con mi primer problema serio con WordPress y, como alguien que disfruta usando Ajax, esto es grave.

Tengo una petición Ajax que tarda 1.5 segundos en completarse mientras uso la API Ajax de WordPress.

Si tomo exactamente el mismo código y lo ejecuto con un script personalizado (sin WordPress), la petición Ajax tarda apenas 150 milisegundos. Esto no es una exageración

Si observas el primer comentario de http://wp.smashingmagazine.com/2011/10/18/how-to-use-ajax-in-wordpress/ y la conversación que le sigue, verás que esta lentitud es causada por el hecho de que en tu petición, todo WordPress se está cargando...

Espero que exista una solución que haga posible realizar peticiones Ajax sin tener que cargar todo WordPress.

¿Cuáles son tus experiencias para acelerar las peticiones Ajax en WordPress?

2
Comentarios

Me pregunto si los plugins de caché populares cubren esta situación.

Raphael Raphael
9 feb 2012 23:12:18

@Raphael, yo también pensé en eso, pero no he visto ninguna mención al respecto. Sería GENIAL si lo hacen

Mike Mike
9 feb 2012 23:25:56
Todas las respuestas a la pregunta 2
12
63

Sí, este es un problema molesto: para tener un entorno completo de WordPress necesitas invertir un tiempo considerable cargándolo.

Yo necesitaba un rendimiento mucho mejor (para una función de búsqueda incremental muy dinámica) en el trabajo y lo que hice fue:

  1. Archivo personalizado como manejador de Ajax.
  2. Constante SHORTINIT para una carga limitada del núcleo de WP.
  3. Carga muy selectiva de partes del núcleo, solo las necesarias para la tarea.

Esto proporciona un entorno muy limitado, pero el rendimiento es mucho, mucho mejor y se mantiene un grado razonable de compatibilidad con WP (comenzando con $wpdb).

Aquí está el inicio de mi archivo de carga, no es bonito pero funciona para necesidades específicas:

<?php

ini_set('html_errors', 0);
define('SHORTINIT', true);

require '../../../../wp-load.php';
require( ABSPATH . WPINC . '/formatting.php' );
require( ABSPATH . WPINC . '/meta.php' );
require( ABSPATH . WPINC . '/post.php' );
wp_plugin_directory_constants();

// aquí va el código
9 feb 2012 22:12:09
Comentarios

¿Qué quieres decir con la constante SHORTINIT? ¿Puedes proporcionar algunos ejemplos? Visualizo que necesitaré configurar mis propios manejadores con diferentes grados de WordPress cargado dependiendo de las necesidades de la solicitud, pero me gustaría ver algunos ejemplos que hayas creado.

Mike Mike
9 feb 2012 22:20:28

@Mike no es muy conocido pero es muy simple en concepto - si la constante SHORTINIT está definida, WordPress no cargará la mayor parte del núcleo (sin la mayoría de APIs/funciones, sin plugins, sin tema). Agregaré algo de código para responder.

Rarst Rarst
9 feb 2012 23:38:20

Eso parece bien. Simplemente no me gusta el hecho de que tengamos que usar require '../../../../wp-load.php'; eso lo hace bastante personalizado. También me preocupa lo fácil que es realmente incluir los recursos que "necesitas", porque según mi experiencia WordPress no es muy modular.

Mike Mike
10 feb 2012 19:47:00

@Mike correcto, pero incluso con problemas es mucho mejor que un endpoint que no tenga idea de WP en absoluto. Esto puede (y debería) mejorarse aún más, pero no es una tarea urgente para mí en este momento.

Rarst Rarst
10 feb 2012 21:32:19

¿Existen métodos para detectar la ubicación de wp-load.php desde dentro de WordPress? Por ejemplo, ¿podría escribir un archivo estático con la ruta establecida como una variable dentro de él al cargar el plugin, y luego incluir ese archivo en el archivo de respuesta Ajax independiente?

hereswhatidid hereswhatidid
20 dic 2012 20:26:41

@hereswhatidid sí, esa es una de las opciones, podrías usar get_included_files() de PHP por ejemplo. Sin embargo, ten en cuenta que escribir en el directorio del plugin no es una buena práctica, típicamente las escrituras en el sistema de archivos solo deberían ir al directorio de contenido. Este es el tipo de problema que no es tan difícil de configurar para ti mismo, pero es bastante difícil producir una solución que sea apropiada para código público.

Rarst Rarst
20 dic 2012 20:40:10

@Rarst, en lugar de require '../../../../wp-load.php'; creo que es mejor usar algo como: $dir = explode ( 'wp-content', dirname(__FILE__) ); y luego require $dir[0] . 'wp_load.php'? Creo que es más flexible y se puede usar en cualquier parte del tema o plugin

gmazzap gmazzap
23 jul 2013 14:43:39

@G.M. la carpeta de contenido puede ser reubicada libremente, es una suposición incorrecta que el código se ejecute desde dentro del directorio principal. Como se mencionó anteriormente, esto es difícil de manejar de manera genérica.

Rarst Rarst
23 jul 2013 15:34:27

@Rarst, sin duda la carpeta de contenido puede ser reubicada, pero si es así tu solución podría fallar también, ¿o me equivoco? Si en mi plugin (o tema) tengo un archivo options.php donde defino define('WPCONTENTROOTFOLDER', 'wp-content') y luego $dir = explode ( WPCONTENTROOTFOLDER, dirname(__FILE__) ) esto funcionará el 90% de las veces, para el resto escribo en la documentación de mi plugin qué cambiar si se mueve la carpeta de contenido. Por ejemplo, puedo implementar otra constante 'FULLWPCONTENTFOLDER', normalmente vacía pero si se establece el plugin usará esta en su lugar.

gmazzap gmazzap
23 jul 2013 18:02:57

@G.M. mi solución es específica para mi instalación, no está destinada a código distribuible. Tu código simplemente está codificando diferentes supuestos (más genéricos relativamente, estoy de acuerdo), pero personalmente no creo que alcance el nivel de código distribuible tampoco

Rarst Rarst
23 jul 2013 18:57:09

@Rarst (último comentario, lo juro) Sí, probablemente el mío no sea código distribuible (seguro que no en el repositorio de WP y/o para un público amplio), pero creo que es código reutilizable, aunque solo sea para mí: actualmente tengo más de 20 instalaciones de WP de clientes en línea y en todas ellas hay plugins desarrollados por mí, así que escribir código fácilmente reutilizable es vital para mí aunque no sea código distribuible.

gmazzap gmazzap
23 jul 2013 20:16:31

He estado usando una versión bifurcada (privada) de este plugin encontrada en GitHub: http://github.com/EkAndreas/ajaxflow/

Austin Passy Austin Passy
10 mar 2016 22:18:41
Mostrar los 7 comentarios restantes
0

Encontré esto y aceleró mis solicitudes AJAX.

function my_deregister_heartbeat() {
    global $pagenow;

    if ( 'post.php' != $pagenow && 'post-new.php' != $pagenow ) {
         wp_deregister_script('heartbeat');
         wp_register_script('heartbeat', false);
     }
}
add_action( 'admin_enqueue_scripts', 'my_deregister_heartbeat' );
13 jul 2014 16:20:31