Які плюси та мінуси: покласти javascript в голову та покласти безпосередньо перед тілом


87

У більшості книг / статей про javascript та веб-розробку сказано, що ви повинні помістити CSS у тег head та javascript внизу сторінки.

Але коли я відкриваю html джерело відомих веб-сайтів, таких як цей stackoverflow, я виявляю, що вони поміщають деякі js-файли в тег head.

Які плюси і мінуси обох підходів і коли використовувати який?

Знайшов ще одне запитання до тієї ж проблеми: Де мені оголосити файли JavaScript, що використовуються на моїй сторінці? У <head> </head> чи поблизу </body>?



Відповіді:


63

З найкращих практик Yahoo щодо прискорення роботи вашого веб-сайту :

Проблема, спричинена сценаріями, полягає в тому, що вони блокують паралельні завантаження. Специфікація HTTP / 1.1 передбачає, що браузери завантажують не більше двох компонентів паралельно на одне ім’я хосту. Якщо ви подаєте свої зображення з декількох імен хостів, ви можете отримати більше двох завантажень, які відбуватимуться паралельно. Поки скрипт завантажується, однак браузер не запускає жодних інших завантажень, навіть з різними іменами хостів.

У деяких ситуаціях нелегко перемістити сценарії внизу. Якщо, наприклад, сценарій використовує document.write для вставки частини вмісту сторінки, його не можна перемістити нижче на сторінці. Також можуть бути проблеми з обсягом. У багатьох випадках існують способи вирішення цих ситуацій.

Альтернативна пропозиція, яка часто виникає, - використовувати відкладені сценарії. Атрибут DEFER вказує, що скрипт не містить document.write, і є підказкою для браузерів, що вони можуть продовжувати візуалізацію. На жаль, Firefox не підтримує атрибут DEFER. В Internet Explorer сценарій може бути відкладений, але не стільки, скільки бажано. Якщо сценарій можна відкласти, його також можна перемістити в нижню частину сторінки. Це зробить ваші веб-сторінки швидшими.

Тому загалом переважно ставити їх внизу. Однак, це не завжди можливо, і це часто не роблять , що особливої різниці в будь-якому випадку.


У мене є приклад, який переміщує квадрат навколо на полотні, і це не буде працювати, якщо я розміщу javascript у головній частині HTML. Після оголошення полотна воно повинно знаходитися внизу тіла. Чи є для цього причина, або як я можу зберегти весь свій Javascript у розділі <head> файлу.
Doug Hauf

@DougHauf Не впевнений, чи точно я це знаю, але чи додали ви слухача DOMContentLoaded? Я запитую, тому що якщо у вас є ваш сценарій внизу, і він відображається на полотні просто чудово; це тому, що полотно вже було завантажено на екран, перш ніж ви спробували написати на ньому. Тепер, якщо ви помістите сценарій у заголовок, він не буде звертатися до полотна, оскільки полотна ще немає. Отже, якщо ви додасте слухач, він запустить ваш код полотна ПІСЛЯ завантаження полотна.
Matthew D Auld

1
Я не знаю, скільки років документу, який ви цитуєте, але, схоже, атрибут defer підтримується у Firefox вже досить давно .
user2428118

Дякую, це мені дуже
допомогло

31

Як казали інші люди, коли ви поміщаєте javascript в голову, це затримує візуалізацію сторінки до завантаження сценаріїв, а це означає, що завантаження сторінки може зайняти більше часу, особливо якщо ви завантажуєте великі файли скриптів.

Якщо ви перемістите теги сценарію в кінець сторінки, ви забезпечите, щоб браузер завантажував зображення та таблиці стилів до тегів сценаріїв, і сторінка, швидше за все, з'явиться перед тим, як скрипти почнуть працювати. Це також означає, що якщо ви залежать від певної функціональності ваших сценаріїв, це буде недоступно до того, як сторінка стане видимою для користувача.

Якщо ви додаєте стилі або елементи (тощо, перемикаючи текстові поля за допомогою певного формату розширеного редактора), це буде видно користувачеві як мерехтіння.

Якщо ви додаєте події кліків до елементів, їх не можна буде натиснути, доки трохи не стануть видимі самі елементи.

Іноді проблеми з тезами вимагають, щоб ви поклали свої сценарії в голову, в інший час ви будете в порядку, вставивши їх в дно.

ІМХО (повністю проти YSlow та багатьох розумних людей), ви повинні зберігати свої сценарії в тезі head і просто покладатися на їх кешування більшу частину часу.


9

Загалом ви повинні розміщувати посилання на сценарії внизу сторінки. Сценарії потрібно не тільки завантажити, вони також повинні бути оцінені та виконані до того, як блок буде звільнений і сторінка продовжить процес візуалізації. Такі речі, як Modernizr, слід розмістити вгорі, оскільки він виявляє деякі функції, а також HTML5 прокладки, які вам, мабуть, знадобляться.

Ще однією причиною, за якою ви хочете спробувати розмістити сценарії внизу сторінки, є одиничні точки відмови або SPOF. Тут виклик сценарію закінчується або з якоїсь іншої причини блокує виконання сторінки. Цього може статися багато в сторонніх рекламних бібліотеках тощо.

Так, можливо, вам доведеться трохи більше подумати над тим, як ви розробляєте свою заявку, але я виявив, що це стало дуже природним для мене дуже швидко. За останні 4 роки я створив сотні веб-програм із сценарієм внизу, і я можу помітити різницю. Я можу бути 500 мс, це може бути 5000 мс, але це все має значення.


5

Це насправді залежить від вашого веб-сайту. Якщо ви отримуєте доступ до функцій JavaScript всередині тіла та викликаєте їх, тоді на нього потрібно посилатись у заголовку, щоб воно було завантажено. В іншому випадку, якщо ви збираєтеся викликати JavaScript лише тоді, коли завантажується весь документ, тоді розумно помістити JavaScript у кінець основного тексту. Поставивши файл .JS наприкінці, ви завантажуєте цілу сторінку, а потім отримуєте файл .JS. Таким чином користувач зможе швидко побачити сторінку, і до того часу, коли він / вона ознайомиться зі сторінкою, файл .JS вже завантажено.


4

Будь-який javascript у голові буде оцінено перед завантаженням сторінки, тобто сторінка відчуває, що завантаження займає більше часу. Трохи складніше змусити події працювати належним чином, якщо весь javascript знаходиться в кінці, але jQuery в значній мірі вирішує цю проблему за вас.


2
Не могли б ви згадати, як jQuery вирішує цю проблему з інтересу?
Метью Лок,

jQuery має API для прив'язки обробників до подій
Draemon
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.