Оптимізація JavaScript і CSS-файлів в Drupal

1. З чого починається сайт?
2. аналіз ситуації
3. CSS-файли
4. Обмежений Internet Explorer
5. Обмеження протоколу HTTP
6. підсумок аналізу
7. види оптимізації
8. Огляд існуючих Javascript-компресорів.
9. Варіанти вирішення проблеми
10. Стандартні можливості Drupal
11. Як працює оптимізація JS і CSS-файлів в ядрі Drupal?
12. Недоліки методу оптимізації в ядрі Drupal
13. Оптимізація JavaScript в ядрі Drupal
14. Використання HTTP-стиснення
15. додаткові модулі
16. модуль CSS Gzip
17. модуль Parallel
18. модуль IE CSS Optimizer
19. модуль IE Unlimited CSS Loader
20. модуль CSSTidy
21. Тестування швидкості завантаження сторінки
22. Умови проведення тесту
23. Діаграма часу завантаження сторінки в різних режимах
24. Аналіз результатів тестування
25. Перенесення JavaScript в footer

З чого починається сайт?

• Для браузера сайт починається з GET-запиту сторінки.
• Сервер на цей запит висилає HTML-код сторінки.
• Браузер розбирає код та почне завантажувати всіх зовнішніх файлів (JS, CSS, Flash і ін.) В порядку їх слідування в коді.
• Зазвичай браузер використовує не більше 2-х потоків для завантаження зовнішніх файлів, а CSS і JS завантажуються взагалі в одному потоці.
• Час на кожен запит залежить від розміру повертається відповіді, завантаження сервера і активності на кожній машині на всьому шляху між браузером і сервером.
• Чим більше розмір файлу - тим довше він буде доставлятися браузеру.
• Чим більше кількість файлів - тим довше буде завантажуватися вся сторінка.

Як браузер рендерить сторінку?

До моменту повного завантаження JS з HEAD користувач бачить "білу сторінку". Коли все зовнішні скрипти завантажені, починається Виконання покрівельних JS в порядку проходження на сторінці (зверху вниз), а користувач уже починає бачити контент сторінки, і в міру завантаження CSS і картинок, сторінка промальовується повністю.

Таким чином, щоб збільшити швидкість завантаження сторінки потрібно:

• Зменшити розміри скриптів щоб прискорити первинний відгук сторінки
• Зменшити кількість файлів (картинки об'єднуються в спрайт, а JS і CSS аггрегіруются)
• Використовувати HTTP-стиснення
• Збільшити кількість хостів, з яких завантажується статика сайту, щоб браузер міг збільшити ліміт одночасних з'єднань
• Помістити JavaScript в footer сторінки, щоб вони завантажувалися останніми, а користувач міг вже користуватися сторінкою.

Оптимізація графіки і створення спрайтів - робота для дизайнера, а ми займемося оптимізацією JavaScript і CSS-файлів в Drupal.

Давайте подивимося як йдуть справи з цими файлами в Drupal.

аналіз ситуації

JavaScript

Pазмер ваших JS-файлів ви можете самі перевірити командою:

find. -name '* .js' -exec ls -l {} \; | awk '{s + = $ 5} END {print s}'

У нашому проекті, крім файлів ядра, є ще понад 1300 (!) JS-файлів, які знаходяться в додаткових модуляx і темах.
Загальний розмір усіх JS-файлів - 14'746'899 байт.
В ядрі Drupal 6 я знайшов такі Javascript-файли:

1. modules / comment / comment.js
2. modules / profile / profile.js
3. modules / openid / openid.js
4. modules / taxonomy / taxonomy.js
5. modules / system / system.js
6. modules / block / block.js
7. modules / color / color.js
8. modules / user / user.js
9. misc / autocomplete.js
10. misc / drupal.js
11. misc / collapse.js
12. misc / batch.js
13. misc / farbtastic / farbtastic.js
14. misc / form.js
15. misc / tableselect.js
16. misc / ahah.js
17. misc / tabledrag.js
18. misc / textarea.js
19. misc / progress.js
20. misc / tableheader.js
21. misc / teaser.js
22. misc / jquery.form.js
23. misc / jquery.js

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

CSS-файли

У вашому проекті кількість і сумарний розмір буде інший.
Команда для самостійної перевірки розміру CSS файлів:
find. -name '* .css' -exec ls -l {} \; | awk '{s + = $ 5} END {print s}'

У нашому проекті, крім файлів ядра, є ще близько 450-ти в додаткових модулях і темах.
Загальний розмір усіх CSS-файлів - 1'674'793 байт.
Що стосується CSS-файлів в ядрі Drupal 6, то ось вони:

1. modules / locale / locale.css
2. modules / aggregator / aggregator-rtl.css
3. modules / aggregator / aggregator.css
4. modules / update / update.css
5. modules / update / update-rtl.css
6. modules / poll / poll.css
7. modules / poll / poll-rtl.css
8. modules / comment / comment-rtl.css
9. modules / comment / comment.css
10. modules / tracker / tracker.css
11. modules / forum / forum-rtl.css
12. modules / forum / forum.css
13. modules / book / book.css
14. modules / book / book-rtl.css
15. modules / profile / profile.css
16. modules / search / search-rtl.css
17. modules / search / search.css
18. modules / openid / openid.css
19. modules / node / node-rtl.css
20. modules / node / node.css
21. modules / taxonomy / taxonomy.css
22. modules / system / system-menus-rtl.css
23. modules / system / admin-rtl.css
24. modules / system / admin.css
25. modules / system / maintenance.css
26. modules / system / defaults-rtl.css
27. modules / system / defaults.css
28. modules / system / system-rtl.css
29. modules / system / system-menus.css
30. modules / system / system.css
31. modules / block / block.css
32. modules / color / color.css
33. modules / color / color-rtl.css
34. modules / help / help.css
35. modules / help / help-rtl.css
36. modules / dblog / dblog.css
37. modules / dblog / dblog-rtl.css
38. modules / user / user.css
39. modules / user / user-rtl.css
40. misc / print-rtl.css
41. misc / farbtastic / farbtastic.css
42. misc / print.css
43. themes / bluemarine / style.css
44. themes / bluemarine / style-rtl.css
45. themes / garland / print.css
46. themes / garland / style.css
47. themes / garland / minnelli / minnelli.css
48. themes / garland / color / preview.css
49. themes / garland / style-rtl.css
50. themes / garland / fix-ie.css
51. themes / garland / fix-ie-rtl.css
52. themes / pushbutton / style.css
53. themes / pushbutton / style-rtl.css
54. themes / chameleon / common-rtl.css
55. themes / chameleon / style.css
56. themes / chameleon / marvin / style.css
57. themes / chameleon / marvin / style-rtl.css
58. themes / chameleon / common.css
59. themes / chameleon / style-rtl.css

Сумарний розмір CSS-файлів на порядок менше, ніж розмір JS-файлів. Але потрібно врахувати, що CSS-файлів на сторінці набагато більше, ніж JS-файлів - приблизно в 2 рази більше. Крім того, стилі, як правило, завантажуються для всіх сторінок (це стилі теми) і тільки стилі модулів можуть завантажуватися для певних сторінок. Таким чином і файли стилів, і скрипти потребують нашої уваги в однаковій мірі.

Обмежений Internet Explorer

Браузер IE 6-8 має обмеження на кількість і розмір CSS-файлів :

• Всі теги додавання стилів після перших 31 тегів ігноруються.
• Всі CSS-правила після перших 4,095 правил ігноруються.
• На сторінках, які використовують правило @import для імпорту зовнішніх таблиць стилів, які імпортують інші зовнішні таблиці стилів, таблиці стилів з рівнем вкладеності більше 3 - ігноруються.

Обмеження протоколу HTTP

Цікаво чи є у браузерів обмеження на кількість АJAX-з'єднань?

Згідно зі специфікацією HTTP 1.1 браузер повинен встановлювати не більше 2 одночасних з'єднань (і це справедлівао для IE6 / 7) до одного хосту. У Firefox і Opera цей параметр настроюється і становить не менше 4 за замовчуванням. За деякими даними в IE8 - 6 з'єднань з одним хостом.

Джерело інформації: Raising network.http.max-persistent-connections-per-server?

• Firefox 2: 2
• Firefox 3 beta 4: 4
• Opera 9.26: 4
• Opera 9.5 beta: 4
• Safari 3.0.4 Mac / Windows: 4
• IE 7: 2
• IE 8: 6

підсумок аналізу

• Більшість JS і CSS-файлів не оптимізовані.
• Файлів багато і їх сумарні розміри значні.
• Маємо проблеми з браузером IE, який обмежує кількість CSS-файлів на сторінці.
• Проблеми зі швидкістю завантаження сторінки через великої кількості зовнішніх файлів і обмеження браузерів на кількість одночасних з'єднань з сервером.

Розберемося з термінологією.

види оптимізації

Мінімізація скрипта - це видалення з коду всіх несуттєвих символів з метою зменшення обсягу файлу скрипта і прискорення його завантаження. У мінімізованому коді видаляються всі коментарі і незначні прогалини, переноси рядків, символи табуляції. У випадку з JavaScript, це зменшує час завантаження сторінки, так як розмір файлу зменшується. Дві найпопулярніших утиліти для мінімізації JavaScript - JSMin і YUI Compressor .

обфускація є альтернативним способом скорочення вихідного коду. Також, як мінімізація, вона видаляє пробільні символи і вирізає коментарі, але на додаток вона ізмененяются сам код. Наприклад, під час обфускаціі імена функцій і змінних замінюються на більш короткі, що робить код більш компактним, але менш читабельним. Зазвичай цей прийом використовується для ускладнення реверс-інжинірингу програми. Але обфускація допомагає також зменшити код настільки, наскільки це не вийде зробити однією мінімізацією. З вибором кошти для обфускаціі JavaScript не все так ясно, але я думаю, що найпоширеніша утиліта для цього - Dojo Compressor (ShrinkSafe).

Мінімізація JavaScript - безпечний і досить простий процес. З іншого боку, обфускація через свою складність може вносити в код помилки. Обфускація також вимагає редагування вашого коду для виділення в ньому API-функцій та інших елементів, які не повинні бути змінені.

аггрегаціі - це об'єднання декількох файлів на сторінці в один. Аггрегаціі безпечна також як і мінімізація, тому що код не змінюється. Іноді "склейка" файлів може давати збій через некоректні коментарів в кінці файлів. Аггрегаціі дозволяє зменшити кількість файлів, що підключаються на сторінці. Починаючи з Drupal 6 аггрегаціі CSS і JS-файлів вбудована в ядро, а до цієї версії потрібно було встановити додатковий модуль.

HTTP-стиснених - це спосіб стиснути контент (в основному текстовий), який передається з веб-серверів через інтернет в браузери. Основна перевага стиснення в тому, що зменшується кількість байт, які передаються і таким чином досягається велика продуктивність. HTTP-стиснення використовує загальнодоступні алгоритми стиснення, щоб кодувати HTML, XML, JavaScript, CSS і інші формати файлів на стороні сервера. Цей метод доставки стисненого контенту заснований на стандартах і включений в HTTP / 1.1 і всі сучасні браузери підтримують протокол HTTP / 1.1. Таким чином вони можуть розпаковувати стислі файли автоматично на стороні клієнта. Це означає, що ніякого додаткового ПЗ або участі користувача на стороні клієнта не потрібно.

Запит на сервер без використання стиснення

Запит на сервер і сервер віддає стислий контент

Для каскадних таблиць стилів можна застосовувати тільки мінімізацію, аггрегацію і HTTP-стиснення. Обфускація для CSS-файлів не використовується. А ось для JavaScript-файлів будь-який з методів підходить.

Огляд існуючих Javascript-компресорів.

Порівняти ступінь стиснення одного і того ж файлу можна за допомогою онлайн-сервісу: JavaScript Compressor and Comparison Utility .

• JSMin - традиційний компресор, написаний кілька років тому Дугласом Крокфорд (Douglas Crockford). Утиліта безпечна (особливо, якщо ви перед використанням перевірили ваш код за допомогою JSLint ), Тому що утиліта не намагається змінювати імена змінних.
• Dojo shrinksafe - це дуже популярний JavaScript компресор, написаний на Java. Він парсит коду використовуючи бібліотеку rhino і змінює імена локальних змінних.
• Packer написаний Діном Едвардсом (Dean Edwards). Ще один дуже популярний JavaScript компресор, який може ще більше звичайного стиснення і також додає розпакування "на льоту" під час виконання JavaScript.
• YUI Compressor - це нові компресор, написаний Люліен Лекомт (Julien Lecomte), який ставить собі за мету об'єднати безпеку JSMin з найвищим рівнем стиснення, який досягається Dojo Shrinksafe. Подібно Dojo shrinksafe, він написаний на Java і заснований на бібліотеці rhino .

Ступінь стиснення у всіх компресорів різна, тому як і методи стиснення теж різні. Стиснення маленьких файлів, як правило, дає дуже незначне стиснення, а файли більше 10Кбайт стискаються дуже добре. На діаграмі нижче показана залежність ступеня стиснення від розміру файлу:

Подробиці тестування ступеня сжанія різними компресорами - в статті JavaScript: жати або не тиснути? . Використана діаграма з цієї статті.

Варіанти вирішення проблеми

Отже, у нас є досить велика кількість файлів, які можна стиснути і нам потрібно розібратися з тим, що Drupal вже може нам запропонувати (в ядрі і в додаткових модулях) і знайти найбільш оптимальне рішення.

Почнемо з аналізу того, що ми вже маємо "з коробки".

Стандартні можливості Drupal

В ядрі Drupal 6 реалізовані аггрегаціі JavaScript і СSS-файлів і HTTP-стиснення.
На сторінці "Performance" ( "Продуктивність" - admin / settings / performance) є можливість включити / вимкнути оптимізацію CSS і JavaScript файлів:

Якщо оптимізація CSS і JS-файлів заблоковано - це значить, що кеш агрегованих файлів не вдається записати в файли. Перевірте чи правильно вказано шлях до папки files і права записи для цієї папки на сторінці File System (Файлова система - admin / settings / file-system).

Як працює оптимізація JS і CSS-файлів в ядрі Drupal?

Щоб почати користуватися цією можливістю - потрібно включити оптимізацію JavaScript або CSS-файлів на сторінці налаштування продуктивності.
Тоді під час темізаціі сторінки з функції template_preprocess_page () буде викликана фукнція drupal_get_css () . Саме ця функція і робить основну роботу для CSS-файлів.

Як працює функція drupal_get_css () ?

• Оптимізація CSS не робиться, коли сайт знаходиться в режимі Maintenance ( "Обслуговування") або запущено оновлення (update.php).
• До оптимізованим файлів додається рядок у вигляді параметра, яка дозволяє контролювати кешування файлів браузером. Коли запускається update.php або робиться повний скидання кеша, - змінюється цей рядок, що змушує браузери перезавантажити нові версії файлів, так як вони вважають, що URL змінився.
• Чи буде файл брати участь в оптимізації вирішує 4й аргумент функції drupal_add_css () - $ preprocess, який визначає чи буде даний файл брати участь в оптимізації, якщо вона буде включена. За замовчуванням файл буде брати участь в оптимізації.
• Спочатку формується 2 списку файлів, які не беруть участі в оптимізації CSS - окремо (1) для модулів і окремо (2) для тем.
• Далі створюється ім'я файлу, який буде зберігати оптимізований CSS і викликається функція drupal_build_css_cache () , Яка аггрегірует і оптимізує CSS файли.
• Отриманий файл зберігається в папці sites / default / files / css (в мультісайтового установці буде інший шлях, але, - я думаю, - що ви і самі знаєте де вони будуть зберігатися).

Що в себе включає оптимізація?

• Все @import інструкції проходять обробку в drupal_load_stylesheet () І замінюються контентом файлу, який повинен був імпортуватися.
• Знаходяться всі коментарі з поодинокими і подвійними кaвичкамі і відправляються на обробку в функцію _process_comment () , Яка намагається визначити чи можна цей коментар видалити або це хак для IE-Mac.
• Видаляються прогалини навколо роздільників, але зберігаються навколо круглих дужок.

Отже, оптимізація, яку нам пропонує ядро ​​Drupal є насправді мінімізацією з аггрегаціі в один файл.

Недоліки методу оптимізації в ядрі Drupal

Метод оптимізації, який використовується в ядрі Drupal безпечний, тобто він не призводить до помилок в коді. Але метод не настільки ефективний, як здається.

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

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

Оптимізація JavaScript в ядрі Drupal

Оптимізація JavaScript робиться подібно оптимізації CSS-файлів.

Саме такий спосіб склейки може породити помилки в агрегованому файлі, коли в кінці скрипта останнім рядком був коментар.

При оптимізації JavaScript-файлів вони об'єднуються в один великий файл трохи інакше - після кожного файлу додається "; \ n".
Сам код JS-файлу не змінюється - це можна побачити в коді функції drupal_build_js_cache () , А просто об'єднується в один великий файл.

Тобто ядро Drupal робить навіть мінімізації JavaScript!

Використання HTTP-стиснення

На сторінці налаштування продуктивності ( "Perfomance") можна включати і вимикати HTTP-стиснення:

фукнція page_set_cache () зберігає стислий контент сторінки в кеші, якщо:

• Якщо вибрано використання стиснення трафіку на сторінці налаштування продуктивності,
• розширення PHP zlib ) Присутній в системі,

Drupal кешує контент сторінки, а при виконанні умов, зазначених вище, стискає і потім кешує контент сторінки. .

Якщо браузер підтримує HTTP-стиснення, то в запиті сторінки він вказує з якими видами стиснення він вміє працювати:

Accept-Encoding: gzip, deflate

A simple online web page compression / deflate / gzip test tool - сервіс, який перевіряє чи віддає сервер файл з використанням HTTP-стиснення і ступінь стиснення.

Якщо сервер використовує HTTP-стиснення, то він буде сам стискати і віддавати браузеру стислу версію контенту.
Але Drupal може і сам при наявності бібліотеки zlib стискати і кешувати вже стислу версію HTML-сторінки, але не JS і не CSS-файли.
Це означає, що якщо веб-сервер налаштований стискати контент і браузер підтримує таке стиснення, то сервер буде "на льоту" стискати JS і CSS-файли. Але набагато ефективніше було б зберігати стислі копії цих файлів з максимально великим ступенем стиснення, а не стискати їх "на льоту" (в цьому випадку за замовчуванням використовується не максимальний ступінь стиснення).

додаткові модулі

модуль JavaScript Aggregator

Модуль робить мінімізацію JS-файлів, використовуючи JSMin
Модуль може стискати агрегованих і мінімізовані JS-файли, використовуючи gzip-стиснення. Стисла копія зберігається в файлі на сервері і віддається браузеру замість того, щоб веб-сервер стискав цей файл самостійно.

Приклад стиснення:

FILENAME SIZE DESCRIPTION 6e13ccb6262e06b9f890414db56d3b1f.js 289.558 Bytes> Aggregated by Drupal Core 6e13ccb6262e06b9f890414db56d3b1f.jsmin.js 173.243 Bytes> Minified with JSMin 6e13ccb6262e06b9f890414db56d3b1f.jsmin.js.gz 47.618 Bytes> Minified and gzipped

модуль CSS Gzip

• Модуль стискає агрегованих CSS-файли, як це робить з JS-файлами модуль Javascript Aggregator.
• Стискає контент один раз і зберігає результат - це зменшує навантаження на процесор сервера.
• Використовує 9й рівень стиснення так як це потрібно зробити лише 1 раз для кожного файлу, що дає менший розмір файлу.
• Вимагає включені "Чисті посилання" (mod_rewrite).
• Вимагає, щоб метод скачування був "Публічний" (див admin / settings / file-system).
• Увійшов в ядро ​​Drupal 7.

модуль Parallel

• Дозволяє браузеру паралельно завантажувати зовнішні файли сторінки.
• Для цього створюється 3 нових поддомена, які вказують на одну кореневу папку сайту.
• Включити модуль Parallel.
• На сторінці "Продуктивність" ( "Performance") потрібно вказати ці піддомени.
• Не вимагає хакати ядро ​​Drupal.
• Модуль Parallel работет тільки з JavaScript, картинками і CSS.

модуль IE CSS Optimizer

• Модуль дає можливість розробникам виключати окремі файли модулів, а також CSS-файли тим, з аггрегации.
• Вимагає, щоб метод скачування був "Публічний" (див admin / settings / file-system).
• В Drupal 7 модуль не потрібен: http://drupal.org/node/228818 .
• Інші модулі можуть перезаписати $ vars [ 'styles'] і це нейтралізує модуль. Лагодиться зміною ваги модуля.

модуль IE Unlimited CSS Loader

"Do not use @import" - стаття про те, чому використання @import не бажано з точки зору продуктивності.

Модуль робить приблизно те ж саме, що і IE CSS Optimizer , Але трохи інакше - використовує @import, щоб обійти обмеженість браузера IE в 31 СSS-файл.

модуль CSSTidy

• Модуль автоматично запускає CSSTidy в максимальним рівнем стиснення.
• Можна налаштувати так, щоб код залишався читабельним.
• Модуль не сумісний з Pressflow.
• Новий CSS3 може викликати проблеми (див. http://drupal.org/node/763730 ). Деякі з них вже вирішені: http://drupal.org/cvs?commit=432558

Що оптимізується:

• Кольори типу black або rgb (0,0,0) конвертуються в hex-коди типу # 000, коли тільки можливо. Деякі hex-коди замінюються їх колірними іменами, якщо вони коротші (# f00 -> red).
• a {property: x; property: y;} стає a {property: y;} (всі повторювані атрибути об'єднуються).
• margin: 1px 1px 1px 1px; стає margin: 1px ;.
• margin: 0px; стає margin: 0 ;.
• a {margin-top: 10px; margin-bottom: 10px; margin-left: 10px; margin-right: 10px;} стає a {margin: 10px;}.
• margin: 010.0px; стає margin: 10px ;.
• Все не потрібні прогалини видаляються.
• Всі властивості background: об'єднуються.
• Всі коментарі видаляються.
• Остання крапка з комою в кожному блоці видаляється.
• Відсутні крапки з комою додаються, некоректні переноси рядків у рядках виправляються, невірні кольору (і імена квітів) виправляються.
• property: value! important; стає property: value! important;

CSS-хакі, які працюють:

Тестування швидкості завантаження сторінки

Було проведено замір часу завантаження сторінки, щоб з'ясувати наскільки зміниться середній час завантаження при різних методах оптимізації JS-файлів. Тестовий сайт має понад 1300 JS-файлів і майже 450-CSS-файлів. Встановлено 227 модулів (включаючи модулі ядра). Були досліджені різні методи оптимізації:

• Optimize JavaScript files: Disabled - оптимізація JS-файлів ядром Drupal відключена
• Optimize JavaScript files: Enabled - оптимізація JS-файлів ядром Drupal включена
• Optimize and Minify JavaScript files: Enabled - оптимізація JS-файлів ядром Drupal включена і додатково встановлено модуль Javascript Aggregator, який сильніше мінімізує JS-код.

Умови проведення тесту

налаштування браузера

• Проверяемая сторінка: головна сторінка тестованого сайту
• Браузер: Firefox 3.6.13
• Кеш браузера: 500М
• Інструмент виміру: Yslow 2.1.0
• Проксі сервер: чи не використовувався

налаштування сервера

• Сервер має: Accelerator
• Операційна система: Linux
• Версія ядра: 2.6.29-5
• Архітектура: x86_64

Налаштування в Drupal

• Користувач в Drupal: суперадмін
• Caching mode: Normal
• Minimum cache lifetime: none
• Page compression: enabled
• Block cache: enabled
• Optimize CSS files: enabled

результати тестування

Середній час завантаження сторінки

Діаграма часу завантаження сторінки в різних режимах

Аналіз результатів тестування

• Аггрегаціі зменшує кількість запитів до сервера (при порожньому кеші) на 23 штуки.
  Це означає, що коли користувач вперше завантажує сторінку (кеш порожній), то завантаження буде виконана швидше.
• Використання кешу браузера дозволяє знизити кількість запитів до 13.
  Повторні запити тієї ж самої сторінки робляться ще швидше завдяки тому, що браузер кешує деякі файли.
  Кеш, як правило, включений за замовчуванням, але керувати кешуванням браузера ми не можемо і він може бути просто відключений.
• Gzip-стиснення робиться не з максимальним рівнем стиснення.
  Агрегованих JS-файл має точно такий же розмір, як і сумарний розмір усіх неаггрегірованних JS-файлів сторінки. Агрегованих файл на сервері має розмір 326,9Кбайт, а отриманий браузером і стислий gzip - 108,9Кбайт. При цьому стиснення утилітою gzip того ж файлу вручну дає розмір близько 90Кбайт. Причина в тому, що бібліотека zlib, яка використовується для стиснення на сервері має за замовчуванням ступінь стиснення (zlib.output_compression_level) рівну "-1", хоча максимальний ступінь стиснення - це "9", а "-1" - це найкраще швидкодію. Таким чином ми отримуємо найгірше стиск, але завдяки цьому швидкодія сервера вище.
• Використання модуля JavaScript Aggregator разом з аггрегаціі і Gzip-стисненням дає файл набагато меншого розміру, чим не агрегованих файли.

Таким чином експериментальним шляхом було встановлено, що оптимізація ядром Drupal JS-файлів не завжди показує хороший результат. У нашому випадку (без застосування модуля JavaScript Aggregator) ми отримали незначне збільшення швидкості завантаження (за рахунок скорочення кількості запитів) і збільшення (у порівнянні з вихідними файлами) розміру агрегованих (і стисненого) файлу.

З огляду на те, на багатьох сторінках завантажуються одні і ті ж JS і СSS-файли, а додаються / видаляються тільки кілька специфічних, то кешування одного великого файлу не дасть приросту продуктивності. При цьому кешування браузером окремих файлів стилів і скриптів на одній сторінці дасть економію на завантаженні цих файлів на наступних сторінках.
Користувач, як правило, не завантажує одну й ту саму сторінку кілька разів, а переходить далі і далі ( "серфить") і таким чином кешування браузером невеликих файлів скриптів і стилів може бути ефективніше аггрегации в один великий файл. Але це тільки для користувача, а для сервера вигідніше мати якомога менше запитів і віддавати агрегованих файли, замість купи невеликих файлів.

Що можна зробити, щоб поліпшити ситуацію?

• Зберігати стислі JS-файли з максмальним рівнем стиснення, щоб не змушувати сервер стискати їх для кожного запиту.
• Використовувати більш ефективні методи упаковки JS і CSS-файлів.
• Можна використовувати вибіркову аггрегацію загальних для різних сторінок сайту скриптів і стилів, а специфічні файли завантажувати окремо, але цей метод трудомісткий.
• Перемістити Javascript у footer, щоб прискорити момент показу сторінки користувачеві.
• Використовувати CDN або модуль Parallel, щоб збільшити кількість одночасних з'єднань, які може дозволити собі браузер.

Перенесення JavaScript в footer

На самому початку статті ми з'ясували, що браузер завантажує весь CSS і весь JS з HEAD і тільки потім показує сторінку користувача і починає виконання JS. Саме тому є сенс перемістити JS-файли в footer, щоб наблизити момент появи контенту сторінки в браузері. Це зменшить час, коли користувач бачить "білу сторінку" і візуально прискорить завантаження сторінки (фактично сторінка буде завантажуватися стільки ж часу).

JS-файли в Drupal підключаються наступним чином:

drupal_add_js ($ data = NULL, $ type = 'module', $ scope = 'header', $ defer = FALSE, $ cache = TRUE, $ preprocess = TRUE)

тут
$ scope (optional) The location in which you want to place the script . Possible values ​​are 'header' and 'footer' by default. If your theme implements different locations, however, you can also use these.

За замовчуванням $ scope одно "header" і, якщо не вказано інше, то все скрипти завантажуються в HEAD ...
Таким чином потрібно у всіх модулях поміняти $ scope = 'header' на $ scope = 'footer'.

Просте переміщення в footer результату не дасть, тому що в HEAD сторінки залишаться inline-скрипти, які очікують наявності jquery.js і інших скриптів в HEAD і при виконанні будуть давати помилки.

Для 7й версії Drupal, було обговорення можливості зробити значенням за замовчуванням для $ scope - 'footer' ( Make 'footer' the default scope for drupal_add_js () so that pages render fast ), Але швидше за все це буде вже в 8й версії Drupal.

Корисні посилання

Компресори скриптів

HTTP-стиснення

Порядок завантаження елементів сторінки браузером

Перенесення Javascript у footer

різне