Que un sitio web cargue rápido es algo muy importante cuando desarrollamos un sitio web. Tanto de cara ahorrar costes de infraestructura como para mejorar al máximo la experiencia de usuario, debemos optimizar al máximo nuestro sitio web. Explicación cómo de una manera sencilla y rápida podemos optimizar nuestros sitios desarrollados en WordPress para así conseguir un tiempo de carga y peso de las páginas menores. Autor: Dani Reguera (Profesor e investigador en Mondragon Unibertsitatea). Librecon.io

1. Rendimiento y velocidad,
acelera tu WordPress
dreguera@mondragon.edu Ÿ Dani Reguera Bakhache Ÿ @dreguera

2. Cuanto
mas
rápido
vaya
un
si2o
web
2
mejor

3. ¿Qué
es
el
WPO?
• Labores que hacemos para que nuestro sitio web sea mas
rápido
• Esas labores pueden ser en diferentes ámbitos: Plataforma,
base de datos, maquetaciones, servidores, peticiones…
• Podemos Debemos hacer WPO en:
– Frontend
– Backend
• En definitiva, WPO o Web Performance Optimization es el
proceso de optimización de sitios web tanto a nivel usuario
como a nivel servidor para reducir el tiempo de carga del
mismo.

4. ¿Por
qué
es
tan
importante
que
un
si2o
web
carge
rápido?
• Cuanto más rápida vaya una web, el usuario estará más
tiempo en la página
• Cuanto más rápida vaya una web, habrá menos
porcentaje de rebote
• Cuanto más rapida vaya una web, habrá más
conversiones
• Cuanto más rápida vaya una web, mejoraremos la
experiencia de usuario
• Cuanto más rápida vaya una web, tendremos menos
coste de infraestructura.

5. Para Amazon, 0.1 segundos de retraso
implican una pérdida del 1% de los ingresos
5

6. 6
Según AOL.com, los sitios web que
funcionan rápido tienen 7-8 pag. vistas por
usuario mientras que las lentas 3-4 pag.
vistas.

7. Para Bing, un segundo de retraso implica una
caída del 2,8% de los ingresos, 2 segundos de
retraso implica una bajada del 4,3% de los
7
ingresos por usuario

8. 8
Para Google, 0,4 segundos de retraso
causan una caída del 0,59% de las
búsquedas por usuario

9. Para Facebook, 0.5 segundos más lento
provoca una caída de tráfico del 3%, 1
segundo provoca una caída del 6%
9

10. Google Maps, redujo un 30% del tamaño de
sus ficheros y el número de peticiones
10
aumentó un 30%

11. Para Outlook.com, 6 segundos de retraso,
implica 40 millones de anuncios menos al
mes, lo que supone 6.000.000$ menos al
11
año

12. Netflix, activó el sistema gzip en sus servidores
consiguiendo un aumento de entre el 13% y 25%
de velocidad de carga y reducción de un 50% del
12
volumen de tráfico

13. Para Yahoo!, 0.4 segundos de retraso
causan una caída entre el 5% y el 9% del
13
tráfico

14. Por
lo
general
hablamos
de…
• El 47% de los usuarios esperan que una página cargue
en menos de 2 segundos.
• El 14% cambia de tienda online si la página tarda en
cargar.
• El 40% de los usuarios abandona una página que tarda
más de 3 segundos en cargar.
• El 64% de los compradores que no están satisfechos
cambia de sitio para su próxima compra.
• El 52% de los compradores afirman que un sitio que
carga rápido los fideliza.
14

15. ¿Y qué pasa con las versiones para
dispositivos móviles?

16. Navigation timing – w3c
http://www.w3.org/TR/navigation-timing/

17. ¿Qué herramientas disponemos?

18. 18

19. GtMetrix
• Herramienta web gratuita que nos analiza en
función de Google y Yahoo y nos evalua en
función de la velocidad.
• Nos aporta un listado de aspectos a mejorar
tanto en la web como en el servidor para
mejorar estas valoraciones.
• http://gtmetrix.com
19

21. Pingdom Tools
• Herramienta gratuita y muy potente que nos
permite saber los tiempos de carga, el tamaño
de las páginas
• Nos permite testear desde múltiples
localizaciones
• Compartir los resultados
• Guardar históricos para saber las mejoras que
hemos ido haciendo
• http://tools.pingdom.com/fpt/

23. ¿Qué imagen tiene Google de la velocidad
de nuestro site?

24. Estadísticas de rastreo

25. Estadísticas de rastreo con
WebMasterTools
• Lo que nos dice es el tiempo en milisegundos,
que tarda GoogleBot en entrar en nuestra
página, indexarla y salir. No son datos de
usuarios
• Un tiempo normal sería entre 250 y 500
milisegundos
• Un tiempo óptimo sería entre 150 y 250
• A partir de 1seg (1000mseg) ya sería un tiempo
malo y deberíamos tomar medidas

26. Tiempos de carga en Google
Analytics

27. Tiempos de carga en Google
Analytics

28. Tiempos de carga en Google
Analytics
• Son datos sacados el 1% de nuestras visitas.
• Si quisieramos que nos sacara de todos:
• Importancia de analizar bien los datos:
– Por país
– Por navegador
– Porcentaje de rebote
– Tiempo de estancia en página
• https://www.youtube.com/watch?v=vWMAsIHbB5g

30. ¿Qué tenemos que tener en
cuenta con WordPress?
• Instalación
de
WordPress
• Configuración
de
WordPress
• Plan2lla
• Los
plugins
(plugini's)

31. Instalación de WordPress
• Lo
primero
el
Hos2ng,
¿Qué
necesitamos?
– Uno
de
“men2ra”
– Hos2ng
compar2do
– Dedicado
• Hay
que
ser
realistas
con
el
número
de
visitas
que
tenemos,
tráfico
y
lo
más
importante…
¿Cuantas
visitas
esperamos
tener?

32. Si quieres que te recomiende
uno…

33. Nuestra base de datos
• Pensemos qué base de datos necesitamos…
“No sólo de MySQL vive WordPress”
• Si nos decantamos por MySQL optimicemos al
máximo. (WP Optimize plugin)
• ¿MariaDB?
– Para cargas mas complejas su optimizador trabaja mejor
– El acceso mediante views aligera el proceso de carga
– https://mariadb.com/blog/how-install-and-run-wordpress-mariadb
– http://es.wikipedia.org/wiki/MariaDB

34. Nuestro servidor Web
• Si
nos
decantamos
por
Apache
(como
la
mayoría
de
mortales)
intentemos
op2mizar
al
máximo:
– h`ps://www.digitalocean.com/community/tutorials/
how-­‐to-­‐op2mize-­‐apache-­‐web-­‐server-­‐performance
– Redirecciones:
del
.htaccess
al
h`pd.conf
• Montando
WordPress
sobre
nginx,
“No
sólo
de
Apache
vive
WordPress”
– h`p://mukom.mondragon.edu/socialmedia/como-­‐
instalar-­‐wordpress-­‐usando-­‐nginx-­‐como-­‐servidor-­‐web/

35. Optimizando caché de PHP con
OPCache
• OPcache mejora el rendimiento de PHP
almacenando el código de bytes de un script
precompilado en la memoria compartida,
eliminando así la necesidad de PHP de cargar y
analizar los script en cada petición.
• Esta extensión está incluída en PHP 5.5.0 y
posteriores, y está » disponible en PECL para
las versiones de PHP 5.2, 5.3 y 5.4.

36. Optimizando caché de PHP con
OPCache
• $ sudo gedit /etc/php5/fpm/php.ini
– ;opcache.enable=0 à opcache.enable=1
– ;opcache.memory_consumption=64 à
opcache.memory_consumption=128
– ;opcache.max_accelerated_files=2000 à
opcache.max_accelerated_files=4000
– ;opcache.revalidate_freq=2 à
opcache.revalidate_freq=60
• $ sudo service php5-fpm restart

37. Instalación óptima de WordPress
• Instalar
la
ul2ma
versión
siempre
– $
wget
h`p://wordpress.org/latest.tar.gz
• Permisos:
– Carpetas
(wp-­‐content,
wp-­‐admin,
wp-­‐includes)
con
permisos
755
(rwx
r-­‐x
r-­‐x)
– Ficheros
con
permsiso
644
(rw-­‐
r–
r–)

38. Instalación perfecta de WordPress
• Optimizando el wp-config.php
– Activar la caché de WordPress:
• define('WP_CACHE', true); //El triple de rápido
– Incrementar el autoguardado, por defecto es a 60
segundos:
• define('AUTOSAVE_INTERVAL',160);
– Quitar las revisiones (limpieza en bbdd):
• define('WP_POST_REVISIONS', false);

39. Instalación óptima de WordPress

40. Instalación óptima de WordPress
• Habilitar
la
compresión
gzip
|
deflate
para
nuestro
WordPress:
– Comprimir
al
máximo
los
contenidos:
• U2lizar
compresión
gzip/deflate.
– Lo
que
hacemos
con
este
modo
es
comprimir
los
contenidos,
enviarlos
y
descromprimirlos
al
ser
recibidos.
– De
esta
manera
ahorramos
2empo
de
transferencia.
– Si
ac2vamos
deflate
en
nuestro
servidor
web,
todos
los
ficheros
par2rán
con
la
compresión
ac2vada.

41. Instalación óptima de WordPress
• $
sudo
a2enmod
deflate;
• $
sudo
gedit
/wp-­‐admin/op#ons.php;
– Gzipcompression
=
1

42. Instalación óptima de WordPress
• Sacando partido a WP_Query
– WP_Query es una clase, una de las más importantes
del núcleo de WordPress. Se encarga de determinar
la consulta necesaria a la base de datos de acuerdo a
la información que se está solicitando y, además,
guarda este tipo de consultas frecuentes para
optimizar la carga de la página.
• Op2mizando
con
WP_Query:
– h`p://dariobf.com/wp_query-­‐wordpress/

43. Loop normal de WordPress

44. Loop modificado de WordPress

45. ¿Qué es la pluginitis?
• La dependencia extrema que tenemos de los
plugins
• Los plugins nos relentizan al máximo nuestro
WordPress puesto que modifican la
funcionalidad.
• Site-Builders vs Programadores
• “Yo tengo un plugin…” “Conozco un plugin…”
“He oído hablar de un plugin que te…” “Pues
con WordPress mi sobrino te lo hace gratis”

46. Para empezar…

47. Para empezar…

48. Analizar los plugins
• ¿Qué
plugin
me
relen2za?
– Por
mal
funcionamiento
– Porque
me
sobreescribe
código
– Porque
me
relen2za
la
base
de
datos
– Etc…
• Op2micemos
esos
plugins
– SEO
Yoast
vs
Add
Meta
Data
– WP
Touch
Demonio
– Mul2lingüismo:
mqTranslate
vs
WMPL/Polylang

49. ¿Qué plugins “deberíamos” instalar?
• Tratamiento
de
imágenes

50. ¿Qué plugins “deberíamos” instalar?
• Asincronía
de
carga

51. ¿Qué plugins “deberíamos” instalar?
• Caché:
WP
Super
Caché,
WP
Total
Caché

52. W3 Total cache

53. Page Caché
De esta manera sirvo a mis visitantes páginas estáticas del contenido dinámico,
por lo que la carga de servidor es menor.
Con esto consigo que WP no cree la página en cuanto es solicitada y al usuario le
muestro la página que he guardado en memoria

54. Minificado de css y js

55. Database caché
Con esta opción lo que consigo es cachear las querys a la
base de datos cada vez que hago una petición y así no pedir
cada vez.

56. Object cache
Con
esta
opción
lo
que
consigo
es
cachear
los
objetos
de
MySQL.
Esto
no
siempre
baja
el
2empo
de
carga.

57. Browser caché
Defino de esta manera la caché del navegador para decirle
cuanto tiempo tiempo deben usar ese contenido.

58. Reverse proxy
Vamos a introducir aquí nuestra configuración de Varnish para que funcione
correctamente

59. Resultados – contenido cacheado

60. WP Otimizer

61. Eliminar las transacciones muertas de
la base de datos

62. Eliminar las transacciones muertas de
la base de datos

63. ¿Algo más? Apunta…
• U2liza
HTTP
1.1
• U2liza
CSS-­‐Sprites
• JetPack
y
su
Photon
para
el
tema
de
distribuir
imágenes
• HyperDB
para
distribuir
la
Base
de
Datos
• Cookies
pocas
y
muy
pequeñas
• Domain
sharing,
paralelización
(6
pe2ciones)
• CSS
en
el
<header>,
para
el
DOM
• Como
mucho
dos
archivos
CSS
• Ges2onar
las
DNS
(root53)
• Contrata
hos2ng
de
calidad
• Evita
redirección,
por
favor.
• Fuentes
en
vez
de
imágenes
• Ges2ón
de
las
fonts,
siempre
es
mejor
in
da
jaus
(Google
Fonts?)
• Especifica
heigth
y
width
en
el
HTML
• Ul2mos
posts?
Ojo
cargar
todo…
• …

64. Punto de partida

65. Punto de partida

66. Punto de llegada

67. Punto de llegada

68. El mejor WPO es
hacer las cosas bien

69. Con MUCHO sentido
común, que es el
menos común de los
sentidos…

70. Créditos
• Iñaki Arenaza www.slideshare.net/iareneza
• Increased frecuency by Enrie http://ernie-e.deviantart.com/art/increased-frequency-132219750
• Móvil: http://commons.wikimedia.org/wiki/File:Personal_Health_Apps_for_Smartphones.jpg
• Fast train moving: http://commons.wikimedia.org/wiki/File:Fast_Moving_Train_India.jpg
• WPO por Javier Casares: https://dl.dropboxusercontent.com/u/19964073/Guia-WPO.pdf
• WordPress Performance http://codex.wordpress.org/WordPress_Optimization
• Blog de Darío Balbotín http://www.dariobf.com

71. Eskerrik asko!
Dani
Reguera
Mondragon
Unibertsitatea
dreguera@mondragon.edu
h8ps://twi8er.com/dreguera
h8ps://linkedin.com/in/danireguera