Eliminar dependencias de WooCommerce fuera de sus dominios

Comparto este script que permite eliminar las dependencias de WooCommerce en todas las páginas que no están relacionadas con su funcionamiento; todas salvo el carrito, checkout y las propias paginaciones de WooCommerce.

function bf_dequeue_woocommerce_styles_scripts() {
    if( function_exists( 'is_woocommerce' ) ) {
        if( ! is_woocommerce() && ! is_cart() && ! is_checkout() ) {
            # Styles
            wp_dequeue_style( 'woocommerce-general' );
            wp_dequeue_style( 'woocommerce-layout' );
            wp_dequeue_style( 'woocommerce-smallscreen' );
            wp_dequeue_style( 'woocommerce_frontend_styles' );
            wp_dequeue_style( 'woocommerce_fancybox_styles' );
            wp_dequeue_style( 'woocommerce_chosen_styles' );
            wp_dequeue_style( 'woocommerce_prettyPhoto_css' );
            # Scripts
            wp_dequeue_script( 'wc_price_slider' );
            wp_dequeue_script( 'wc-single-product' );
            wp_dequeue_script( 'wc-add-to-cart' );
            wp_dequeue_script( 'wc-cart-fragments' );
            wp_dequeue_script( 'wc-checkout' );
            wp_dequeue_script( 'wc-add-to-cart-variation' );
            wp_dequeue_script( 'wc-single-product' );
            wp_dequeue_script( 'wc-cart' );
            wp_dequeue_script( 'wc-chosen' );
            wp_dequeue_script( 'woocommerce' );
            wp_dequeue_script( 'prettyPhoto' );
            wp_dequeue_script( 'prettyPhoto-init' );
            wp_dequeue_script( 'jquery-blockui' );
            wp_dequeue_script( 'jquery-placeholder' );
            wp_dequeue_script( 'fancybox' );
            wp_dequeue_script( 'jqueryui' );
        }
    }
}
add_action( 'wp_enqueue_scripts', 'bf_dequeue_woocommerce_styles_scripts', 99 );

A modo de resumen, el funcionamiento es sencillo. Añadimos la llamada a nuestra función en el hook que se encarga de encolar los scripts en WordPress.

En dicha función hacemos una doble comparación: la primera para controlar que WooCommerce está activado y que el código no se rompa; la segunda para desencolar los estilos y scripts sólo en las páginas que no están relacionadas con WooCommerce.

*Nota: Si tu tema crea dependencias en todas las páginas, este script puede romper tu sitio. ¿Cómo saber si tu tema crea dependencias? Por ejemplo, si tiene el carrito o productos siempre visibles en la barra lateral, cabecera o similares.

Obviamente no me hago responsable del uso de este script; su funcionamiento está comprobado aquí mismo, en DarioBF.

Responsive en vídeos incrustados de WordPress

Si has llegado hasta aquí es posible que hayas tenido el problema de los vídeos incrustados de WordPress y el responsive.

En mi caso, al aplicar un max-width: 100% (generalmente con esto sirve para que algo se adapte a todo tipo de dispositivos), el alto del incrustado hacía algo extraño; en unos vídeos era demasiado alto y en otros demasiado estrecho.

El caso es que probé varias soluciones: le di un alto mínimo, un alto máximo, un alto fijo… Y ninguna funcionaba para todas las soluciones.

Al final, la solución es algo más rebuscada, hay que añadir un filtro como este:

/* Adds a wrapper for video embeds */
add_filter('embed_oembed_html', 'my_embed_oembed_html', 99, 4);
function my_embed_oembed_html($html, $url, $attr, $post_id) {
  return '<div class="video-container">' . $html . '</div>';
}

Lo que hace es añadir una capa “contenedor” para nuestro vídeo incrustado.

Además, tendremos que jugar con los estilos de dicha capa contenedora:

.video-container {
	position: relative;
	padding-bottom: 56.25%;
	padding-top: 30px;
	height: 0;
	overflow: hidden;
}
 
.video-container iframe,
.video-container object,
.video-container embed {
	position: absolute;
	top: 0;
	left: 0;
	width: 100%;
	height: 100%;
}

Parece mentira que aún nos sirvan soluciones de hace tres años.

Evitar enlaces permanentes numéricos en WordPress con esta función

Si no incluimos un título antes de guardar el artículo como borrador o publicarlo, WordPress añade automáticamente el post_name (o slug) numérico basado en el id del artículo. Sabes a qué me refiero, ¿verdad?

El caso es que, en algunas ocasiones nos olvidamos de editar el slug antes de publicar nuestro artículo y claro, queda tremendamente feo un slug numérico (y no es que ayude mucho al SEO, por ejemplo).

Por eso, he creado esta función, que se encarga de reescribir el slug en el momento que guardamos o publicamos el post:

/*
*	Rewrite post_name (slug) before publish it using
*	WordPress function.
*/
// initial hook
add_action( 'save_post', 'rewrite_post_name' );
 
function rewrite_post_name( $post_id ) {
 
    // verify post is not a revision
    if ( ! wp_is_post_revision( $post_id ) ) {
        // unhook this function to prevent infinite looping
        remove_action( 'save_post', 'rewrite_post_name' );
 
        $post_name = get_post_meta ( $post_id, 'post_name' );
        $post_id2 = $post_id . "-2";
 
        if( $post_name === $post_id || $post_name === $post_id2 ){
	    // update the post slug
	    wp_update_post( array(
	        'ID' => $post_id,
	        'post_name' => '' // Rewrite based on Post Title
	    ));
	}
 
        // re-hook this function
        add_action( 'save_post', 'rewrite_post_name' );
    }
}

Explicándola paso a paso, tendríamos algo tal que así:

  • Primero, añadimos la llamada a la función que re-escribe el slug al hook “save_post”; lo que hará que cada vez que guardemos un post se invoque a dicha función.
  • A continuación creamos la función encargada de re-escribir el slug.
    • Comprueba que no es una revisión, no nos interesa hacer esta comprobación para todas las revisiones.
    • Recogemos los datos en dos variables: Por un lado el post_name (o slug) actual del artículo, por otro agregamos un -2 al post_id original por si es un artículo previamente descartado. Esto suele ocurrir en WordPress.
    • A continuación hacemos la actualización del campo post_name sólo si el actual post_name (o slug) es igual al ID del post o al ID del post seguido de un “-2”.
    • Las líneas donde desenganchamos el hook save_post y lo reenganchamos no es necesario que entendáis por qué están ahí; pero -en resumen- evitan que entremos en un bucle infinito de actualización del campo post_name.

Esta función la puedes utilizar en tu instalación de WordPress copiándola en el functions.php de tu tema.

Eliminar contenidos de páginas AMP con el plugin de Automattic para WordPress

Si utilizas el plugin de automattic para mostrar tus páginas en AMP, te habrás dado cuenta que el filtro the_content se muestra tal cual, con nuestros shortcodes y demás contenidos.

Puede ser interesante eliminar según que contenidos para seguir la filosofía de AMP, o incluso pasar la validación de las páginas AMP.

Un buen ejemplo serían los botones sociales, si llevan algo de JavaScript para -por ejemplo- mostrar una ventana emergente con ciertas características, AMP no validará, porque no reconoce estos parámetros.

El caso es, que podemos evitar que ciertos contenidos se muestre o no en las páginas AMP con la función is_amp_endpoint(), que nos devuelve un booleando true si la página visualizada es AMP y false en caso contrario.

Con esto, podemos evitar que ciertos contenidos se muestren en las páginas AMP con sólo un if:

if( !is_amp_endpoint() ) //AQUI CONTENIDO QUE NO SALDRA EN AMP

También podemos hacerlo por igualación:

if( is_amp_endpoint() === false ) //AQUI CONTENIDO QUE NO SALDRA EN AMP

¡Ahora ya puedes darle a la imaginación y mejorar tus hooks para evitar errores de validación en AMP!

Más información en GitHub

Etiquetas:

Las plantillas de un tema de WordPress [WordPress Themes II]

Esta es la segunda entrega del tutorial de cómo crear Temas de WordPress desde cero.

Plantilla vs tema, no son lo mismo

Tal y como explicaba en la primera parte del tutorial, un tema es un conjunto de ficheros que le dan apariencia a nuestro sitio web creado con WordPress.

Bien, entre estos ficheros se encuentran diferentes plantillas, que dan la apariencia concreta a según qué sección.

Dicho de otra forma, una plantilla es el fichero que se encarga de representar un tipo de contenido dentro de nuestro tema.

Seguir leyendo “Las plantillas de un tema de WordPress [WordPress Themes II]”

Añadir offset al loop principal de WordPress (con paginación)

Esta no será una entrada extensa, simplemente es un código que he utilizado y creo que viene bien guardar aquí para mi yo futuro.

Supongamos que tenemos un slider/carrusel (¡¡odio los sliders!!) con las últimas 10 entradas en la home. Lo lógico sería no repetir esas mismas entradas en el loop de entradas de la home, ¿verdad?

Para eso, WordPress nos facilita el offset. El problema del offset es que, si utilizamos algún tipo de paginación (bien sea el típico “Entradas siguientes” – “Entradas anteriores” o la paginación numerada), no funciona. No es que no funcione el offset, sino que no funciona la paginación.

Seguir leyendo “Añadir offset al loop principal de WordPress (con paginación)”

WordPress Hooks

Esta es una de esas entradas del megatutorial de WordPress desde cero, quizá más avanzada de lo que eran las últimas entradas que he redactado, pero necesario igualmente. Poco a poco va estando completado y da igual el orden que sigamos, lo importante es aprender.

Antes de ponerte a desarrollar plugins, temas e incluso modificar una plantilla, deberías entender los Hooks (o ganchos, aunque nadie los llama así).

Hook

¿Qué son los Hooks?

Técnicamente son eventos, por ejemplo invocado por la llamada de do_action() o de apply_filters() que ejecutan después todas las llamadas a las funciones enganchadas a ese evento.

Básicamente, intentando simplificarlo, el proceso sería el siguiente:

  1. El hook invoca un observador, que se encarga de recoger una serie de funciones “enganchadas” al evento.
  2. Ejecuta las funciones utilizando call_user_func() de php.
  3. El código de dichas funciones son implementadas en el proceso del core sin modificarlo.

Lo sé, es una explicación un tanto simplista, pero vamos a ir poco a poco, prefiero que lo entiendas de forma sencilla.

Action Hooks y Filter Hooks

Como los Actions y Filters requieren del uso de Hooks para funcionar, lo más frecuente es que oigas hablar de Action Hooks y Filter Hooks. Y yo, que quiero facilitarte la vida, los llamaré así también (sin traducir) para que puedas buscar más facilmente documentación sobre ellos.

Su implementación es similar pero, como veremos a continuación, sus funciones y aplicaciones son totalmente diferentes.

Los Filter Hooks

Los Filter Hooks están diseñados para modificar contenido. Generalmente se enganchan a hooks de procesamiento de contenido; por ejemplo cuando lo guardamos o cuando lo representamos.

Un ejemplo básico de Filter Hook sería el siguiente, con el que modificamos todos los “wordpress” por “WordPress” en nuestros artículos.

<?php
   add_filter('the_content', ‘guorpres_vs_wordpress’);
   function guorpres_vs_wordpress($content) {
      return str_replace('wordpress', 'WordPress', $content);
}
?>

Atención:
No utilices los filter hooks para realizar shortcodes, para esto existe la función add_shortcode(), cuya utilización es muy sencilla.

Además, los filtros pueden ser reutilizados tantas veces como queramos, podemos utilizarlo múltiples veces y en diferentes tipos de contenido.

Como decía anteriormente, pueden modificar el contenido bien antes de guardarlo en la base de datos o bien más adelante, en la fase de renderizado del contenido.

Pero ojo, cuando hablamos de contenidos no hablamos sólo del contenido de artículos y páginas, sino también de autores, comentarios, widgets, enlaces del blogroll, fechas y horas, elementos del escritorio, etc. Todo de forma dinámica sin tocar el código del núcleo de WordPress.

Cómo crear Filter Hooks
Si quieres añadir un filter Hook tendremos que utilizar la función add_filter().

<?php add_filter( $tag, $function, $priority, $accepted_args ); ?>

Su uso es sencillo:

  • Tag: (string) A qué tipo de proceso de contenido debe ser aplicado el filtro
  • Function: (callback) La función a ejecutar.
  • Priority: (int) – opcional. Orden en el que debe ser ejecutado. A número más bajo antes se ejecutará. Por defecto 10.
  • Accepted Args: (int) – opcional Número de argumentos aceptados cuando utilizamos apply_filters() (WP >= 1.5.1). Por defecto 1.

Mi consejo es que os centréis en los dos primeros parámetros, la prioridad dependerá de otros factores.

A tener en cuenta, que la función será la que marque nuestro control sobre el contenido.

Los Action Hooks

Aunque similares en implementación, son completamente diferentes en funcionamiento.

Mientras que los Filter Hooks están enfocados a modificar y actualizar contenidos, los Action Hooks están diseñados para proporcionar una mayor flexibilidad en cómo se procesan los elementos, así como la posibilidad de añadir nuevas funciones al sistema (campos de texto, hojas de estilo, otros tipos de contenido, Custom Post Types, Metaboxes…).

Todo, como siempre, sin alterar el código original del core de WordPress.

Empecemos con un ejemplo:

<?php
   add_action(‘admin_menu', ‘mi_plugin_extraordinario’);
   function mi_plugin_extraordinario() {
      if(function_exists('add_submenu_page')) {
         add_submenu_page(‘plugins.php','Extraordinario', ‘Extraordinario’, 10, ‘my_new_plugin', 'my_new_plugin_admin_page_function');
      }
   }
?>

Digamos que todo Action Hook se ejecuta en tres fases (según el ejemplo anterior, obtendríamos):

  1. El Action: Obtiene el menú de administración.
  2. La petición: Cuando estés generando el Menú de administración, ejecuta esta función que añade un elemento bajo la sección de plugins.
  3. El Resultado: El menú es generado con nuestro enlace, justo debajo de la sección de plugins.

Cómo crear Action Hooks
Al igual que con los filter hooks tenemos una función que se encarga de esto, ¿Adivinas cuál es? En efecto, add_action().

<?php
   add_action($tag, $function, [$priority], [$accepted_args]);
?>

Y, una vez más, los parámetros:

  • Tag: (string) A qué tipo de proceso de contenido debe ser aplicado el filtro
  • Function: (callback) La función a ejecutar.
  • Priority: (int) – opcional Orden en el que debe ser ejecutado. A número más bajo antes se ejecutará. Por defecto 10.
  • Accepted Args: (int) – opcional Número de argumentos aceptados cuando utilizamos apply_filters() (WP >= 1.5.1). Por defecto 1.

Al igual que en los Filter Hooks, lo mejor es que te centres en las dos primeras. Ten en cuenta, de nuevo, que la función es la que marca el control sobre el hook. Vamos, que es con la que controlamos lo que queremos hacer.

Uso de Hooks de forma avanzada (Advance Hooking)

Además, podemos tener control sobre los hooks, conociendo y preguntando a WordPress en todo momento sobre su uso e implementación.

Para ello tenemos estas funciones:

  • has_action y has_filter: Detectan cuándo (o cuándo no) se ha añadido una función al array de hooks para un evento determinado.
  • did_action y did_filter: Detectan cuándo (o cuándo no) se ha invocado un evento. Cuidado, porque si tu evento no ha sido enganchado al hook pero se ha invocado, retornará true.
  • remove_action y remove_filter: Nos permiten eliminar una función específica de un evento determinado.
  • remove_all_actions y remove_all_filters: También podemos eliminar todas las funciones de un evento determinado. Con remove_all_actions(“the_content”, 4) eliminamos todas las funciones enganchadas al hook “the_content” con prioridad 4.
  • current_filter(): Sólo aplicable a los filtros; nos permite saber si el evento actual ha sido procesado.

Como ves, no profundizo en exceso en estas funciones, ya que tienes toda la información sobre ellas en el Codex y, realmente su explicación no es el propósito de esta entrada.

También puedes añadir tus propios Hooks en tu tema (funcions.php) o tu plugin, pero como da para otra entrada… Te lo explicaré más adelante.

Cómo desactivar los emojis en WordPress 4.2.2

Dándole un repaso rápido a mi web (la tengo algo abandonada, lo reconozco) me he dado cuenta de que la versión 4.2.2 de WordPress activa los emojis por defecto (¿WTF WordPress?)

Así que, me he puesto a mirar cómo desinstalarlos y he visto que varios sitios recomiendan plugins: que si uno para activar los que existían previamente y así inhabilitar los nuevos, que si otro para inhabilitarlos todos…

En mi caso, he creado unos hooks para evitar estas llamadas, ya que no quiero emoji alguno:

    /**
     * Desactiva los emoji's
     */
    function desactiva_emojis() {
        remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
        remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
        remove_action( 'wp_print_styles', 'print_emoji_styles' );
        remove_action( 'admin_print_styles', 'print_emoji_styles' );
        remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
        remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
        remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
        add_filter( 'tiny_mce_plugins', 'desactiva_emojis_tinymce' );
    }
    add_action( 'init', 'desactiva_emojis' );
 
    /**
     * Filtro que elimina el plugin de emojis de TinyMCE
     *
     * @param    array  $plugins
     * @return   array             Difference betwen the two arrays
     */
    function desactiva_emojis_tinymce( $plugins ) {
        if ( is_array( $plugins ) ) {
            return array_diff( $plugins, array( 'wpemoji' ) );
        } else {
            return array();
        }
    }

Y con esto, adiós a las llamadas javascript y css que hacen innecesariamente.

WPO WordPress: Mejora la velocidad de carga de WordPress

wpo-wordpress

A raíz de mi tutorial de WPO para front-end sois muchos los que me preguntáis si tendrá más partes o si haré uno para WordPress.

En realidad, poco después de terminar esa serie de tutoriales (son 4) de optimización WPO en el front end, redacté uno sobre WordPress.

El caso es que, como no me gusta abusar de los plugins, no había lanzado este artículo por recomendar demasiados.

¿Qué me ha hecho cambiar de opinión? Pues la utilidad de esta entrada. Aunque recomiende plugins en vez de códigos, creo que es un buen artículo para mejorar la velocidad de carga de WordPress.

Dividiré este mini-tutorial en varias partes, donde explicaré cómo optimizar WordPress tanto a nivel de cliente como de servidor. Veremos cómo mejorar la plantilla, hablaremos sobre plugins y un poco sobre servidor.

Mejorar la plantilla o theme de WordPress

Una plantilla de WordPress, salvo las consultas que realizan las funciones del mismo a la base de datos, no deja de ser front-end; y como tal, te recomiendo que veas mi guía de wpo para front-end (son 3 partes).

A modo de resument (insisto, lee esa guía, está todo mucho mejor explicado), tendremos que cuidar los siguientes factores:

  • Reducir el número de peticiones HTTP: para ello, debemos minificar y reducir ficheros javascript, CSS y, siempre que nos sea posible, usar Sprites CSS.
  • Paralelizar peticiones HTTP: Aunque pudiera parecer que está relacionado con el punto anterior, no es así directamente. Los navegadores descargan contenidos simultáneamente, podemos aprovecharnos de esto utilizando un CDN o un sistema de Domain Sharding.
  • Cuidar el tamaño y orden de los componentes: El tamaño sí importa; a veces es mejor uno grande que muchos pequeños y otras es mejor muchos medianos que uno grande. Además, también influye el orden en que llamamos a estos componentes; mejor CSS en la cabecera y javascript en el pié de página.
  • Evitar 404: Si un fichero (imagen, CSS o JS) dejan de existir, el navegador puede quedarse atascado buscándolo. Intenta evitarlo comprobando que todos los ficheros están donde deben. Si no es así elimina su llamada.
  • Sobre CSS y JS: Aunque ya he comentado varias cosas a tener en cuenta sobre estos ficheros, me reafirmo en algunas: Intenta externalizar algunos de ellos (para paralelizar peticiones), haz que sean cacheables y minifícalos (haz que sólo sean un fichero).

En resumidas cuentas, estos son los factores que pueden afectar al front-end (hay más), pero los que más pueden entorpecer la carga son estos.

Cachea en WordPress

Aunque WordPress gestiona su propia caché, que se puede activar desde WP-config.php con una línea, mi recomendación en esta ocasión es utilizar un plugin para gestionarla de manera más óptima. ¿Cuál? Con el que te sientas más cómodo. Como sé que me vas a pedir que “me moje”, yo siempre recomiendo WP Super Cache, fácil de configurar y muy bueno en sus labores.

Cacheando a nivel cliente
No obstante, algunos analizadores WPO nos pueden decir que debemos incrementar las cabeceras de cacheado de lado cliente (algo como browser caching).

Tranquilo, te explico este concepto de forma rápida: El Browser caching es un parámetro que se especifica en las cabeceras de los ficheros como tal (cualquier imagen, fichero CSS, JS y demás). ¿Podemos modificar estas cabeceras? Poder… se puede, pero no es recomendable. Lo suyo es, a nivel servidor, decirle al cliente (el navegador web en cuestión) el tiempo de caducidad que va a tener ese tipo de fichero.

Por ejemplo, la imagen de un artículo en WordPress no es habitual que cambie, por lo que podemos decirle al navegador que en vez de 2 días de cacheo, le dedique 1 mes. De esta manera, si un usuario visita nuestro sitio web de forma recurrente, las imágenes no las descargará por un mes.

A continuación, os dejo el fichero .htaccess que utilizo yo, donde especifico por tipo de fichero la caducidad:

# ------------------------------------------------------------------------------
# | Expires headers                                                            |
# ------------------------------------------------------------------------------

# Serve resources with far-future expires headers.

# IMPORTANT: If you don't control versioning with filename-based cache
# busting, consider lowering the cache times to something like one week.

<ifmodule mod_expires.c>
 
    ExpiresActive on
    ExpiresDefault                                      "access plus 1 month"
 
  # CSS
    ExpiresByType text/css                              "access plus 1 year"
 
  # Data interchange
    ExpiresByType application/json                      "access plus 0 seconds"
    ExpiresByType application/ld+json                   "access plus 0 seconds"
    ExpiresByType application/vnd.geo+json              "access plus 0 seconds"
    ExpiresByType application/xml                       "access plus 0 seconds"
    ExpiresByType text/xml                              "access plus 0 seconds"
 
  # Favicon (cannot be renamed!) and cursor images
    ExpiresByType image/x-icon                          "access plus 1 week"
 
  # HTML components (HTCs)
    ExpiresByType text/x-component                      "access plus 1 month"
 
  # HTML
    ExpiresByType text/html                             "access plus 0 seconds"
 
  # JavaScript
    ExpiresByType application/javascript                "access plus 1 year"
 
  # Manifest files
    ExpiresByType application/manifest+json             "access plus 1 year"
    ExpiresByType application/x-web-app-manifest+json   "access plus 0 seconds"
    ExpiresByType text/cache-manifest                   "access plus 0 seconds"
 
  # Media
    ExpiresByType audio/ogg                             "access plus 1 month"
    ExpiresByType image/gif                             "access plus 1 month"
    ExpiresByType image/jpeg                            "access plus 1 month"
    ExpiresByType image/png                             "access plus 1 month"
    ExpiresByType video/mp4                             "access plus 1 month"
    ExpiresByType video/ogg                             "access plus 1 month"
    ExpiresByType video/webm                            "access plus 1 month"
 
  # Web feeds
    ExpiresByType application/atom+xml                  "access plus 1 hour"
    ExpiresByType application/rss+xml                   "access plus 1 hour"
 
  # Web fonts
    ExpiresByType application/font-woff                 "access plus 1 month"
    ExpiresByType application/font-woff2                "access plus 1 month"
    ExpiresByType application/vnd.ms-fontobject         "access plus 1 month"
    ExpiresByType application/x-font-ttf                "access plus 1 month"
    ExpiresByType font/opentype                         "access plus 1 month"
    ExpiresByType image/svg+xml                         "access plus 1 month"
 
</ifmodule>

Cacheando a nivel servidor
Para cachear a nivel servidor, mi recomendación es utilizar Varnish o algún servicio similar. No obstante, plugins como W3 Total Cache gestionan este tipo de cosas. Aquí poco os puedo recomendar:

  • Cacheo de las páginas.
  • Cacheo de la base de datos.
  • Cacheo de objetos (Object Caching).
  • Opcode Caching.

Como digo, en este ámbito no soy un gran conocedor, mejor que busques información sobre este tema por otro lado.

Algunas recomendaciones extras que ayudarán en WordPress

Como no todo es cachear o pulir ficheros, a continuación os enumero algunos de los aspectos que repercuten directamente en la carga de WordPress.

Base de datos
Es casi el pilar más importante de WordPress; cualquier consulta (artículo, página, adjuntos, menús…) va asociada a una consulta a la base de datos. Si no cuidamos la misma, estamos entorpeciendo (considerablemente) la carga de nuestra instalación.

Puedes utilizar WP-Optimize para mejorar la respuesta y optimización de la base de datos de WordPress; este plugin realiza las siguientes acciones:

  • Elimina las revisiones de entradas.
  • Elimina los comentarios no aprobados o spam.
  • Elimina los comentarios de la papelera.
  • Elimina los metadatos de Akismet para comentarios (son muchos, creeme).
  • Elimina otros metadatos de los comentarios que son prescindibles.
  • Limpia los autoguardados en borradores.
  • Limpia la papelera de entradas.
  • Aplica acciones predeterminadas de WordPress para optimizar las tablas de la base de datos.

Además, este plugin me parece maravilloso porque sólo lo pueden utilizar administradores, automatiza la optimización (yo lo tengo activado una vez por semana), no utiliza códigos extraños (las acciones que utiliza para optimizar son las propias de WordPress) y, lo más importante, permite seleccionar el número de semanas a guardar cuando hacemos limpieza (para no borrar contenidos no deseados).

Uso de imágenes
Como comprenderás, un blog tiene muchas imágenes, aunque en mi caso no sea así por la gran cantidad de artículos técnicos que tengo.

Vamos, que las imágenes son una parte importante a la hora de manejar una instalación de WordPress.

Mi recomendación es optimizarlas con herramientas como Photoshop a la hora de guardar e ImageOptim (para Mac) después de guardarla.

No obstante, entiendo que no siempre utilizamos imágenes creadas con photoshop sin que muchas salen directamente de la cámara. Para estos casos recomiendo (muy mucho) WP Smush.it, que se encargará de optimizar tus imágenes “al vuelo”, según las subas a tu WordPress.

Además, siempre recomiendo JetPack, pero no en su totalidad, más bien por un módulo llamado Photon, que hace las veces de CDN, utilizando los servidores de WordPress.com.

Minificación de ficheros HTML, CSS y Javascript
Como os comentaba en el primer punto, es importante hacer una optimización del front-end. En WordPress es complicado, ya que cada plugin (si lo necesita) inyecta su propio fichero CSS, javascript o lo que fuera.

Para estos casos, recomiendo WP Minify Fix, un plugin que minificará el HTML, CSS y JS; y lo hará bastante bien.

¿Hasta qué punto optimizar?

Esta es una cuestión que deberíamos hacernos todos. Es muy desafiante utilizar un analizador tipo GTMetrix y querer ser el mejor de la clase, pero… ¿Es lo mejor para la página?

La respuesta es que no siempre. No siempre es mejor comprimir todos los ficheros CSS en uno, no siempre es importante tener una puntuación alta en estos analizadores, no siempre es mejor cachear a todos los niveles (tampoco siempre es posible, depende de nuestro servidor) y no siempre menos peticiones HTTP implican un sitio web más rápido.

Sobre este punto, te recomiendo leer el artículo que han publicado en WP Rocket, sobre 5 mitos de la optimización de carga (En inglés)..

Mi consejo es que no os volváis locos, optimizar está bien, pero como en todo… los excesos no son buenos.

Si te ha resultado útil este artículo, no dudes en compartirla (utiliza los botones de debajo) y sígueme en Twitter para conocer más aspectos de WPO.

Más información sobre cache y optimización de Base de Datos.

Derechos de imagen