Contenido

Un mal llamado script.aculo.us

19 Mar

+ 48

Los blogs son la revolución de Internet y últimamente se están convirtiendo en una plaga que amenaza con crecer más y más, pero esto ha cambiado mucho desde los principios (como comenta nuestro amigo Daniel).

Daniel comenta que los blogs están mutando, y que parece que la cantidad de herramientas que tenemos para nuestros sidebar hacen de nuestros blogs algo cargante e incluso marea a los visitantes. Una forma de hacer esta zona algo más clara y disminuyendo la cantidad de información (abrumadora) es el uso de efectos javascript como acordeones o deslizantes. Para ello podemos usar miles de librerías, pero nunca nos paramos a pensar cual es la que más nos conviene.

En mi caso, me inicie con script.aculo.us, una librería fantastica, con miles de efecto y muy facil de usar, realmente es algo asombroso lo que se puede llegar a hacer con ella, pero ¿a que precio?.

Un poco de teoría de redes:

La programación web se divide en 2 capas, servidor y cliente. Llamamos servidor a la capa en la que las operaciones se transmiten y se ejecutan dentro del servidor, construyendo la respuesta para enviar al cliente la página que nosotros vemos en nuestro navegador. Y cliente al navegador, donde se ejecutan aplicaciónes como javascript, CSS…

El problema reside en que script.aculo.us es una libraría en Javascript, y como hemos explicado el Javascript se ejecuta en el cliente, por lo tal ha de viajar al cliente, a cada usuario. La librería sola, ocupa 76kb, sin contar la página, imagenes y ficheros de estilos. Esto por desgracia hace que quizas nuestra web en total pese más de 100kb facilmente, lo cual me parece algo realmente exagerado.

Teniendo en cuenta esto, hagamos cuentas. 100kb*N(visitas) = Muuuchos KB / 1024 = menos MB.

En definitiva, cargamos mucho el tiempo de carga de nuestra página. Es cierto que con las conexiones de hoy en día 100kb no son nada, pero imaginar una web como Microsiervos con una web de 100kb la cantidad de información que debe estar transmitiendo por minuto.Esto obliga a tener que buscar servicios con mayor ancho de banda, con su consecuente aumente de precio.

Alguno ejemplos de sobrecarga de web he visto en los tiempos de carga de Vidablog y Proletarium, que usan esta librería. Yo he notado diferencia desde que he dejado de usarla.

Script.aculo.us, es una gran librería, pero tienes demasidas opciones y efectos que no usamos, y eso a mi punto de vista es basura. Por ello tenemos otras librerías con las que podremos hacer cosas muy similares en mucho menos espacio.

Alternativas
moo.fx
jquery
wz_dragDrop 
wz_jsGraphics 
MochiKit 
overLIB 

  • Gracias por las alternativas, les daré una mirada. Por mientras ya he bajado de 55 sec a 39 sec eliminando varios estilos y js realmente innecesarios.

  • Lo suyo para estas librerias seria currarse una forma que solo se cargaran las que se necesitaran, o cargarse en el momento de pedirlas.

    Hay que andar con cuidado como tu dices, porque sacrificar un peso por un efecto acordeon tiene mucha tela.

  • Si pues según esa utilidad me llevo el premio a web de más peso. xDD

    ¿Va lento mi blog?

  • Show, no veo que tengas muchos efectos, ¿que le has puesto?
    Por que según esto te tarda 101 segundos en cargar!!!!!

  • Pues yo no puedo estar más en desacuerdo, pues la gran mayoría de los lectores de mi blog, y casi todos los que a mí me interesa que me lean, tiene ADSL básico en casa como mínimo, 1 Mb/s que se convierte en unos 700 Kb/s. Haciendo los pertitentes cálculos:

    (700 Kb/s) * (1000 b/Kb) = 700.000 b/s
    (700.000 b/s) / (8 b/B) = 87500 B/s
    (87500 B/s) / (1024 B/KB) = 85,45 KB/s

    b = bits, B = bytes

    Respuesta: 85,45 KB/s

    Si la librería pesa 76 kB, el usuario tarda menos de 1 segundo en cargarla, con lo que no es para tanto. Y eso en España, que en el resto de países desarrollados del mundo esa transferencia es muchísimo mejor. Sí, será una pérdida todo ese código que no se utiliza, pero scrip.aculo.us NO es la razón por la que una página se ralentiza excesivamente.

    Antes que mirar ahí, échale un vistazo a los plugins que tienes instalados, como por ejemplo PopStats, que causan gran parte de esa pérdida por ser código PHP que realiza llamadas a base de datos MySQL, lo cual requiere tiempo, aunque muchos nos merece la pena por los beneficios que nos traen estos plugins.

    Por otra parte, las librerías que mencionas son excepcionales todas, pero la mayoría te ofrecen un ahorro ínfimo que no se nota practicamente a la hora de la carga.

    Es mi impresión.

  • Luis, tienes razón en que las conexiones de los usuarios Españoles de media es ADSL, y no es lo mismo que las antiguas conexiones.
    Lo que me refiero es que esos 85,45kb has de multiplicarlo por el número de conexiones simultáneas que tengas, asi ya obtenemos un tamaño mucho mayor. Sin contar el texto, las imagenes y además las llamadas a BD.

    Por eso que tu web pese 323kb, que ya no son los 85kb del principio.

    De todas formas, siempre dependerá del servidor y franja horaria en la que te conectes, dependiendo de lo colapsado que esté el servidor.

    Las llamadas MYSQL, sobre tablas medias (las grandes son un poco especiales) son un mal menor y necesario, ya que al hacerse generalmente sobre el mismo servidor el tiempo de respuesta suele ser algo insignificante. Pero tambien influyen 😉

  • Así sólo cargas lo que se necesita.
    [script src=»scriptaculous.js?load=effects,dragdrop» type=…][/script]

  • Echo off, conocía esta opción y la he sado en algún theme. Pero continuo pensando lo mismo.

    Por ejemplo, si cargas effects para un simple FadeOut, estas cargando todos los otros efectos que no usas para nada…. Y son ficheros muuuuy grandes.

  • He estado mirando las alternativas. Y algunas de las opciones estan bastante bien. Además de ser prácticas.

    He estado mirando moo.fx y tiene una pinta bastante buena. Aunque he echado de menos las demos que se pueden encontrar en los otros sites.

    ¿Hay en algún sitio de moo.fx, donde se pueda ver demos de las diferentes funcionalidades ?

  • Bueno… yo soy más de la opinión de 5. Además hay que contar con la caché de los navegadores.

    En cualquier caso hay que pensar que cada vez más se demandan contenidos visuales con efectos de todo tipo y es lógico que también se necesiten recuros mayores (como el ancho de banda por ejemplo). Pero en eso consiste un poco todo este mundillo no?. 😉

    Un saludo.
    Pablo

  • Si análizas el trafico con algun sniffer o proxy HTTP vas a ver que el request para ese .js lo transfiere únicamnete la primera vez. Después de eso queda en el caché del browser y lo único que hace es verificar si hay una versión nueva en el server.
    A lo sumo lo está transfiriendo una vez por usuario por sesión.

  • @Diego: Estoy de acuerdo, pero si tienes 1.000.000 de usuarios, estás enviando 200kb de javascript a cada usuario, lo que hace la friolera de 200.000.000kb. La transferencia se resentiría 😀

  • Amigo, esto refleja no mucho conocimiento de la cuestión. Los js se transfieren solo la primera vez, luego, sale del cache. Con lo cual tu teoria, al tacho!
    Es mas, te diria que el problema pasa por otro lado! Es la cantidad de cosas que se le obliga a hacer al navegador del lado del cliente. Y en eso, en ancho de banda no tiene nada que ver. Quizás deberias considerar actualizar tu PC!

  • @joselo: Si tienes 100.000 visitas únicas diarias estás enviando casí 200kb cada una de las 100.000 visitas que entran… matemática básica.

    Saludos, gracias por comentar.

  • No se en que versión te basastes para escribir este artículo. Pero a día de hoy las librerias de scriptaculous se pueden cargar de forma que sólo se usan las que se necesitan en cada página. Otra cosa es que por perrería la gente no ponga sólo las necesarias.

    También existe la opción en el servidor para que estos archivos JS se cacheen, también disminuye el tiempo de respuesta, con lo que esos k’s perdidos de los que tanto haces incapié solo se pierden la primera vez que entres en la página y no «n» veces.

    Y esto ya gracias a prototype, te permite realizar un «Ajax.request» lo cual también reduce la carga de una página ya que solo actualiza una parte de ella. Pero usando scriptaculous también se puede cargar toda la página ocultando ciertas capas y mostrarla solo cuando sea necesario ahorrando el coste de transferencia de una recarga de página.

    Y por último Google ha incluido estas librerias en sus servidores ver más aquí ->
    http://ajaxian.com/archives/announcing-ajax-libraries-api-speed-up-your-ajax-apps-with-googles-infrastructure Y esto aún proporciona muchisimas más ventajas aún si quiera y desvirtúa complemtamente tu artículo.

  • @Deathtime: ¿has leido los comentarios? ¿te has molestado en buscar? ¿O simplemente has llegado a soltar lo primero que te pasa por la cabeza?

    Te explico (por enésima vez), por mucho que solo se descargue la primera vez y que el navegador lo reutilize, bla bla,… si tienes 1.000.000 de visitas únicas, estás descargandolo 1.000.000 de primeras veces, lo que a nivel de servidor implica un alto rango de transferencia, lo que en la mayoría de servidores se traduce en dinero.

    El que puedas elegir que porciones de script.aculo.us quieras o no, no soluciona los 80kb (mínimos) de Prototype. Además, si has echado un vistazo al código de script.aculo.us verás que casi todo está relacionado y si como mínimo necesitas, además, Element lo que significa 15kb más.

    Osea que como mínimo estarías sirviendo 95kb por visita única…

    Evidentemente (2 años despues de este post) Google se dió cuenta de que es la única empresa que puede hacer frente a dicho tráfico, así que lanzó el Google Ajax Libraries.

    Saludos

  • antes tenés muchas otras cosas que hacer para mejorar tu sitio, por ejemplo para este blog:
    1) hacer menos requests http: tenés 7 javascript externos, 5 hojas de estilo y 59 imágenes de background en css
    2) usá un cdn, tenés todos los archivos en un mismo servidor, usar cdn permite cargar contenido simultáneamente
    3) usá el header de expires de http, ninguno de los archivos en este sitio declara cómo guardarse en caché.
    4) usá mod_gzip para comprimir los archivos enviados
    5) cargá los js al final de la página
    6) podés minimizar los javascripts, ninguno está minimizado, tenés 30K en javascript que podrían ser 10K.
    7) usá un servidor de caché inverso como squid o varnish, solamente con eso podrías generar un 500% más de páginas por segundo.
    8) sacá keep-alive de los headers de http

    con caché vacío esta página transfiere 274.8K en 96 request, de la manera que está configurada ahora utilizando el caché son 44.9K en 95 requests,

    si te fijás mi sitio (http://www.spiler.com.ar/) genero 153.3 K en 22 requests sin caché y 14.7K en 21 requets, ese blog está en una computadora casera que tiene solo 128 kbps de upstream.

    cuando tenés mucha cantidad de visitas el problema ya no pasa por la conexión, porque si tenés esa cantidad y el equipo necesario podés recuperar varias veces el costo de la conexión con publicidad, en ese estado lo que tenés que pensar es en qué capacidad tiene tu servidor para generar respuestas simultáneas

    sin caché inverso mi servidor puede responder un máximo de 15 requests simultáneos por segundo, con caché inverso puede responder más de 3569 requets por segundo, de hecho si sacás las cuentas mi servidor con esta configuración puede generar más páginas de las que puedo transmitir por la conexión =) asique poner o sacar un script porque es pesado… no me parece justificativo para decir que es un «mal», simplemente no encontraste una mejor solución.

  • Hola pero realmente funciona ya que siempre que trato de usarlo me sale el depurador o que estoy haciendo mal no habra un manual para saber que tengo que hacer para que funcione

    atentamente
    jose

  • Hola no estoy tan de acuerdo con algunas cosas que dices, en lo particular a mi tampoco me gusta abusar de los efectos y cosas que se hacen dentro de lagunos sitios. La libreria pesa 76 kb y es cierto que si entran muchos al sitio se descargará, pero esto es solo la primera vez ya que existe un mecanismo muy malo pero eficiente denominado cache. Entonces el archivo del kernel se descarga una vez (a menos que borres el cache) y esto pasa con todos los sitios, En realidad 76 Kb por todo lo que ofrece es una ganga de recursos de red, ya que si haces lo mismo con flash minimo te llevas la mitad(y este es estatico y se descarga mas veces que un archivo de texto plano o javascript), Si tu plan es poner solo unas cuantas animaciones y solo determinadas, pues busca otras opciones, si quieres hacer algo complejo y que no pese tanto, esta es una buena opcion (OJO no es la mejor).

    El problema con scriptaculous radica principalmente en los recursos del cliente, si eres de los que gusta de tener 20 aplicaciones abiertas al mismo tiempo, si te alenta la pagina, ya que la libreria ocupa funciones que emplean tiempo real del procesamiento y puede verse mermado al momento de ejecutarse.

    Es importante mencionar que mientras mas limpias se mantengan las paginas es mejor para el visitante, y el exeso de animaciones crean confusion, es por esto que debe pensarse exactamente si lo que queremos hacer es realmente necesario, de lo contrario mejor no lo implementen bajo ninguna herramienta.

    Saludos

  • Muy interesante el comentario. Lo que podría aportar es que las compañías de hosting seras buscan soluciones para este tipo de inconvenientes, y en este caso la solucion es sencilla y consiste en configurar al servidor para que la librería javascript no se descargue con cada visita, sino que quede en el caché del cliente por ejemplo durante un mes. Con eso sube la velocidad y se disminuye la transferencia de datos en cada visita.

    Estoy de acuerdo en que scriptaculous es una libreria extraordinaria y que puede ser utilizada sin temor.

  • Creo que el título de este post es muy poco acertado y un pelín amarillista. Como ya se ha comentado, hoy en día preocuparse de si una página ocupa 80kb o 300 no es crítico. Es como decir que hay que programar los juegos en ensamblador porque van más rápido que un lenguaje de alto nivel. Pues será cierto pero con un procesador de 3gb, una tarjeta de video con 128MB de ram y en general un pepinazo de PC, a nadie de la industria de videojuegos le quita el sueño.

    Decir que script.aculo.us es un mal, cuando pesa 76kb y encima se pueden cargar sólo los efectos que se van a usar me parece poco serio.

    Desde luego funciona para atraer lectores, si esa era la intención.

  • Debo añadir, que se me ha pasado, que esos 76kb encima se cachean, por lo tanto se carga una vez y hasta que la versión cambie no se transfieren más al cliente.

  • @Luis: No nos olvidemos de los dispositivos móviles, a mi que las páginas pesen 200kb me cuesta una fortuna al mes.
    @Luis: Mi móvil no cachea el JS. Además si se cachea en cada cliente estás enviando (aunque solo sea una vez) 76kb por X cliente… lo que también significa más pasta al final del mes en la factura de servidor de hosting.

    No es una prohibición, es más bien un toque de atención para hacer las cosas bien, de ahí que haya tengas versiones de Lightbox, cada una más ligera que la anterior…. el tamaño importa.

  • Tu eres tonto. Solo carga el script 1 vez, despues (si tu servidor está bien configurado indica que está cacheado).

    Y si tanto te preocupa el tamaño lo puedes comprimir, mediante compresores de código o gzip si necesitas debuguear. Así puedes comprimirlo a más de la mitad.

    Y si todavía te preocupa, y para ti es «basura» lo que no usas, entonces ELIMÍNALO TÚ MISMO si eres tan listo.

    Vamos que eres un payaso que se monta en la ola del surf-guay con tal de criticar y parecer inteligente. Aprende a programar payaso.

  • @Benja: Si te parece bien, aprenderé de ti ya que argumentas usando la descalificación y la ignoráncia.

    El script se «DESCARGA» 1 sola vez por cada usuario que entra. Si tu aplicación tiene 1000 usuarios únicos se «DESCARGA» 1000 veces. Matemáticas básicas.

    1 x 1000 = 1000
    La x es es el símbolo de multiplicar que es lo mismo que sumar muchas veces otro valor.

    Si lo comprimes consigues paliar el problema, pero ya lo hablamos hace años..

    Como aún me molestaba el tamaño, lo eliminé y pasé a alternativas más eficientes en menor espacio.

    Si tienes algún problema con el cálculo, te puedo recomendar una serie de artículos para niños con deficiencias psíquicas que probablemente te sirva o ayude a que comprendas como funcionan las operaciones básicas de aritmética.

    Para lo de la poca vergüenza, la falta de educación y el vocabulario barrio bajero y soez, no hay solución… te quedarás así de por vida… ya te arrepentirás.

    Espero haberte ayudado en algo, y sino no me preocupa.

    Saludos, espero verte pronto 😉

  • wouu ya empezamos el año.
    saludos

  • Mira que les cuesta pillarlo xD

  • Ah si lo que queria decir es que me parece una mierda que el post se llame «Un mal llamado scriptaculous» y aparezca 2º e si buscas scriptaculous en el google español (aunque eso no sea tu culpa).
    El mal NO es scriptaculous ni prototype, que son un inmenso trabajo y estan muy bien hechos para desarrollar JavaScript de alta calidad, sino los patanes que solo quieren desplegar un div con una animación y no saben nada más del tema. Meh.

  • @benja: Bueno así si podemos debatir algo, pero entrando de primeras ofendiendo al personal no, ni aquí ni en ningún sitio.

    En relación a tu comentario, tienes toda la razón, el problema es que el post es antiguo, y si te fijas verás que hace ya más de 3 años que es escribió y desde entonces han pasado muchas cosas, pero por aquella época estaba de moda y era lo último.

    El post intenta explicar lo pesado que es, pero no para criticarlo sino para concienciar a la gente de que si se usa, sea por que hace falta, no para, como dices, desplegar un div con una animación…

    Luego que cada uno le dé el uso que crea conveniente.

  • jaja impresionante el post, me lo lei de punta a punta, de año a año.

    lamentablemente mis conocimientos son bajisimos en esta materia por lo que no podía aportar nada, y aprendi muchisimo leyendolo.

    Un abrazoo

  • Yo estoy deacuerdo con el artículo. Y alucino con bastantes comentarios.
    Soy desarrolladora, en aplicaciones web y páginas llevo poco tiempo y no es mi especialidad, pero llevo muuuchos años desarrollando aplicaciones cliente-servidor, con grandes bases de datos muy transaccionales.
    Siempre he tenido colaboración estrecha con administradores de sistemas y redes y los últimos 2 años estoy muy metida en temas de QoS y gestores de tráfico, os recomiendo leer al respecto.
    Por experiencia, la optimización de los recursos es fundamental, no se puede dejar de dar importancia a este tema «porque mi servidor lo aguanta» y porque «tengo ancho de banda de sobra».
    Parece que os sobra de todo, pero la tecnología evoluciona muy muy deprisa, y no es posible estar al día si las cosas no se hacen bien desde el principio.
    Como desarrolladora he visto evolucionar muchas aplicaciones de todo tipo y si no os preocupáis por optimizar el rendimiento ahora, después será demasiado tarde porque migrar o rehacer algo que está en producción sin una buena base es un trabajo de titanes.
    Entiendo que es muy cómodo y útil disponer de estas librerías, entiendo que es una suerte que existan todo tipo de herramientas para crear páginas web con pocos o ningún conocimiento técnico, me alucina y me encanta que mi padre con 76 años pueda tener su blog. Pero a nivel profesional hay que currárselo mucho más, si queremos hacer las cosas bien no se puede desarrollar con copy-paste, tampoco en ensamblador, hay que conseguir un equilibrio entre lo bien hecho y lo rentable.
    Yo personalmente soy una desarrolladora orientada al I+D y tengo la suerte de no tener que mirar demasiado la rentabilidad, así que yo no utilizo el código que encuentro en bruto sino que empleo mucho tiempo a estudiar el código y me quedo con la idea para integrar solo lo que me interesa con mis desarrollos.

    Obviamente con la optimización no me refiero únicamente al tamaño del javascript. La optimización hay que buscarla en todo, en el cliente, en el servidor y en la red.

    Andrés, felicidades por tu blog.

Comentar

#

Me reservo el derecho de eliminar y/o modificar los comentarios que contengan lenguaje inapropiado, spam u otras conductas no apropiadas en una comunidad civilizada. Si tu comentario no aparece, puede ser que akismet lo haya capturado, cada día lo reviso y lo coloco en su lugar. Siento las molestias.