Должен ли я вставлять файлы CSS/JavaScript в веб-приложение?

3

Конечно, если кто-то, кто знал, что они делали, мог использовать сборщик Reflector и извлечь JS или CSS. Но это было бы намного больше, чем просто использовать что-то вроде FireBug, чтобы получить эту информацию. У обычного конечного пользователя вряд ли будет желание пойти на все эти проблемы, чтобы испортить ресурсы. Любой, кто интересуется этим типом вещей, скорее всего, будет злонамеренным пользователем, а не конечным пользователем. Вероятно, у вас есть много других проблем в отношении безопасности, если пользователь может использовать такой инструмент, как сборщик рефлектора в вашей DLL, потому что к тому моменту ваш сервер уже скомпрометирован. Безопасность не была фактором моего решения о внедрении ресурсов.

Суть заключалась в том, чтобы заставить пользователей делать что-то глупое с этими ресурсами, например, удалять их, думая, что они не нужны или каким-либо иным образом мешают им.

Также намного проще упаковать приложение для целей развертывания, поскольку в нем задействовано меньше файлов.

Верно, что библиотека DLL (библиотека классов), используемая страницами, больше, но это не делает страницы более крупными. ASP.NET создает контент, который необходимо отправить клиенту (браузеру). Клиенту больше не отправляется контент, чем требуется для работы страницы. Я не вижу, как библиотека классов, помогающая обслуживать эти страницы, будет иметь какое-то влияние на размер данных, отправляемых между клиентом и сервером.

Однако у Rjlopes есть точка, правда, браузер не может кэшировать встроенные ресурсы JavaScript/CSS. Я должен проверить это, но я подозреваю, что Rjlopes прав: файлы JavaScript/CSS нужно будет загружать каждый раз, когда на сервер отправляется полноформатная обратная передача. Если это окажется правдой, этот удар производительности должен стать фактором вашего решения.

Я все еще не смог проверить различия в производительности между использованием встроенных ресурсов, перепродажи и отдельных файлов, потому что я был занят своими усилиями. Надеюсь, сегодня я займусь этим, потому что мне очень любопытно, и точка кеширования браузера Rjlopes поднялась.

источник

2009-07-28 13:51:24 Frinavale

+1

Меня очень интересует проблема с кешем. Я не могу себе представить, что они не будут использовать согласованные URL-адреса, чтобы браузер мог кэшировать файл. –

+2

Встраиваемые JS-файлы, созданные через ScriptManager, действительно кэшируются и используют согласованные URL-адреса для всего приложения. Мы используем его довольно успешно на нескольких клиентских сайтах. –

+0

Благодарим вас за обновление Zhaph. Вы случайно не знаете, относится ли это к методу Page.ClientScript.GetWebResourceUrl? – Frinavale

1

Причина для внедрения: Браузеры не загружают файлы JavaScript параллельно. У вас есть условие блокировки, пока файл не будет загружен.

Причина против внедрения: Вам может не понадобиться весь код JavaScript. Таким образом, вы можете увеличить пропускную способность/обработку без необходимости.

источник

2009-07-27 20:16:14 easement

+0

cuzillion (http://stevesouders.com/cuzillion/) может показать вам, как каждый встроенный/встроенный выбор и размещение на странице могут повлиять на общее время загрузки страницы. – easement

+0

@easement, это интересная страница, но она кажется немного надуманной. Добавляя внешнюю таблицу стилей, она сообщает вам, что она добавит 2-секундную задержку, которая кажется произвольной. И, похоже, это не затрагивает идею встроенных ресурсов. –

+1

Некоторые браузеры восстанавливаются параллельно, не так ли? Или, по крайней мере, я думаю, вы можете сказать, что Firefox это делает. Когда вы вставляете их, имеет ли он только одну ссылку, независимо от того, сколько файлов вы вставляете? если бы я не думал, что это будет иметь большое значение. –

4

Я должен был принять такое же решение один раз. Причина, по которой я решил внедрить свои ресурсы JavaScript/CSS в свою DLL, заключалась в том, чтобы предотвратить несанкционированное использование этих файлов (любопытными конечными пользователями, купившими мое веб-приложение) после развертывания приложения.

Я сомневаюсь и ставил под сомнение достоверность комментария Easement о том, как браузеры загружают файлы JavaScript. Я уверен, что встроенные файлы JavaScript/CSS временно воссоздаются ASP.NET до того, как страница будет отправлена в браузер, чтобы браузер мог загружать и использовать их. Мне это интересно, и я буду запускать собственные тесты. Я дам вам знать, как она идет ....

-Frinny

источник

2009-07-27 21:10:42 Frinavale

-1

Вы знаете, что если кто-то хочет, чтобы подделать ваш JS или CSS, они просто должны открыть сборку с отражателем, перейдите к ресурсам и отредактируйте то, что они хотят (возможно, требуется гораздо больше работы, если сборки подписаны).

Если вы вставляете js и css на страницу, вы делаете страницу более крупной (больше KB для загрузки по каждому запросу), и браузер не может кэшировать JS и CSS для следующих запросов. Хорошей новостью является то, что у вас меньше запросов (по крайней мере, 2, если вы похожи на меня и объединяете несколько js и css и один), плюс javascripts имеют проблемы с загрузкой серийно.

источник

2009-07-27 22:11:24 rjlopes

1

Что касается кеша браузера, насколько я заметил, ответ на WebRecource.axd говорит, что «304 не изменен». Итак, я думаю, они были взяты из кеша.

источник

2013-10-03 13:03:53 Arthur

1

Я должен был принять такое же решение один раз. Причина, по которой я решил внедрить свои ресурсы JavaScript/CSS в свою DLL, заключалась в том, чтобы предотвратить несанкционированное использование этих файлов (любопытными конечными пользователями, купившими мое веб-приложение) после развертывания приложения. Причина против внедрения: вам может не понадобиться весь код JavaScript. Таким образом, вы можете увеличить пропускную способность/обработку без необходимости.

источник

2013-10-03 13:06:14 user2721863

Должен ли я вставлять файлы CSS/JavaScript в веб-приложение?

ответ

Смежные вопросы