2009-07-27 15 views
6

Recientemente he comenzado a incrustar archivos JavaScript y CSS en nuestras DLL de biblioteca comunes para simplificar mucho más la implementación y el control de versiones. Me preguntaba si hay alguna razón para querer hacer lo mismo con una aplicación web, o si siempre es mejor dejarlos como archivos regulares en la aplicación web, y solo usar recursos integrados para componentes compartidos.¿Debo incrustar archivos CSS/JavaScript en una aplicación web?

¿Habría alguna ventaja al insertarlos?

+0

ver [aquí] (http://stackoverflow.com/a/40399162/5137413) para la solución Espero que este sulotion le ayude –

Respuesta

3

Por supuesto, si alguien que supiera lo que estaban haciendo podría utilizar el ensamblado Reflector y extraer el JS o CSS. Pero eso sería muchísimo más trabajo que solo usar algo como FireBug para obtener esta información. Es improbable que un usuario final habitual tenga el deseo de resolver todos estos problemas solo para desordenar los recursos. Cualquiera que esté interesado en este tipo de cosas es probable que sea un usuario malintencionado, no el usuario final. Probablemente tenga muchos otros problemas con respecto a la seguridad si un usuario puede usar una herramienta como el reflector de ensamblaje en su DLL porque para ese punto su servidor ya se ha visto comprometido. La seguridad no fue el factor en mi decisión de incorporar los recursos.

El objetivo era evitar que los usuarios hicieran algo tonto con estos recursos, como eliminarlos pensando que no son necesarios o manipularlos de otro modo.

También es mucho más fácil empaquetar la aplicación para fines de implementación porque hay menos archivos involucrados.

Es cierto que la DLL (biblioteca de clases) utilizada por las páginas es más grande, pero esto no aumenta las páginas. ASP.NET genera el contenido que debe enviarse al cliente (el navegador). No se envía más contenido al cliente de lo que se necesita para que la página funcione. No veo cómo la biblioteca de la clase que ayuda a publicar estas páginas tendrá ningún efecto sobre el tamaño de los datos que se envían entre el cliente y el servidor.

Sin embargo, Rjlopes tiene un punto, podría ser cierto que el navegador no puede almacenar en caché recursos de JavaScript/CSS incorporados. Tendré que verificarlo, pero sospecho que Rjlopes es correcto: los archivos JavaScript/CSS deberán descargarse cada vez que se realice una devolución de datos de página completa en el servidor. Si esto resulta ser cierto, este impacto en el rendimiento debería ser un factor en su decisión.

Todavía no he podido probar las diferencias de rendimiento entre el uso de recursos incrustados, el resex y archivos individuales porque he estado ocupado con mis esfuerzos. Espero poder acceder a él más tarde porque tengo mucha curiosidad y el punto de almacenamiento en caché del navegador Rjlopes ha surgido.

+1

Estoy muy interesado en el problema del caché. No puedo imaginar que no usarían URL consistentes para permitir que el navegador guarde en caché el archivo. –

+2

Los archivos JS incrustados que se procesan a través de un ScriptManager están en la memoria caché y utilizan URL consistentes en toda la aplicación. Lo estamos utilizando con bastante éxito en un par de sitios de clientes. –

+0

Gracias por la actualización Zhaph. ¿Sabes por casualidad si se aplica lo mismo al método Page.ClientScript.GetWebResourceUrl? – Frinavale

1

Motivo de inclusión: los navegadores no descargan archivos JavaScript en paralelo. Tiene una condición de bloqueo hasta que se descarga el archivo.

Razón contra la incrustación: es posible que no necesite todo el código JavaScript. Por lo tanto, podría aumentar el ancho de banda/procesamiento innecesariamente.

+0

cuzillion (http://stevesouders.com/cuzillion/) puede mostrarle cómo cada línea/La elección y la ubicación integradas en la página pueden afectar los tiempos generales de carga de la página. – easement

+0

@easement, esa es una página interesante, pero parece un poco artificial. Al agregar una hoja de estilo externa, te dice que va a agregar un retraso de 2 segundos, lo que parece arbitrario. Y no parece abordar la idea de los recursos integrados. –

+1

Algunos buscadores recuperan en paralelo, ¿no? O al menos creo que puedes decirle a Firefox que lo haga. Cuando los incrusta, ¿solo tiene un enlace, sin importar cuántos archivos haya incrustado? si no, no pensaría que eso haría mucha diferencia. –

4

Tuve que tomar esta misma decisión una vez. La razón por la que elegí incrustar mis recursos de JavaScript/CSS en mi archivo DLL fue para evitar la manipulación de estos archivos (por los usuarios finales curiosos que compraron mi aplicación web) una vez que la aplicación se implementó.

Dudo y cuestiono la validez del comentario de Easement acerca de cómo los navegadores descargan archivos JavaScript. Estoy bastante seguro de que los archivos JavaScript/CSS incorporados son recreados temporalmente por ASP.NET antes de que la página se envíe al navegador para que el navegador pueda descargarlos y usarlos. Tengo curiosidad por esto y voy a hacer mis propias pruebas. Te dejaré saber cómo se va ....

-Frinny

-1

Usted saber que si alguien quiere alterar sus JS o CSS sólo tienen que abrir el conjunto con reflector, ir a la página de Recursos y edite lo que quiera (probablemente lleve mucho más trabajo si los ensamblajes están firmados).

Si inserta el js y el css en la página, la página se agranda (hay más KB para descargar en cada solicitud) y el navegador no puede almacenar en caché el JS y CSS para las siguientes solicitudes. La buena noticia es que tiene menos solicitudes (al menos 2 si es como yo y combina varios js y css y uno), además los javascripts tienen el problema de ser descargados en serie.

1

En cuanto a la memoria caché del navegador, por lo que he notado, la respuesta en WebRecource.axd dice "304 no modificado". Entonces, supongo, se tomaron de la memoria caché.

1

Tuve que tomar la misma decisión una vez. La razón por la que elegí incrustar mis recursos de JavaScript/CSS en mi archivo DLL fue para evitar la manipulación de estos archivos (por los usuarios finales curiosos que compraron mi aplicación web) una vez que la aplicación se implementó. Motivo contra la incrustación: es posible que no necesite todo el código JavaScript. Por lo tanto, podría aumentar el ancho de banda/procesamiento innecesariamente.

Cuestiones relacionadas