Por qué la velocidad de carga es crucial para tu web

Que tu web o blog cargue rápido seguro que es una de tus principales preocupaciones, y si no lo es, debería serlo, ya que creo que no hay nada peor que entrar en una web lenta que provoque una mala experiencia de navegación.

Si una web o blog carga lento, sin duda puede abocarla al fracaso. Veamos porqué es tan importante la velocidad de carga en un sitio web.

Tengas un blog, página web corporativa, ecommerce o lo que sea, la velocidad de carga es algo crucial para el éxito de tu proyecto.

Empecemos con un dato de los que molan:

El 40% de los usuarios abandona una web si tarda más de 3 segundos en cargar – Akamai

Cómo afecta la velocidad de carga a tu web o blog

Si tienes un blog, ya sabrás que una de las partes más importantes, sino la que más, es conseguir una buena lista de suscriptores. Si tienes un blog lento, la posibilidad de que los usuarios se planteen y completen el proceso de darte su correo electrónico disminuye de forma considerable.

La velocidad de carga de una web o blog afecta al posicionamiento orgánico, según lo indicado por el propio buscador. Además, se trata de algo lógico: si tu web carga muchos recursos o lo hace de forma poco eficiente, además de molestar a los usuarios, Google indexará más lentamente tus contenidos, por lo que la cantidad de contenido que pueda indexar de tu dominio será mucho menor que si tuviera una velocidad de carga más rápida.

En un ecommerce, si consigues mejorar el tiempo de carga, conseguirás mejorar las conversiones con casi total seguridad.

Hay que tener en cuenta que para realizar una compra el usuario tiene que completar un proceso de al menos 2 pasos (o más), por lo que el tiempo de carga de cada página puede hacer desesperar a nuestros usuarios e invitarlos a irse a otro sitio a comprar.

En cualquier web o ecommerce, un tiempo de carga lento afectará a tu marca. Si visitas un blog que carga de forma lenta y ofrece un pobre experiencia de usuario, es poco probable que el usuario vuelva a visitar dicho blog.

Medir la velocidad de carga de tu web

En este ejemplo comprobamos la velocidad de carga de seoh1.com, y puede que no sea el mejor ejemplo ya que (de momento) tiene poco contenido y todavía no hemos optimizado la velocidad de carga con caché (cuando lo hagamos compararemos de nuevo).

Como verás, la herramienta es muy intuitiva y viene a contarnos lo mismo que otras como gtmetrix.com, aunque prefiero pingdom por la pestaña de “Performance Grade”, donde se da nota a varios aspectos a tener en cuenta y se recomienda al mismo tiempo.

Consideraciones para mejorar el tiempo de carga

Vamos a mencionar algunos puntos para mejorar la velocidad de carga de tu sitio web.

Contrata un VPS y abandona tu hosting compartido

Cuanto más grande sea tu sitio web, más notarás que un hosting compartido se queda corto para tus necesidades. La cuestión aquí es conocer el momento exacto en el que migrar de un hosting compartido a un VPS, así que antes de darte vagos consejos, la mejor recomendación que puedo hacerte es que hables con alguien que controle de servidores o en su defecto, con el servicio técnico.

De hecho, probablemente será el cambio que más notes en cuanto a la velocidad de carga de tu web. Nosotros te recomendamos los VPS de HostEurope, ya que son muy potentes, escalables y están optimizados para WordPress a precios muy competitivos.

Si buscas una solución profesional, sin duda contrata el hosting de Webempresa.

Controla el tamaño de tus imágenes

Ya sea antes de subirlas con Photoshop, kraken.io o, a posteriori, con plugins como Wp Smush.it. Este último es muy buena opción, porque te permite comprimir y optimizar las imágenes de tu galería de WordPress nada más subirlas, o hacerlo en bloque para las que ya tengas.

Compresión

Personalmente siempre he usado W3 Total Caché, aunque es cierto que existen otros plugins que cumplen con la misma función igual de bien, cuestión de costumbres. Si quieres configurarlo, encontrarás un montón de post donde se explica cómo se hace, como este.

Si sabes o conoces a alguien que sepa de servidores, es preferible que te lo configure él antes de que le metas mano a algo que no conoces 100%, ya que es conocido que las reglas que introduce en .htaccess no son del todo correctas.

De igual forma, en WordPress existen varios plugins para activar la compresión Gzip, aunque también es preferible que alguien de sistemas te configure esta compresión en el servidor, ya que este tipo de plugins pueden dar conflictos con las tareas Cron que sirven, por ejemplo, para programar la publicación de los post.

Con este código en tu archivo .htaccess puedes optimizar la caché fácilmente con el sistema DEFLATE:

# 1. COMPRIMIR

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript text/x-javascript application/javascript application/x-javascript application/xml
SetOutputFilter DEFLATE

# 2. CACHEAR

    ExpiresActive On
    ExpiresByType image/jpg "access plus 1 year"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/gif "access plus 1 year"
    ExpiresByType image/x-icon "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType text/javascript "access plus 1 month"
    ExpiresByType text/x-javascript "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType application/pdf "access plus 1 year"
    ExpiresDefault "access plus 2 days"

# 3. Compatibilidad con navegadores antiguos

    <FilesMatch ".(js|css|xml|gz|html)$">
        Header append Vary: Accept-Encoding

1. Comprimir los archivos

Para la compresión elegimos el algoritmo DEFLATE porque, como norma general, la compresión DEFLATE (librería ZLIB) requiere menos recursos que GZIP.

Comprimimos el código HTML generado y los recursos estáticos (css y javascript):

    
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript text/x-javascript application/javascript application/x-javascript application/xml
SetOutputFilter DEFLATE

2. Leverage Browser Caching

Consiste en añadir cabeceras HTTP para el control de la caché en los navegadores. De esta manera, el navegador pedirá estos archivos únicamente la primera vez que los solicite. Para posteriores peticiones empleará los archivos almacenados en la caché del navegador hasta que expire el plazo indicado para los mismos.

ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/pdf "access plus 1 year"
ExpiresDefault "access plus 2 days"

3. Accept-Encoding

Debido a que la práctica totalidad de redes hacen uso de cachés intermedias y CDNs, es necesario incluir la cabecera «Vary» a fin de discriminar las peticiones sobre un mismo archivo realizadas por distintos clientes.

Imaginemos dos navegadores, uno más antiguo que no acepta/entiende peticiones comprimidas y otro sí. Entre los clientes y el servidor de caché hay un servidor proxy que cachea los archivos y determina qué enviar a los navegadores.

El navegador que solicite un recurso por primera vez determinará si la página que se almacena en el servidor proxy estará comprimida o sin comprimir.

Si el primer navegador en solicitar el recurso no trabaja con compresión, dicho recurso se almacenerá en el servidor proxy será sin comprimir. Por consiguiente, cuando
el navegador que sí acepta compresión solicite el mismo recurso, el servidor proxy le enviará la versión sin comprimir del mismo, resultado en un tiempo de carga mayor.

El otro escenario es todavía peor: si el primer navegador en solicitar el recurso sí acepta la compresión, el proxy almacenará la versión comprimida del mismo. Cuando un navegador que no acepte compresión solicite el recurso se le servirá la versión comprimida, la cual no sabrá procesar y se mostrará de manera ilegible al usuario.

 
    <FilesMatch ".(js|css|xml|gz|html)$">
        Header append Vary: Accept-Encoding
    

En resumidas cuentas, lo que la cabecera HTTP Vary hace es ‘obligar’ a guardar dos copias del recurso, una comprimida y otra sin comprimir. Al cliente (navegador) se le enviará una u otra en función de si las peticiones incluyen o no esta cabecera.

Tras activar la caché en SEOH1, Search Console nos arrojó la siguiente gráfica:

Como puedes ver, el tiempo de carga ha pasado de 596 milisegundos en el pico más alto a ser estable con tan solo 163, coincidiendo con un pico en las páginas rastreadas, ¿casualidad?.

Bueno pues para conseguir estos valores nos decidimos por contratar también uno de los mejores servicios de hosting de España, el de webempresa, que cuenta con un plan básico optimizado para WordPress y con discos duros SSD, y que como ves, escupe las páginas a toda velocidad.

Usa una CDN (Content Delivery Network)

Además del cambio de servidor, usar una CDN puede marcar otro gran cambio en el tiempo de carga de tu web. Lo que hace una CDN, explicado de forma muy sencilla y rápida, es servir los contenidos de tu web (imágenes, archivos, CSS  etc.) desde la ubicación más cercana al usuario, aumentando así la velocidad de carga.

No te obsesiones

De igual forma que con el DA o PA, cuando tenemos un dato numérico, tendemos a obsesionarnos con mejorarlo casi hasta el infinito, y lo mismo pasa con la velocidad de carga. Un tiempo de carga menor a 3 segundos es un dato positivo en la mayoría de sitios web (dependerá del tamaño, cantidad de contenidos, etc.), por lo que obsesionarse con bajar milisegundos en tiempo de carga puede que no merezca la pena en tu caso.