Presentación utilizada en el WordPress Euskadi sobre WPO y cómo poder acelerar y mejorar el rendimiento web de sitios desarrollados en WordPress.

1. Acelera tu sitio
WordPress
Dani Reguera
Mondragon Unibertsitatea
@dreguera

2. 2
Cuanto mas rápido vaya un sitio
web 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…
• Hacer WPO en:
– Frontend
– Backend

4. ¿Qué tiene en cuenta el WPO?
“Lo primero y principal: ES 100%
TECNOLOGÍA. La optimización se basa en
las mejoras referentes a la conectividad de
redes, la optimización de los servidores web
y la mejora de los diferentes elementos que
tienen los propios sitios web, desde el HTML
hasta el JavaScript, pasando por los CSS o
la cantidad de peticiones a servidores DNS”
Vía Javier Casares
4

5. ¿Por qué es tan importante el
rendimiento web?
• Cuanto más rápida vaya una web, el usuario
estara 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á mas
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

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

7. 7
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.

8. 8
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 ingresos por usuario

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

10. 10
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%

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

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

13. 13
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 volumen
de tráfico

14. 14
Shopzilla consiguió reducir el tiempo de carga de las
páginas de 7 segundos a 2 segundos y la conversión se
incrementó entre un 7% y un 12%, además de aumentar
un 25% las páginas vistas en el sitio y reducir a la mitad
el número de servidores

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

16. 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.
16

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

18. 18
¿Qué herramientas
disponemos?

19. 19

20. 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
20

22. 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. Algunas herramientas más
• Loads.IN: Nos permite analizar el tiempo de carga
de una página en concreto desde diferentes
puntos del mundo.
• Web Page Analyzer: Permite calcular el tamaño
de la página, tiempo de descarga y también nos
da mejoras.
• Pylot: Permite realizar pruebas de carga HHTP de
forma que se pueda calcular el stress.
• Site-perf: Permite calcular el tiempo de carga de
una página de manera realista dando información
de todo tipo.
23

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

25. Estadísticas de rastreo

26. 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 seria entre 150 y 250
• A partir de 1seg (1000mseg) ya sería un
tiempo malo y deberíamos tomar medidas

27. Tiempos de carga en Google
Analytics

28. Tiempos de carga en Google
Analytics

29. 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. Punto de partida

31. Punto de partida

32. El deseado

33. El “deseado”

34. 34
Optimización de las
imágenes

35. ¿Qué formato escoger?
• A día de hoy hay tres formatos principales
que son soportados por la red:
– PNG
– GIF
– JPEG
• Aunque la imagen se vea perfectamente no
significa que sea la óptima
• Cada formato tiene su propia manera de
gestionar los colores. Algunos guardan todos
los colores y otros solo los colores en uso.
35

36. ¿La imagen tiene muchos colores?
• SI
– JPG:
• Progresivo
• Optimizado
• Lossless
– WEBP: Formato beta
• NO:
– Transparente:
• SI:
– Alpha: PNG8
– Parcial: PNG24 > PNG8
• NO: PNG8
via Sergio Falcon otro WPO master

37. Reducción con ImageAlpha

38. Reducción con ImageAlpha

39. Reducción con jpegmini

40. Optimizando los jpgs
¿Optimizada del todo? ¿Que opinas
@ricadpriet? ;-)

41. http://jpeg-optimizer.com/
Yes we can 

43. Imagen de muy
mala calidad y muy
pixelada

44. Utilizar CSS-Sprites

45. Utilizar CSS Sprites
• Reducimos considerablemente el número
de peticiones
• Combinamos las imágenes en una grande
y así conseguimos una única descarga.
• “Mejor una descarga grande que muchas
pequeñas
• http://dariobf.com/css-sprites-tutorial/

46. Ejemplo de uso de css-sprites
<style>
#menu span {
width:128px;
height:110px;
display:inline;
float:left;
background-image:url(/iconos.png);
}
.icono1 { background-position:0 0;}
.icono2 { background-position:-128px 0;}
.icono3 { background-position:-256px 0;}
.icono4 { background-position:-384px 0;}
.icono5 { background-position:-512px 0;}
.icono6 { background-position:-640px 0;}
.icono7 { background-position:-768px 0;}
</style>

47. 47
Optimización de los CSS

48. Optimizar los archivos CSS
• Los archivos CSS son hojas de estilo que
lo que nos hacen es dar el diseño que
queremos a la página.
• Para empezar evitar al máximo incrustar
CSS en el mismo HTML.
• El CSS siempre en un fichero externo
para poder cachear si hemos modificado
algo.
• Evitar el uso de @import e utlizar <link>
48

49. 49
http://www.csscompressor.com/

50. 50http://sourceforge.net/projects/cssmerge/

51. 51
http://cleancss.com/

52. WordPress y los ficheros CSS
• De media WordPress tiene un 40% de su
CSS sin utilizar por lo que podemos ver
que no es óptimo su tratamiento.
• Para ello podemos hacer hacer los pasos
anteriores o utilizar algun plugn existente:
– WP-Minify
– W3 Total Cache
52

53. 53
http://unused-css.com/

55. Minificado de nuestro css

58. 58
Optimización del JavaScript

59. Optimización del javascript
• Reducir el código JavaScript es básicamente
eliminar cualquier comentario, caracter o espacio
que no sea util.
• De esta manera conseguimos reducir su peso.
• Combinar los ficheros JavaScript en uno para así
reducir el numero de peticiones (Mejor uno grande
que varios pequeños)
• Cuanto más pequeño el fichero menor será la
petición
• Si es asíncrono Async, AJAX siempre GET y
JSON como almacenamiento
59

60. 60
http://refresh-sf.com/yui/

61. 61
https://code.google.com/p/minify/

62. Nuestro fichero de javascript
minificado

63. 63
Optimización del HTML

64. Optimización del HTML
• El fichero HTML al ser texto podemos
comprimirlo al máximo.
• No incrustar código CSS
• No dejar etiquetas sin cerrar. Aunque no
nos dé fallo estamos haciendo trabajar
más al navegador
• Intentar optimizar al máximo el peso del
fichero que devolvemos, sobre todo para
dispositivos móviles

65. Optimizaciones del HTML
• Nunca incorporar redirecciones por
código, ni por javascript. Siempre es mejor
hacer las redirecciones a nivel de servidor.
• Slash de la URL, tenemos que ver si
trabajamos o no con /, para ello Apache
nos proporciona el mod_dir en el que
podemos decir que nos lo corrija
automaticamente

66. Optimizaciones del HTML
• Comprimir al maximo los contenidos:
– Utilizar compresión gzip/deflate.
• Lo que hacemos con este modo es comprimir
los contenidos, enviarlos y descromprimirlos
al ser recibidos.
• De esta manera ahorramos tiempo de
transferencia.
• Si activamos deflate en nuestro servidor web,
todos los ficheros partirán con la compresión
activada.

67. Activar mod_deflate en Apache
• $ sudo a2enmod deflate;
Ejemplo cedido por @iarenaza

68. Activar mod_deflate en Apache

69. Gzip vs deflate
• Gzip comprime con un ratio más alto
• Deflate utiliza menos CPU

70. 70
Caché

71. Activando mod_expires en Apache

72. Activando mod_expires en Apache

73. 73
https://www.varnish-cache.org/about

74. Varnish Cache
• Varnish Cache es un acelerador de
aplicaciones web, también conocido como
caché de proxy HTTP inverso.
• Se instala delante de cualquier servidor
HTTP y se configura para almacenar en
caché una copia del recurso solicitado.
• Está ideado para aumentar el rendimiento de
las aplicaciones web.
• http://chrisgilligan.com/consulting/varnish-
vcl-and-config-for-wordpress-with-w3-total-
cache/
74

75. Varnish Cache

76. Varnish Cache

77. Varnish Cache

78. Optimizando la plataforma

79. W3 Total cache

80. 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

81. Minificado de css y js

82. 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.

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

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

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

86. Resultados – contenido cache

87. Resultados – home

88. WP Otimizer

89. Eliminar las transacciones muertas
de la base de datos

90. Eliminar las transacciones muertas
de la base de datos

91. ¿Algo más?
• Utiliza HTTP 1.1
• Cookies pocas y muy pequeñas
• Domain sharing, paralelización (6 peticiones)
• CSS en el <header>, para el DOM
• Como mucho dos archivos CSS
• Gestionar las DNS (root53)
• Contrata hosting de calidad
• Evita redirección, por favor.
• Fuentes en vez de imagenes
• Gestión de las fonts, siempre es mejor in da jaus
• Especifica heigth y width en el HTML
• Optimiza las querys de WordPress
• Ultimos posts? Ojo cargar todo…
• …

92. Siempre se puede mejorar… ;-)

93. El mejor WPO es
hacer las cosas bien

94. Con MUCHO
sentido común

95. Eskerrik asko!
Dani Reguera
Mondragon Unibertsitatea
dreguera@mondragon.edu
https://twitter.com/dreguera
https://linkedin.com/in/danireguera