Лучше поместить код JS в HTML-файл или во внешний файл?


16

Если я разрабатываю одностраничный веб-сайт, лучше ли создавать внешний файл для моего JS-кода или просто поместить его в HTML-код? Быстро ли загружать его на страницу? Могу ли я изменить разрешения, чтобы запретить запросы пользователей на код, но HTML-страница все еще может вызывать код?

Ответы:


26

Вы должны поместить свой код JS в отдельный файл, потому что это облегчает тестирование и разработку. Вопрос о том, как вы обслуживаете код, это другой вопрос.

  • Обслуживание HTML и JS по отдельности имеет то преимущество, что клиент может кэшировать JS. Для этого необходимо отправить соответствующие заголовки, чтобы клиент не выдавал новый запрос каждый раз. Кэширование проблематично, если вы хотите выполнить обновление и, таким образом, хотите аннулировать клиентские кэши. Одним из способов является включение номера версии в имя файла, например /static/mylibrary-1.12.2.js.

    Если JS находится в отдельном файле, вы не можете ограничить доступ к нему: трудно (технически: невозможно) определить, был ли сделан запрос к файлу JS, потому что вы ссылались на него на своей HTML-странице или потому, что кто-то хочет его скачать непосредственно. Однако вы можете использовать куки и отказываться обслуживать клиентов, которые не передают определенные куки (но это было бы глупо).

  • Обслуживание JS внутри HTML увеличивает размер каждой страницы - но это нормально, если клиент вряд ли будет просматривать несколько страниц. Поскольку клиент не выдает отдельный запрос для JS, эта стратегия загружает страницу быстрее - по крайней мере, впервые, но есть точка безубыточности, где кэширование лучше. Вы можете включить JS, например, через PHP.

    Здесь клиенту не требуется отдельный доступ к файлу JS, который может быть скрыт, если хотите. Но любой по-прежнему может просматривать код JS внутри HTML.

Другие стратегии минимизации времени загрузки включают

  • Минификация JS, которая уменьшает размер обслуживаемого вами файла JS. Поскольку минимизация происходит только один раз при развертывании кода, это очень эффективный способ сохранения байтов. Это делает ваш код сложнее для понимания заинтересованными посетителями.

    С минификацией связана практика объединения всех ваших файлов JS в один файл. Это уменьшает количество необходимых запросов.

  • Сжатие, которое добавляет вычислительные затраты для каждого запроса как на клиенте, так и на сервере. Однако время, потраченное (распаковывание), обычно меньше, чем время, потраченное на передачу несжатых данных. Сжатие обычно прозрачно обрабатывается серверным программным обеспечением.

Эти методы также применяются к другим ресурсам, таким как изображения.

  • Изображения могут быть встроены в HTML или CSS с URL-адресами данных. Это практично только для небольших простых изображений, так как кодировка base64 увеличивает размер. Это все еще может быть быстрее, чем другой запрос.
  • Несколько небольших изображений (значки, кнопки) могут быть объединены в одно изображение, а затем извлечены в виде спрайтов.
  • Изображения могут быть уменьшены сервером до размера, в котором они фактически используются на веб-сайте, что экономит трафик. Сравните миниатюры изображений.
  • Для некоторых графических изображений текстовые изображения, такие как SVG, могут быть намного меньше.

«Легче тестировать и разрабатывать», я не уверен, что всегда полезно иметь JS в своем собственном файле для этой цели. В одном проекте я использую очень маленькие HTML-файлы, и на самом деле они более организованы, чтобы включать их в HTML. Что касается кэширования, оно может повысить скорость при нескольких посещениях (возможно), но для загрузки первой страницы всегда будет быстрее включить javascript непосредственно в HTML.
Юнгган

5

Я разрабатываю одностраничный сайт

Если у вас буквально просто одна страница, то да, лучше (с точки зрения производительности) обслуживать все в одном файле ... таблицы стилей, JavaScript и даже изображения (небольшие изображения, встроенные в data-URI). Это исключает дополнительные HTTP-запросы, необходимые для извлечения внешних ресурсов, которые являются относительно медленными.

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

Вам все равно следует подумать о том, чтобы иметь большие изображения, внешние по отношению к странице, поскольку существуют ограничения по размеру URI данных и совместимости с браузером. (Например, IE8 имеет ограничение 32 КБ, что соответствует фактическому размеру файла около 23 КБ из-за характера кодирования base64.)

Могу ли я изменить разрешения, чтобы запретить запросы пользователей на код, но HTML-страница все еще может вызывать код?

Нет. В лучшем случае код можно запутать, чтобы «спрятать» его от случайного наблюдателя, но он не обеспечивает реальной защиты.


1
Почему голосование "за"? В то время как для разработки и многостраничных сайтов лучше иметь отдельные / внешние файлы, OP в этом случае специально задает вопрос об «одностраничном веб-сайте» и о том, «быстрее ли он загружается». Минимизация HTTP-запросов должна быть приоритетом в этом случае. Вы можете (и должны) по-прежнему разрабатывать несколько файлов, но это не тот вопрос, который задают.
MrWhite

Поместив js, css и изображения в отдельные файлы, вы разрешаете браузеру кэшировать файлы. Таким образом, если содержимое страницы изменится, только HTML должен быть перезагружен.
Тьерри Дж

@ThierryJ. Хорошо, вы можете кэшировать файлы, но при загрузке первой страницы (что очень важно для привлечения новых пользователей) все еще намного быстрее включить все файлы, поскольку кэширование не действует. Кроме того, компьютер все еще должен загрузить кэшированный файл, этот шаг полностью пропускается, если вы включаете файл в HTML. Вероятно, будет быстрее, если сначала включить файл в HTML почти во всех случаях. В любом случае вам придется перезагрузить HTML, а часть javascript не может быть больше ста кБ, это незначительно.
Юнгган

4

Код JS на стороне клиента должен просматриваться браузером (то есть, если страница должна использовать JS напрямую) - это означает, что он должен быть загружен браузером.

Вы не можете использовать браузер JS на странице, если он не может загрузить его.

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

Если у вас есть код, который вы не хотите показывать в браузере, вам нужно будет использовать код на стороне сервера (скажем, node.js, php, perl, asp.net, jsp - вариантов так много) и взаимодействовать с ним из браузера - либо при начальной загрузке страницы, либо с помощью AJAX .


2

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

Хотя это не то, чем я бы занимался сам, и если вы хотите узнать лучшие практики разработки программного обеспечения, я настоятельно советую вам записать все во внешний *.jsфайл и загрузить его с помощью <script>тегов.

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


1

лучше создать внешний файл для моего кода JS, или просто поместить его в код HTML?

Лучше создать внешний файл для вашего кода JS. Также лучше иметь один или два файла, которые вы обслуживаете клиенту. Но лучше также разбить ваш код JS на несколько файлов для обеспечения удобства обслуживания. Чтобы сделать это, вы можете использовать препроцессоры, такие как Gulp, которые будут объединять ваши различные файлы JS в один файл.

Лучше обслуживать меньше файлов, так как клиент будет обрабатывать меньше HTTP-запросов.

Быстро ли загружать его на страницу?

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

Могу ли я изменить разрешения, чтобы запретить запросы пользователей на код, но HTML-страница все еще может вызывать код?

Нет, ты не можешь. JS-код, как CSS-код и HTML-код, является статическим содержимым. Это означает, что, как только он появится в браузере, клиент может полностью загрузить его и его содержимое. Каждый файл, изображение, скрипт открыт для скачивания. Но вы можете уменьшить / уменьшить ваш код, чтобы человеку было труднее его использовать. Это только следствие углификации, которая была сделана для производительности в первую очередь.


0

Многие преимущества разделения содержимого html и javascript на отдельные файлы:

  • повышает читаемость отдельных файлов курса
  • так как код javascript больше не ограничен html-файлом, другие html и javascript-файлы или библиотеки могут использовать ваш javascript-код
  • аналогичным образом код JavaScript, помещенный в отдельный файл, может легко использовать другие файлы и расширенные библиотеки для выполнения сложных вычислений (машинное обучение, трехмерная графика, фреймворк и т. д. библиотеки)
  • javascript может быть кэширован на стороне клиента, и при этом необходимо обновить только HTML-контент при обновлении страницы.
  • Хорошие / современные методы разработки программного обеспечения могут быть легко применены к отдельному файлу / модулю / библиотеке javascript (шаблоны проектирования, чтение о машинописи / babel и т. д.)
  • javascript-код может быть легко запутан или «скрыт» от посетителей веб-страницы путем минимизации / увеличения
  • javascript-файлы могут быть объединены в один файл / модуль через gulp, webpack и т. д.

1
кажется, это не дает ничего существенного по сравнению с замечаниями, сделанными и объясненными в предыдущих 6 ответах
комнат
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.