Поліпшення продуктивності веб-сайту за допомогою паралельних завантажень CSS?

Я оптимізував час завантаження сторінки веб-сайту. Одним із способів було поєднання декількох HTTP-запитів для CSS в один об'єднаний HTTP-запит. Але один із рецензентів задав цікаве запитання: чи не паралельне завантаження декількох файлів CSS скоротить час завантаження сторінки?

Я ніколи не розглядав цей варіант, тому що єдине, що я читав в Інтернеті, це те, що зменшення кількості (блокування) запитів HTTP є ключовим фактором для швидшої веб-сторінки (хоча ця сторінка Google Pagespeed Insights, очевидно, не чітко визначає це 1 ).

Я бачу кілька причин, через які паралелізація не підвищила б продуктивність або мала дуже мало значення (переважила користь використання меншої кількості HTTP-запитів):

Налаштування нового з'єднання дорого. Хоча налаштування декількох підключень може здійснюватися паралельно, браузери використовуватимуть щонайменше приблизно 4-6 підключень (залежно від браузера), тому завантаження паралельно CSS блокує завантаження інших ресурсів, таких як JavaScript та зображення.
Налаштування HTTPS-з'єднання потребує додаткових даних. Я читав, це легко може бути декілька КБ даних. Це кілька додаткових даних, які потрібно надсилати по дроту, замість CSS, які ми насправді хочемо надсилати.
Завдяки алгоритму повільного запуску TCP, чим більше даних буде надіслано через з'єднання, тим швидше буде з'єднання. Отже, триваліші з'єднання фактично надсилатимуть дані набагато швидше, ніж нові. Дивіться, наприклад, протокол SPDY, який використовує єдине з'єднання для покращення часу завантаження сторінки.
TCP - це абстракція: все ще є (як правило) лише одне базове з'єднання. Тож хоча використовується декілька запитів, дані, що надсилаються по дроту, не обов'язково можуть скористатися безліччю з'єднань взагалі для підвищення швидкості.
Підключення до Інтернету за своєю суттю ненадійне, особливо в мобільному. Один запит може бути виконаний значно швидше, ніж інший. Використання декількох запитів для CSS означає, що надання веб-сторінки блокується до останнього запиту, що закінчиться, що може бути значно пізніше, ніж середнє з'єднання.

Отже, чи є взагалі якась користь у паралелізації HTTP-запитів на файли CSS?

Примітка / оновлення: всі файли CSS блокуються візуалізацією. Файли CSS, які вже не переміщені за межі критичного шляху.

css performance

— айке
джерело

Я бачив щось на коді etsy як майстер-сайт, де вони рекомендували просто використовувати єдиний домен без файлів cookie для статичних об'єктів (css, imgs, js). Виявляється, сучасні браузери чудово справляються з паралельними завантаженнями з одного домену. Щодо декількох файлів з одного домену (10 файлів css проти 1 великого), я думаю, вам краще поєднувати та мінімізувати один великий файл і просто зробити його одним запитом. Спеціально з CSS, де для вашого сайту, ймовірно, знадобиться весь css, щоб виглядати правильно.

— Френк

Певним чином, браузери вже завантажують паралельно залежно від кількості підключень, які доступні для використання. Він заснований на HTML, який читає браузер.

— Нд

CSS-файли, пов’язані з документами HTML, додаються до черги паралельних завантажень під час розбору HTML; найголовніше - несинхронні посилання JavaScript блокують HTML-аналізатор, не дозволяючи пізніше додавати теги до черги завантаження до тих пір, поки JavaScript не буде завантажений, проаналізований та виконаний. ^[1]

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

<head>
  <script src="js/fizz.js"></script>
  <link rel="stylesheet" href="css/foo.css"/>
  <script src="js/buzz.js"></script>
  <link rel="stylesheet" href="css/bar.css"/>
</head>

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

<head>
  <link rel="stylesheet" href="css/foo.css"/>
  <link rel="stylesheet" href="css/bar.css"/>
  <script async src="js/fizz.js"></script>
  <script src="js/buzz.js"></script>
</head>

Ще одна примітка: файли CSS (за замовчуванням) блокують візуалізацію, а не блокування синтаксичного аналізу; сторінка буде продовжувати розбиратися та будувати DOM, але візуалізація не розпочнеться, поки CSSOM не буде побудований.

Основна причина, щоб розділити ваш CSS, полягає в тому, щоб отримати мінімальні правила, необхідні для того, щоб якнайшвидше надати вищезгаданому вмісту клієнту та проаналізувати його. Решта правил для речей, які не одразу видно, можна позначати як не обов’язково-блокують рендерінг із mediaзапитами в тезі посилання, або додавати на сторінку асинхронно завантаженим JavaScript.

Отже, немає чіткої користі для паралелізації завантажень CSS лише заради себе. Але, як завжди, виміряйте і випробуйте!

Для подальшого читання я рекомендую ці статті на тему "Основи веб-сторінок: оптимізація ефективності" від Google: https://developers.google.com/web/fundamentals/performance/

[1]: Це ігнорування функції спекулятивного розбору деяких браузерів:

https://docs.google.com/document/d/1JQZXrONw1RrjrdD_Z9jq1ZKsHguh8UVGHY_MZgE63II/preview?hl=en-GB&forcehl=1

https://developer.mozilla.org/en-US/docs/Web/HTML/Optimizing_your_pages_for_speculative_parsing

— Роберт К. Белл
джерело

Ще добре читати, про те , як зберегти ваші скрипти завантаження одночасно, тут: stackoverflow.com/questions/436411 / ...

— joshreesjones

Варто зазначити, що всі файли .js повинні бути пов’язані в кінці коду безпосередньо перед тегом закриття тіла, щоб вони нічого не блокували.

— Шаолі

Ви можете розробити "Отже, немає чіткої користі для паралелізації завантаження CSS лише заради себе"? Я якось не міг це зрозуміти з наведеної відповіді

— gaurav5430

@ gaurav5430 Мабуть, немає вагомих причин для розбиття файлів css, окрім оптимізації для вищевказаного часу візуалізації (і, можливо, оптимізація кешу?)

— Роберт К. Белл