optimization - La mayoría de la configuración eficiente de múltiples páginas requiere JS y Almond

seo tags (5)

Tengo varias páginas en un sitio que usa RequireJS, y la mayoría de las páginas tienen una funcionalidad única. Todos ellos comparten una gran cantidad de módulos comunes (jQuery, Backbone y más); todos ellos tienen sus propios módulos únicos, también. Me pregunto cuál es la mejor manera de optimizar este código usando r.js Veo una serie de alternativas sugeridas por diferentes partes de la documentación y ejemplos de RequireJS y Almond, así que se me ocurrió la siguiente lista de posibilidades que veo, y estoy preguntando cuál es la más recomendada (o si hay otra forma mejor) :

Optimice un único archivo JS para todo el sitio , utilizando Almond , que se cargaría una vez y luego se mantendría en la memoria caché. La desventaja de este enfoque más simple es que estaría cargando en cada código de página que el usuario no necesita para esa página (es decir, módulos específicos de otras páginas). Para cada página, el JS cargado sería más grande de lo que necesita ser.
Optimice un solo archivo JS para cada página , que incluiría tanto los módulos comunes como los específicos de la página. De esa forma podría incluir Almond en el archivo de cada página y solo cargaría un archivo JS en cada página, lo que sería significativamente más pequeño que un solo archivo JS para todo el sitio. La desventaja que veo, sin embargo, es que los módulos comunes no se almacenarían en caché en el navegador, ¿verdad? Para cada página que el usuario vaya, tendrá que volver a descargar la mayor parte de jQuery, Backbone, etc. (los módulos comunes), ya que esas bibliotecas constituirían partes grandes de cada archivo JS único de una sola página. (Este parece ser el enfoque del ejemplo de varias páginas de RequireJS , excepto que el ejemplo no usa Almond).
Optimice un archivo JS para módulos comunes, y luego otro para cada página específica . De esta forma, el usuario almacenaría en caché el archivo de los módulos comunes y, al navegar entre las páginas, solo tendría que cargar un pequeño archivo JS específico de la página. Dentro de esta opción, veo dos formas de finalizarlo, para incluir la funcionalidad RequireJS: a. Cargue el archivo require.js antes de los módulos comunes en todas las páginas, utilizando la sintaxis data-main o una etiqueta <script> normal, sin usar Almond. Eso significa que cada página tendrá tres archivos JS: require.js, módulos comunes y módulos específicos de la página. segundo. Parece que esta esencia está sugiriendo un método para conectar Almond en cada archivo optimizado ---- así no tendría que cargar require.js, sino que incluiría Almond tanto en mis módulos comunes como en mis módulos específicos de la página. ¿Está bien? ¿Es eso más eficiente que cargar require.js por adelantado?

Gracias por cualquier consejo que pueda ofrecer sobre la mejor manera de llevarlo a cabo.

Creé un repositorio de ejemplos para demostrar estos 3 tipos de optimización.

Nos puede ayudar a entender mejor cómo usar r.js

https://github.com/cloudchen/requirejs-bundle-examples

Creo que has respondido tu propia pregunta con bastante claridad.

Para la producción, lo hacemos, al igual que la mayoría de las empresas con las que he trabajado con la opción 3 .

Aquí hay ventajas de la solución 3, y por qué creo que debería usarla :

Utiliza la mayoría del almacenamiento en caché , todas las funcionalidades comunes se cargan una vez . Tomando el menor tráfico y generando los tiempos de carga más rápidos al navegar por varias páginas. Los tiempos de carga de varias páginas son importantes y, si bien el tráfico de su parte puede no ser significativo en comparación con otros recursos que está cargando, los clientes realmente apreciarán los tiempos de carga más rápidos.
Es el más lógico, ya que comúnmente la mayoría de los archivos en el sitio comparten una funcionalidad común.

Aquí hay una ventaja interesante para la solución 2:

Envía la menor cantidad de datos a cada página. Si muchos de sus visitantes son una vez, por ejemplo en una página de inicio, esta es su mejor opción. Los tiempos de carga no pueden sobreestimarse en importancia en escenarios orientados a la conversión.
¿Tus visitantes repiten? algunos estudios sugieren que el 40% de los visitantes vienen con un caché vacío.

Otras Consideraciones:

Si la mayoría de sus visitantes visita una sola página, considere la opción 2. La opción 3 es ideal para sitios donde los usuarios promedio visitan varias páginas, pero si el usuario visita una página y eso es todo lo que ve, esa es su mejor opción.
Si tienes mucho JavaScript Considere cargar algo para dar al usuario una indicación visual, y luego cargar el resto de forma diferida de forma asincrónica (con la inyección de etiquetas de secuencia de comandos, o directamente con require si ya lo está usando). El umbral para que las personas noten que algo es "torpe" en la interfaz de usuario suele ser de unos 100 ms. Un ejemplo de esto es ''loading ...'' de GMail.
Dado que las conexiones HTTP son Keep-Alive por defecto en HTTP / 1.1 o con un encabezado adicional en HTTP / 1.0, el envío de múltiples archivos es un problema menor que hace 5-10 años. Asegúrese de enviar el encabezado Keep-Alive desde su servidor para clientes HTTP / 1.0.

Algunos consejos generales y material de lectura:

La minificación de JavaScript es imprescindible, r.js por ejemplo lo hace muy bien y tu proceso de pensamiento al usarlo fue correcto. r.js también combines JavaScript, que es un paso en la dirección correcta.
Como sugerí, el defering JavaScript también es muy importante y puede mejorar drásticamente los tiempos de carga. La ejecución diferida ayudará a que su tiempo de carga se vea rápido, lo cual es muy importante, mucho más importante en algunos escenarios que realmente cargar rápidamente.
Cualquier cosa que pueda cargar desde un CDN, como recursos externos, debe cargar desde un CDN. Algunas bibliotecas que las personas usan hoy en día como jQuery son bonitas (80kb), y obtenerlas de un caché realmente podría beneficiarlo. En su ejemplo, no cargaría Backbone, guión bajo y jQuery de su sitio, sino que los cargaría desde un CDN.

FYI, prefiero usar la opción 3, siguiendo el ejemplo en https://github.com/requirejs/example-multipage-shim

No estoy seguro de si es el más eficiente.

Sin embargo, me parece conveniente porque:

Solo necesita configurar require.config (en las distintas bibliotecas en un solo lugar)
Durante la optimización de r.js, decida cuáles son los módulos para agrupar como comunes

Prefiero usar la opción 3, y seguramente puedo decirte que por qué es eso.

Es lo más lógico
Utiliza la mayoría del almacenamiento en caché, todas las funcionalidades comunes se cargan una vez. Tomando el menor tráfico y generando los tiempos de carga más rápidos al navegar por varias páginas. Los tiempos de carga de varias páginas son importantes y, si bien el tráfico de su parte puede no ser significativo en comparación con otros recursos que está cargando, los clientes realmente apreciarán los tiempos de carga más rápidos.

He enumerado opciones mucho mejores para el mismo.

Puede usar cualquier red de entrega de contenido (CDN) como MaxCDN para garantizar que sus archivos js sean servidos a todos. También le sugiero que ponga sus archivos js en el pie de página de su código html. Espero que ayude.