Category: Programmation

JQuery a changé la vie de pas mal de développeurs web...
JQuery a changé la vie de pas mal de développeurs web...

Optimiser WordPress en utilisant JSDelivr & Google Library pour Jquery !

Hello à tous !

Petite découverte du jour : Une des raisons de la lenteur de chargement des WordPress, c’est l’utilisation abusive de Javascript… Et je suis pleinement dans ce cas ! Mais sachez que si vous utilisez des ressources de CDN officiels, il y a de fortes chances que votre internaute ait déjà chargé ces librairies dans son navigateur… Et cela vous économisera quelques millisecondes de chargement !

Pour cela, il existait un plugin (Use Google Libraries), mais celui ci ne fonctionne plus avec les nouvelles versions de WordPress. En plus il n’est plus mis à jour… Moi je vous propose une solution simple : Utiliser le fichier function.php de votre thème et… Roulez jeunesse ! Ajoutez-y ces instructions :

////////////////////////////////////////////////////////////////////////
// On utilise les cdn Google et JSdelivr 🙂 ////////////////////////////
////////////////////////////////////////////////////////////////////////
function register_jquery() {
if (!is_admin()) {
wp_deregister_script(‘jquery-core’);
wp_register_script(‘jquery-core’, ‘https://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js’, true, ‘2.2.0’);
wp_enqueue_script(‘jquery-core’);
wp_deregister_script(‘jquery-migrate’);
wp_register_script(‘jquery-migrate’, ‘https://cdn.jsdelivr.net/jquery.migrate/1.2.1/jquery-migrate.min.js’, true, ‘1.2.1’);
wp_enqueue_script(‘jquery-migrate’);
wp_deregister_script(‘jquery-ui’);
wp_register_script(‘jquery-ui’, ‘https://ajax.googleapis.com/ajax/libs/jqueryui/1.11.4/jquery-ui.min.js’, true, ‘1.11.4’);
wp_enqueue_script(‘jquery-ui’);
}
}
add_action( ‘wp_enqueue_scripts’, ‘register_jquery’ );

Et voilà ! Les principales ressources javascript de votre wordpress seront gérées depuis des CDN 😉 ! Elle est pas belle la vie ? Notez également que wordpress vous propose un CDN image gratuit, photon, livré avec le plugin Jetpack, que je ne peux que vous conseiller d’activer pour encore soulager votre serveur !

Ah oui, petit détail : ma version de jQuery, la 2.2.0, cassera la compatibilité avec les navigateurs Internet Explorer plus vieux que IE9… Mais c’est un choix qui m’est personnel, puisque j’améliore l’expérience sur mobile, tablette et ordinateurs modernes en contrepartie 😉 !

Google Chrome et l'erreur net::ERR_INCOMPLETE_CHUNKED_ENCODING
Google Chrome et l'erreur net::ERR_INCOMPLETE_CHUNKED_ENCODING

Bug net::ERR_INCOMPLETE_CHUNKED_ENCODING entre Google Chrome et admin-ajax.php (WordPress)

Voilà, depuis la nouvelle version du site, les utilisateurs sous Google Chrome ont beaucoup de mal à poster des commentaires. En réalité, cela fonctionne, le commentaire est bien publié, mais l’AJAX n’ayant pas un retour positif, il donne l’impression à l’utilisateur que le message n’a pas été envoyé – alors qu’il l’a été.

C’est dommage car Google Chrome représente plus de 50% des visiteurs : C’est donc un bug majeur.

Quel est la cause du problème

Ayant fait un peu le tour du web, je comprends que c’est lié au « chunked » et à un « Content-Length » incorrect. Google Chrome vérifie que les données concorde et si ce n’est pas le cas… Il s’arrête. Le soucis, c’est que mes données sont envoyées en GZip (compressée) donc forcément, impossible pour le serveur de savoir combien fera le fichier AVANT de le Gzipper (puisque le fichier contenant ce fameux Content-Length est DANS ce fichier Gzip).

Que faire ?

Personnellement, je me dis que désactiver Gzip et Deflate devraient résoudre le problème, mais je n’ai pas encore réussi à le faire (il faut dire que le fichier de configuration est vraiment complexe).  D’ailleurs, on peut voir dans le code source de Chromium la façon dont Chrome renvoi cette erreur :

int HttpStreamParser::DoReadBodyComplete(int result) {
// When the connection is closed, there are numerous ways to interpret it.
//
// – If a Content-Length header is present and the body contains exactly that
// number of bytes at connection close, the response is successful.
//
// – If a Content-Length header is present and the body contains fewer bytes
// than promised by the header at connection close, it may indicate that
// the connection was closed prematurely, or it may indicate that the
// server sent an invalid Content-Length header. Unfortunately, the invalid
// Content-Length header case does occur in practice and other browsers are
// tolerant of it. We choose to treat it as an error for now, but the
// download system treats it as a non-error, and URLRequestHttpJob also
// treats it as OK if the Content-Length is the post-decoded body content
// length.
//
// – If chunked encoding is used and the terminating chunk has been processed
// when the connection is closed, the response is successful.
//
// – If chunked encoding is used and the terminating chunk has not been
// processed when the connection is closed, it may indicate that the
// connection was closed prematurely or it may indicate that the server
// sent an invalid chunked encoding. We choose to treat it as
// an invalid chunked encoding.
//
// – If a Content-Length is not present and chunked encoding is not used,
// connection close is the only way to signal that the response is
// complete. Unfortunately, this also means that there is no way to detect
// early close of a connection. No error is returned.
if (result == 0 && !IsResponseBodyComplete() && CanFindEndOfResponse()) {
if (chunked_decoder_.get())
result = ERR_INCOMPLETE_CHUNKED_ENCODING;
else
result = ERR_CONTENT_LENGTH_MISMATCH;
}

Il y a également quelques erreurs Varnish 503, qui ne sont pas lié au bug ci-dessus, mais elles me semblent être liées à un des modules PHP chargé sur le serveur qui serait défectueux… Le soucis étant de trouver lequel, car l’erreur dit simplement :

zend_mm_heap corrupted

Et c’est tout… Aucune indication, si ce n’est que ZEND est forcément lié à PHP 🙂 !

Voilà, c’était tout pour ce petit carnet de développeur !