Общее правило - отправляйте столько, сколько вам нужно - зачем отправлять ненужные данные и тратить время на загрузку и трафик? Так что, если вы можете встроить только свой критический CSS для 1 КБ, то сделайте это, если вам нужно 5 КБ, то продолжайте. Основная причина включения полных 15 КБ состоит в том, чтобы избежать сложности определения критического или необходимого CSS, но вы, похоже, решили эту проблему.
Некоторые также спорят о сохранении критических данных для первой краски (включая встроенный CSS и HTML) в первых 14 КБ страницы - это связано с тем, как работает TCP, и с тем, что он может отправлять 10 пакетов изначально он ожидает какого-либо подтверждения. Таким образом, все, что больше, чем 14 КБ, потребует подтверждения и так туда и обратно, и поэтому задержка. После этого сумма, которую TCP может отправить, прежде чем требовать подтверждения (CWND), растет в геометрической прогрессии, но начинается с малого. Лично я не уверен, что число 14 КБ остается верным; Для согласования SSL / TLS (при условии, что вы используете HTTPS) требуется часть из того, что 14 КБ также требуют циклических переходов, а затем для HTTP / 2 (опять же, если вы используете это) требуются дополнительные килобайты и циклические переходы для отправки исходных сообщений, все до Ваш HTTP-запрос отправлен и получен. Таким образом, к тому времени, когда все это произойдет, размер окна будет либо частью 14 КБ, либо уже увеличился в геометрической прогрессии до большего размера. Тем не менее, общий принцип сохранения его как можно меньшего размера, чтобы позволить большей части страницы загружаться быстрее, остается в силе - просто не обязательно фиксировать этот номер 14 КБ.
Независимо от того, решили ли вы вообще использовать CSS, все зависит только от вас. Увеличение скорости впечатляет, и вы правы в том, что первые просмотры страниц, как правило, более важны, но есть и недостатки, в том числе тот факт, что требуется шаг сборки, чтобы выяснить, какой CSS включить, а затем включить, факт дублирует данные на страницах, тот факт, что вам может понадобиться выпустить все веб-страницы с указанием их, если вы когда-нибудь измените свой CSS (в отличие от простого выпуска файла CSS) ... и т. д. Лично, если только вы не очень занят и супер оптимизирован сайт (например, домашняя страница Google), я думаю, что сложность не стоит. Больше моих мыслей об этом здесь: https://www.tunetheweb.com/blog/inlining-css-is-not-for-me/
Изменится ли это в HTTP / 2? Ну да и нет. Теоретически мультиплексирование HTTP / 2 означает, что несколько запросов могут быть на ходу одновременно, поэтому вам не нужно запускать другое соединение для запроса CSS, поэтому вам вообще может не потребоваться встроенное соединение. Тем не менее, для получения кода CSS после получения HTML-кода все еще требуется двусторонняя передача, поэтому он не такой быстрый, как встраивание, даже если он быстрее, чем HTTP / 1.1 (где вам нужно будет дождаться полного завершения загрузки HTML-кода, чтобы разрешить подключение к использоваться для запроса CSS или запускать другое соединение с задержками TCP и HTTPS, что влечет за собой).
HTTP / 2 Push должен был решить эту проблему - сохранить CSS в виде отдельного файла, но когда запрашивается HTML, ответьте файлом HTML и файлом CSS (нажмите файл CSS). Никакой задержки туда и обратно и все же отдельный файл CSS - лучший из обоих миров. Реальность, как всегда, немного сложнее. Основная проблема заключается в том, как избежать повторного нажатия CSS для всех последующих страниц (что имеет те же недостатки, что и встраивание). Существуют различные способы сделать это, но реализация на основе файлов cookie *1013*, вероятно, является лучшей и наиболее практичной на данный момент. Даже при этом есть другие сложности и ошибки, которые следует учитывать . Из-за этого HTTP / 2 push не удалось использовать в качестве встроенной замены.