This performant front-end archicture article it’s an excellent high-level technical overview of the entire process for showing a web page, from downloading resources to rendering and prefetching.
Tag: performance
Control HTTP 301 redirects caching
HTTP redirects should be your tool of choice when you’re reorganizing or renaming key sections of your site on order to keep visitors from hitting a not found page and make search engines update their location and keep their ranking.
However, sometimes you might run into a situation when you need to update a redirect, only to find out that the redirection it’s aggressively cached by your browser (specially Chrome).
So, how can you avoid (or at least, control) the way that redirects are cached?
Use get_the_terms() instead of wp_get_object_terms()
I was recently debugging the front page of a WordPress site and found a lot of queries to the terms and term relationships database tables.
Digging a little deeper, I found that the culprit were a set of functions that were calling wp_get_object_terms() to get the terms from a set of looped posts… and then I thought… “wait a minute, doesn’t WordPress should be using the object cache for this?”
Well, it turns out that wp_get_object_terms() always queries the database.
If you’re looping over WP_Query results, you should prefer get_the_terms() instead. It’s pretty much the same for most use cases, but it uses the object cache, which by default gets populated with the terms for the posts matching your query — unless you specifically set update_post_term_cache as false when instantiating WP_Query.
The are several differences, though: wp_get_object_terms() can take arrays as the first and second argument, while get_the_terms() can only take the post ID (or object) as first argument (so you can’t get the terms for a bunch of posts on one function call) and a string for taxonomy (so you can’t get the terms for several taxonomies); and you can use a third argument on the former, which the latter doesn’t have.
You could still emulate some of this, and still benefit from using the object cache; for instance, let’s see how you would get the names of the my_custom_tax terms for the current post, ordered by use on a descending way.
// using wp_get_object_terms()
$popular_terms = wp_get_object_terms( $post->ID, 'my_custom_tax', array(
'orderby' => 'count',
'order' => 'DESC',
'fields' => 'names'
) );
// using get_the_terms()
$popular_terms = get_the_terms( $post->ID, 'my_custom_tax' );
// $popular_terms will be ordered alphabetically, so let's order by count
$popular_terms = usort( $popular_terms, function( $a, $b ){
if ( $a->count < $b->count ) {
return 1;
}
if ( $a->count > $b->count ) {
return -1;
}
return 0;
} );
// we only need slugs, so...
$popular_terms = wp_list_pluck( $popular_terms, 'name' );
Even if it’s somewhat troublesome, it’s probably worth the effort if you’re trying to maximize for performance.
Optimización AJAX 4: Caché permanente
En la parte final (por ahora) de esta serie sobre Optimización de respuestas AJAX vamos a revisar cómo utilizar técnicas de caché permanente, o lo que se debería denominar más correctamente caché-que-se-controla-desde-el-servidor — lo que complementa a la parte anterior sobre “caché volátil” o caché-que-se-controla-desde-el-cliente.
Architecting Websites for the HTTP/2 Era
As I’ve written before, HTTP/2 will force us to change many assumptions and re-define good practices.
Mattias Genar is trying to keep an up-to-date summary of the most important questions, changes and benchmarks on Architecting Websites For The HTTP/2 Era.
Optimización AJAX 3: caché volátil
Poder guardar respuestas en caché nos puede evitar tener que realizar nuevas peticiones a consultas para las cuales ya hemos obtenido los resultados anteriormente.
Por supuesto, no siempre vamos a querer guardar estos resultados: en casos donde es muy probable que la información sea muy dinámica y lo más importante es contar con la información actualizada al segundo lo correcto sería justamente lo contrario, invalidar la caché de modo de siempre contar con datos reales.
Hay básicamente dos puntos donde podemos controlar el almacenamiento en caché de las respuestas AJAX: al momento de realizar la petición o bien al generar y enviar la respuesta. En el primer caso, el control estará de parte del cliente; mientras que en el segundo por la respuesta generada por la aplicación.
Caché volátil
Por caché volátil me voy a referir fundamentalmente al que podemos controlar desde el cliente, y que por lo general está acotado a la duración de la sesión, es decir, dura mientras el documento permanezca abierto — con dos excepciones que mencionaré más adelante.
Horizontally scaling PHP applications
One of the most common worries of the enterprise IT world about WordPress and other Open Source apps it’s how you can scale it — which it’s kind of ironic when their enterprise-y web services response times are usually measured in the scale of tens of seconds…
DigitalOcean has published a high-level practical-overview on horizontally scaling PHP apps that’s a good starting point and I guess it could also apply to other kinds of apps as well.
Optimización AJAX 2: compresión GZIP
Habilitar la compresión de la respuesta puede reducir la cantidad de datos enviados alrededor de un 70%. La mayoría de los navegadores soporta recibir contenidos, e informan de esta capacidad al servidor al realizar una petición.
Es posible agregar la indicación de comprimir la respuesta del servidor en su configuración de acuerdo al mime-type de la respuesta: text/html, text/plain, application/json, application/xml (y en general, es conveniente activarlo para cualquier lenguaje basado en texto, como text/html, text/css, application/javascript, application/json).
Habilitar compresión en Apache y nginx
En Apache puedes habilitar la compresión gzip añadiendo las siguientes líneas a la configuración del servidor o el archivo .htaccess relevante:
<ifModule mod_gzip.c> mod_gzip_on Yes mod_gzip_dechunk Yes mod_gzip_item_include file .(html?|txt|css|js|php|pl)$ mod_gzip_item_include handler ^cgi-script$ mod_gzip_item_include mime ^text/.* mod_gzip_item_include mime ^application/x-javascript.* mod_gzip_item_exclude mime ^image/.* mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.* </ifModule>
En el caso de nginx puedes activarlo dentro del bloque http de la configuración de modo que quede disponible para todos los virtual hosts configurados o bien por bloques server o incluso location.
En Ubuntu estos parámetros suelen venir en la configuración por defecto pero comentados.
gzip on; # deshabilitar para IE 4 a IE6 gzip_disable "msie6"; gzip_vary on; # des/habilitar compresión para respuestas de las nginx hace de proxy gzip_proxied any; # nivel de compresión, de 1 a 9 gzip_comp_level 4; gzip_buffers 16 8k; gzip_http_version 1.1; # los tipos de respuesta que se enviarán comprimidos. siempre incluye text/html gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
Habilitar compresión desde PHP
También es posible activar la compresión de la respuesta en la misma aplicación; por ejemplo en PHP esto se puede lograr de forma muy sencilla con ob_gzhandler:
/**
* Si el navegador no soporta Gzip,
* la condición retorna falso y se abre un buffer normal
*/
if ( ! ob_start('ob_gzhandler') ) ob_start();
echo $out;
ob_end_flush();
exit;
Cómo comprobar si la respuesta fue comprimida
Puedes comprobar si la respuesta se está enviando efectivamente comprimida con las herramientas de desarrollo de Chrome (debes habilitar la opción use large request rows, junto a la opción para mostra los filtros de contenido).
En la columna Size, puedes ver dos cifras: la primera corresponde al tamaño del cuerpo de la respuesta, mientras que la segunda a los datos transferidos. Si la cantidad de datos transferidos es menor al tamaño de la respuesta, significa que la compresión está funcionando.
Optimización AJAX 1: elección del método HTTP
Si bien las interacciones en AJAX nos permiten obtener información de forma dinámica desde el servidor de un sitio web o aplicación, existen varias formas de aumentar la velocidad de estas respuestas para mejorar la experiencia de nuestros usuarios al cargar información bajo demanda, obtener datos de búsquedas u otras interacciones.
Más allá de la parafernalia tecnológica que supone la implementación de una respuesta AJAX (por supuesto, reducida al mínimo con el uso de un framework adecuado), ésta sigue siendo una respuesta HTTP, por lo que se pueden aplicar los mismos principios para mejorar su performance.
En éste y los siguientes posts intentaré revisar la teoría y práctica de las técnicas fundamentales para mejorar la performance de respuestas AJAX y la experiencia de tus usuarios.
Continue reading “Optimización AJAX 1: elección del método HTTP”
HTTP2 for front-end developers
HTTP2 is literally a game-changer for the world of web development, so it shouldn’t be a surprise that some of your best established good practices are bound to change.
For a good starting point, check HTTP2 for front-end developers