2009-07-28 23 views

Respuesta

14

(Descargo de responsabilidad: soy desarrollador de Dojo y esta es mi perspectiva no oficial).

Todas las bibliotecas principales se pueden utilizar en escenarios de carga elevada. Hay varias cosas a considerar:

carga inicial

La carga inicial afecta a su tiempo de respuesta: desde solicitar una página Web para ser sensible y en el modo de trabajo. cosas triviales que hacer son:

  • concatenar varios archivos JavaScript juntos (que funciona para archivos CSS también)
  • minimizar y/o comprimir el JavaScript

La idea es enviar menos — bueno para el servidor, y bueno para el cliente.

La cosa menos trivial hacer:

  • estructura su programa de tal manera por lo que es operacional sin todos los módulos cargados

ejemplo de este último: dividir sus módulos en esencial (por ejemplo, , la lógica del núcleo), y no esencial (por ejemplo, ayudantes: información sobre herramientas, consejos, verificadores, facilidades de ayuda, varios "potenciadores graduales", etc.). La idea es que con frecuencia hay cosas que no son importantes para usuarios frecuentes, pero agradables para usuarios ocasionales ⇒ que pueden retrasarse.

Podemos cargar primero los módulos esenciales y cargar el resto de forma asíncrona. Ejemplo: si el usuario quiere editar un objeto, primero tenemos que mostrarlo, después de eso tenemos varios cientos de milisegundos para cargar el resto: tablas de búsqueda, sugerencias, etc.

Obviamente, ayuda cuando la carga asíncrona de los módulos es compatible con el marco que utiliza. Dojo tiene esta facilidad incorporada.

distribuir archivos

Todo el mundo sabe que, debido a las restricciones del explorador en número de descargas paralelas desde el mismo sitio que es beneficioso para cargar recursos (imágenes, CSS, JavaScript) de diferentes dominios:

  • podemos descargar más en paralelo, si la línea del usuario tiene suficiente ancho de banda — en estos días es casi siempre cierto
  • podemos configurar servidores web optimizados para servir archivos estáticos: gran caché de disco, pequeño w os trabajadores, keep-alive, asíncrono de servir, y así sucesivamente
  • podemos eliminar todas las características innecesarias que no necesitamos al servir archivos estáticos: sesiones, cookies, etc.

Uno frecuentemente pasado por alto la optimización en JavaScript aplicaciones es utilizar CDN:

  • su sitio web puede beneficiarse de la distribución geográfica de CDN (archivos pueden ser servidos desde el servidor más cercano/más rápido)
  • usuario puede haber requerido archivos en su caché, si fueran utilizado por otra aplicación
  • cachés intermedias/corporativa aumentan la probabilidad de que necesitan los archivos se almacenan en caché ya
  • el último pero no menos importante: se trata de archivos que no sirven — pensar en ello

Una vez más, Dojo soporta CDN para un largo tiempo y distribuido públicamente por AOL CDN y Google CDN. Este último lleva prácticamente todos los kits de herramientas de JavaScript populares también. Obviamente, puedes crear tu propia CDN y tu propia compilación de Dojo específica para CDN y aplicaciones, si crees que la necesitas — es trivial y está bien documentada.

ancho de banda de comunicación

cómo puede ser diferente para diferentes conjuntos de herramientas? XHR es XHR.

Debe reducir la carga en sus servidores tanto como sea posible. Analice todo el tráfico y tenga en cuenta la cantidad de material estático/inmutable que se envía a través de la tubería. Por ejemplo, generalmente una gran cantidad de HTML es redundante en varias páginas: un encabezado, un pie de página, un menú, etc. ¿De verdad necesitas que te enviemos todo esto todo el tiempo?

Una solución obvia es pasar de HTML + "mejoras graduales" estáticas con JavaScript a aplicaciones de JavaScript de "una página" reales. Nuevamente, esta es una optimización frecuentemente olvidada, pero la más gratificante.

Si bien la idea suena fácil, en realidad no es tan simple como parece. Tan pronto como pasamos de una línea a aplicaciones, tenemos una plétora de preguntas, y la mayor de ellas es el empaquetado: cuáles son sus componentes, qué componentes proporciona el kit de herramientas y cómo empaquetarlos y entregarlos.

Dojo proporciona módulos, buen OOP para clases generales, widgets (una combinación de un HTML opcional y comportamientos relacionados), y un montón de instalaciones para trabajar con ellos.Puede:

módulos de carga
  • sobre la demanda en lugar de en la cabeza
  • módulos de carga
  • asíncrona
  • encontrar todas las dependencias entre los módulos de forma automática y crear un "construir" — un archivo en casos sencillos, o más, si su aplicación es grande y requiere varias capas
  • mientras se hace la "construcción" que puede inline todos los fragmentos de HTML para sus widgets, optimizar CSS y minify/comprimir JavaScript
  • Dojo puede encontrar y crear instancias de los widgets en HTML ahorrando mucho automáticamente de repetición código
  • y mucho más

Todas estas características ayudan en gran medida en la construcción de aplicaciones en el lado del cliente. That's why I like Dojo.

Obviamente, hay más formas de optimizar los sitios web de alta carga pero, según mi práctica, estos son los más específicos para los marcos de JavaScript.

0

Bueno, como un ejemplo de stackoverflow se basa en jQuery (y utiliza el enlace de google apis) - es una de las bibliotecas más rápidas y populares, y no solo eso, pero diría que es la más fácil de usar. ¿Qué tipo de comportamiento vas a tener en el sitio? Realmente todo depende de sus necesidades de.

11

En pocas palabras: todos ellos.

Todos los marcos se han construido con el fin de proporcionar el rendimiento más rápido posible y proporcionar a los desarrolladores funciones y herramientas útiles. Su elección debe basarse en sus requisitos.

JavaScript se ejecuta en el lado del cliente, por lo que ninguno afectará el rendimiento de su servidor. La única diferencia del lado del servidor es la cantidad de ancho de banda utilizado para transferir los archivos .js al cliente.

Me gusta personalmente MooTools porque responde a mis requisitos y también se adhiere a mis ideales de codificación. Mucha gente adoptó jQuery (personalmente no me gusta, no significa que no sea genial). No he usado los otros.

Pero ninguno es mejor que el otro, es todo una cuestión de requisitos y preferencia personal.

+1

+1 me lo ganaste. la información clave que falta en la pregunta es qué se entiende por alto rendimiento. tiempo de carga inicial rápido? colores bonitos? posibilidad de mostrar películas en tiempo real a un tamaño de píxel de 10000x10000? en la mayoría de los casos (excepto el tiempo de carga inicial), el cuello de botella será el servidor o el ancho de banda, no el cliente. –

+0

No todos los marcos son iguales en velocidad. Algunos son intrínsecamente más lentos que otros debido a diferencias arquitectónicas. Taskspeed, aunque es un tanto artificial e inconsistente, demuestra estas diferencias con claridad. – kangax

0

La respuesta, como siempre, es: depende. ¿De qué tipo de actuación estás hablando? ¿Velocidad de Descarga? Use un minimizador y probablemente no haya mucha diferencia. ¿O rendimiento del lado del cliente, y qué estás haciendo con eso?

Pero, yo sugeriría que si buscas rendimiento en bruto, no utilizaría un framework en absoluto, y crear javascript de bajo nivel que será mucho más difícil de mantener.

Alguna buena información se puede encontrar en el YUI site.

1

Realmente no creo que marque la diferencia. Los grandes parecen usar una mezcla del prototipo Jquery & junto con otros.

Francamente, no importa qué uses para sitios web muy visitados ya que estamos hablando de tecnologías de clientes. Después de cargar el archivo, en realidad no hay gastos generales. Entonces, si solo quiere hacer una cosa simple y múltiples frameworks lo soportan, use cualquiera que tenga el tamaño de archivo más pequeño (por supuesto, si funciona realmente mal, use otro!)

Dicho esto, google aloja una muchos de los marcos, por lo que incluso esto no es un problema. Uso Jquery alojado por Google y estoy muy contento.

http://code.google.com/apis/ajaxlibs/

backend y lo que el servidor debe utilizar es una cuestión totalmente diferente, donde obtendrá un millar de respuestas diferentes!

0

Como ya se han explicado otras respuestas, el marco no será el cuello de botella en el rendimiento de su sitio, sino muchos otros factores.Si usa marcos populares y los carga de URL populares para ellos (por ejemplo, AOL o Google), es probable que se almacenen en caché en los navegadores de los usuarios, por lo que no tiene que preocuparse demasiado por eso.

Sin embargo, si le preocupa el rendimiento, NO DEBE pasar por alto el trabajo Steve Souders;, incluidos sus dos libros, "Sitios web de alto rendimiento" y "Sitios web aún más rápidos".

soy parcial, ya que Steve es un amigo y un colega (y que comparten los editores también), pero alabé y admiraba su trabajo, incluso antes de nos encontramos en persona y se convirtió colegas - Lo que más me una persona de back-end, como solía serlo, así que no puedo dejar de admirar a alguien que, viniendo del mismo origen, tuvo la integridad y el coraje de cambiar casi por completo al enfoque de front-end cuando se dio cuenta de que ESO era de lejos el cuello de botella para el rendimiento percibido por el usuario (es decir, alguien que tuvo el impulso de poner la experiencia del usuario primero, algo por lo que todos rendimos homenaje, por supuesto, pero no lo haga siempre que entre en esa "prioridad prioritaria" el camino de nuestras propias especialidades profesionales, intereses y habilidades ...).

1

Te recomiendo que busques en Dojo. Dojo 1.6 es también la primera (y única) biblioteca de JavaScript popular que se puede utilizar con éxito con el modo avanzado del compilador de cierre, con los enormes beneficios de tamaño, rendimiento y ofuscación asociados, además de la propia Biblioteca de cierre de Google. es decir.

http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t

En otras palabras, un programa usando Dojo puede ser 100% ofuscado - incluso la propia biblioteca.

El código compilado tiene exactamente el mismo comportamiento que el código de texto sin formato, excepto que es mucho más pequeño (promedio 25% sobre minificadores), funciona mucho más rápido (especialmente en dispositivos móviles) y casi imposible después de pasar por un embellecedor, porque la base de código completa (incluida la biblioteca) está ofuscada.

El código que solo se "minifica" (por ejemplo, el compresor YUI, Uglify) se puede modificar mediante ingeniería inversa fácilmente después de atravesar un embellecedor.

Cuestiones relacionadas