PHPBarcelona Conference - Optimización aplicaciones PHP - Client side

Optimización de aplicaciones PHP: Client side

Optimización de aplicaciones PHP
Client side

Manuel Aguilar
Desarrollo web & sistemas
maguilar@harecoded.com


Manuel Aguilar
Atrapalo.com & Plastiasite

‣Un Amstrad CPC 464 es el culpable de todo...
‣11 años de experiencia en desarrollo web y sistemas.
‣En la actualidad:
Atrapalo.com: PHP, front end e internacionalización.
Plastiasite: FreeBSD, PHP, Zope/Plone loving.
3viajesaldia.com: escritos y viajes 3.0


Puntos que vamos a tratar

‣ Porqué es tan importante optimizar en el lado cliente... La
regla del 20/80.
‣ Herramientas de detección de cuellos de botella: Firebug,
Yslow.
‣ 10 optimizaciones que harán volar nuestros sitios web.
‣ Ruegos y preguntas.


http://www.dominio.com

www1.dominio.com

images.dominio.com

INTERNET



<?xml v
<ref:
<gr

HTML

www1.dominio.com

images.dominio.com

INTERNET



<?xml v
<ref:
<gr

HTML

www1.dominio.com
<?xml v <?xml v <?xml v
<ref: <ref: <ref:
<gr <gr <gr

xml js css

images.dominio.com
jpg gif

INTERNET flash


Carga de páginas web:
La regla del 20/80

‣ Un estudio de YAHOO! nos dice que del tiempo total de
carga de la Home de los sitios más populares de Internet:

Una media del 20% corresponde al lado servidor
(entregar un index.html)
El 80% restante corresponde al lado cliente (carga de
js, css, img, ajax, ﬂash, etc.)


Carga de páginas web:
La regla del 20/80

‣ Un estudio de YAHOO! nos dice que del tiempo total de
carga de la Home de los sitios más populares de Internet:

Una media del 20% corresponde al lado servidor
(entregar un index.html)
El 80% restante corresponde al lado cliente (carga de
js, css, img, ajax, ﬂash, etc.)

‣ Por tanto, las optimizaciones que realicemos sobre el lado
cliente tendrán impacto sobre un 80% del tiempo de carga.


20%


80%


Tiempo bajar HTML Tiempo restante
Yahoo! 10% 90%
MySpace 9% 91%
MSN 5% 95%
ebay 5% 95%
Amazon 38% 62%
YouTube 9% 91%
ElPais 15% 85%
Atrápalo 10% 90%
Barrapunto 18% 82%
Terra 4% 96%


= servidor
Yahoo! 10% 90%
MySpace 9% 91%
MSN 5% 95%
ebay 5% 95%
Amazon 38% 62%
YouTube 9% 91%
ElPais 15% 85%
Atrápalo 10% 90%
Barrapunto 18% 82%
Terra 4% 96%


= cliente
Yahoo! 10% 90%
MySpace 9% 91%
MSN 5% 95%
ebay 5% 95%
Amazon 38% 62%
YouTube 9% 91%
ElPais 15% 85%
Atrápalo 10% 90%
Barrapunto 18% 82%
Terra 4% 96%


Optimización en el cliente:
no todo es reducir tiempos...



Lo que importa es la
percepción de velocidad del usuario.



Lo que importa es la
percepción de velocidad del usuario.

‣ Los elementos aparecen progresivamente, siempre hay
cambios.
‣ Dejamos para el ﬁnal de la carga elementos que no
requieren interacción.


Manos a la obra... ¿por dónde empezamos?

‣ Mi web tarda en cargar más de la cuenta, efectivamente,
pero... ¿cuáles son los motivos?


Manos a la obra... ¿por dónde empezamos?

‣ Mi web tarda en cargar más de la cuenta, efectivamente,
pero... ¿cuáles son los motivos?

‣ Debemos auditar la carga de la página, y detectar los
cuellos de botella.


Herramientas para detectar
cuellos de botella en la carga de páginas

Mozilla Firefox 2 & 3

+
Firebug (extensión Firefox)

+
YSlow (extensión para Firebug)


Hay un antes y un después
de Firebug en el mundo del desarrollo web...

1994 2000 2008


Herramientas:
‣ Plugin de Firefox que integra muchas herramientas para el
desarrollador web, de gran utilidad. Por ejemplo:

Nos muestra la actividad de red: qué carga
nuestra página, en qué orden y con qué tiempos.

Inspecciona y edita el HTML en vivo.

Consola de javascript: evaluación y debug.


Ahora ya sí... ¡a optimizar!


Optimización: caché expires
‣ Según Yahoo!, el 75% de las visitas a sus páginas vienen con
elementos ya cacheados.
‣ Para el resto de los mortales, entre el 40-60% de las visitas vienen
con caché. No es una cifra nada despreciable...
‣ Si aumentamos el tiempo de expiración de elementos que
no cambian con frecuencia: imágenes, javascripts, etc. conseguiremos
que los navegadores guarden sus cachés por más tiempo.
‣ Cuando queramos forzar el refresco de un elemento, le ponemos de
suﬁjo un id de versión, ej: public.js?v=20081212
‣ Otra opción es poner de nombre al ﬁchero el md5 de su contenido:
main-811a8ba4fbabed723fcd9c165b6f5d2c.css


En Apache:


En Apache:

ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpg A2592000
ExpiresByType image/jpeg A2592000


Cómo mola la Web 2.0, pero...

‣ Gran parte de la programación pasa al lado cliente: miles
de líneas de javascript, css. Enviamos mucha más
información... ¡a veces más de 500kb en una página!
‣ Las librerías javascript hacen de todo, pero valen su peso
en... Kb. El ADSL es nuestro amigo, pero no hay que abusar.
‣ Mashups: integramos varias herramientas de terceros vía
ajax, la latencia de red se convierte en crítica.


Librerías javascript más populares

Librería Peso* Peso min. Peso min+gzip

prototype/script.aculo.us 280kb
jquery (con plugins) 200kb

Yahoo! YUI +400kb

* Sin contar css’s, imágenes, librerías auxiliares, etc.




prototype/script.aculo.us 280kb 148kb
jquery (con plugins) 200kb 105kb

Yahoo! YUI +400kb 320kb





prototype/script.aculo.us 280kb 148kb 52kb
jquery (con plugins) 200kb 105kb 36kb

Yahoo! YUI +400kb 320kb 83kb



Optimización:
extraer js y css a ficheros externos

‣ Porque los ficheros externos son fácilmente cacheables
‣ Una modicación en una propiedad css no ha de provocar que el
usuario baje de nuevo todo el html (con css y js empotrado)
‣ Lo mismo para las imágenes: mejor en ficheros externos, cacheadas
‣ Podremos optimizar cómo servimos contenidos. Ejemplo: por
Apache (html) y Lighttpd (js, css, imágenes).


Optimización:
Combinar ficheros para reducir peticiones
Descargas en paralelo
‣ Combinando js y css en uno o dos
ficheros, ahorramos muchísimas
conexiones y tiempos de carga.
‣ Los navegadores están configurados
para aceptar 2 peticiones
simultáneas desde un mismo
dominio: cuantas menos peticiones,
más rápido descarga toda la página.


Optimización: usar subdominios
para aumentar descargas en paralelo

‣ Usar subdominios del tipo:
static.dominio.com,
images.dominio.com, etc. para 2 en paralelo
aumentar el número de
descargas en paralelo.

4 en paralelo

8 en paralelo


Optimización:
compactar javascript
‣ Consiste en reducir el tamaño de los ficheros javascript quitando espacios,
comentarios, a veces reduciendo nombre de variables, etc.

‣ La reducción es de hasta un 50%.

‣ La convención es llamar al nuevo fichero: home.js => home-min.js

‣ Inconveniente. Tenemos que mantener un fichero más bajo control de
versiones, y programar script que genere min cada vez que cambia el js.

‣ Minimizadores más famosos:

• JSMin (http://javascript.crockford.com/jsmin.html)

• YUI Compressor (http://www.julienlecomte.net/blog/)

• Packer (http://dean.edwards.name/packer/)


-28%


javascript sin minimizar


javascript minimizado


Optimización:
compresión gzip
‣ ¡Comprime js, css en más de un 80%!
‣ Forma parte del protocolo HTTP/1.1 que implementan todos los
navegadores modernos.
‣ Apache 1.3 => mod_gzip, Apache 2.x => mod_deflate
‣ Se puede combinar con un minimizador de javascript (#3) para
reducir el tamaño del fichero en más de un 90%.
‣ La mayoría de los hostings tienen configurado gzip para html, pero es
conveniente comprimir también css y js. Incluso respuestas de XML
y JSON.
‣ No comprimir imágenes (ya lo están).


256 kb


256 kb

148 kb


256 kb

148 kb
(gzip)
52kb


Optimización:
Una imagen que contenga muchos sprites
‣ Cada imagen (icono, botón, rollover, banderas, backgrounds), por muy
pequeña que sea, cuenta como petición http request.
‣ Es fácil que tengamos decenas de pequeñas imágenes en una página:
las empotradas en los css también cuentan.
‣ Cargamos una sola imagen agrupando el máximo de sprites que
vamos a usar, y mediante css vamos posicionando cada uno en su
lugar.
‣ La imagen resultante es menor de tamaño que 20 imágenes
individuales.
‣ Pero sobre todo, ahorramos http requests.


Optimización:
mover css al <head>

‣ Mover los css al <head> aumenta la percepción de carga rápida de
la página, ya que los elementos se renderizan progresivamente.
‣ Internet Explorer no renderiza nada hasta que tiene todos los CSS
de la página. Si colocamos uno al ﬁnal, hay que esperar a que cargue
el resto de la página y lo lea.
‣ Lo que comentamos de la percepción: si el usuario ve que se van
renderizando cosas en pantalla, la percepción de velocidad es
positiva.


Optimización:
mover scripts js al final de la página

‣ Mover los js al final de la página, si es posible. En HTTP/1.1, hasta que
no se acaba de leer un js no se sigue con el resto de la carga.
‣ A veces no nos es posible mover todos los js al final
(document.write), pero sí los más pesados (librerías).
‣ En todo caso, podemos evaluar de incluirlos a partir de un punto de
la carga que sepamos que el usuario ya ha visto cambios en pantalla,
y cargarlos mientras éste está “distraido”.
‣ Para mayor control sobre la carga, colocar chivatos en el html que
nos indican que ya podemos cargar el js.


html:

js:


Optimización:
Quitar js y css duplicados

‣ Al montar un html a partir de varios componentes de PHP, en
equipos de varios developers, es común que algún js/css lo acabemos
llamando varias veces en el renderizado de una página.
‣ Esto penaliza a nivel de peticiones (Firefox) pero también porque hay
que evaluar varias veces el mismo código.
‣ Podemos diseñar un pequeño sistema centralizado de inclusión de
javascripts y css, tanto en PHP como en javascript.


Herramientas: YSlow

‣ Extensión de Firebug desarrollada por Yahoo!
‣ Audita la carga de una página web, y le pone notas en
función de 14 reglas de optimización reconocidas.
‣ Nos muestra explicaciones del porqué de las notas
conseguidas y valiosos enlaces a más teoría al respecto.
‣ Muestra estadísticas de uso de cache y componentes en
nuestra página, nos ayuda a contextualizar.


Conclusiones
‣ No hay porqué seguir todas las optimizaciones, ni en un orden
establecido. Implementar progresivamente.
‣ Reducir peticiones http request = mayor velocidad de carga
‣ caché de navegador agresiva
‣ agrupación de elementos (js, css, imágenes)
‣ Comprimir salida con gzip (excepto imágenes). Además, minimizar
ﬁcheros javascript.
‣ Concentrarse en la parte de la página que ve primero el usuario:
renderizarla lo antes posible.
‣ Hacer la carga de las páginas progresivas, siempre han de verse
cambios.


Enlaces de interés
- http://getﬁrebug.com
- http://developer.yahoo.com/performance/rules.html
- http://yuiblog.com/blog/2006/11/28/performance-research-part-1/
- http://www.julienlecomte.net/blog/2007/08/13/
- http://httpd.apache.org/docs/2.0/mod/mod_deﬂate.html
- http://jeremy.zawodny.com/blog/archives/009272.html
- http://www.vladville.com/using-apache-mod_expires-for-faster-ajax-sites
- http://www.julienlecomte.net/blog/2007/08/11/
- http://alistapart.com/articles/sprites


¡Gracias!
Esta presentación y más cosas las tienes en:
http://www.phpbarcelona.org
Manuel Aguilar
maguilar@harecoded.com

Patrocinadores

PHPBarcelona Conference - Optimización aplicaciones PHP - Client side

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (12)

Similar a PHPBarcelona Conference - Optimización aplicaciones PHP - Client side

Similar a PHPBarcelona Conference - Optimización aplicaciones PHP - Client side (20)

Último

Último (13)

PHPBarcelona Conference - Optimización aplicaciones PHP - Client side