Должен ли я удалить встроенный CSS после полной загрузки CSS?

Если вы уверены, что у пользователя есть кешированная таблица стилей, это будет правильным подходом, предполагая, что синтаксический анализ кэшированной таблицы стилей или встроенных стилей критического css займет столько же времени.

Однако вы не можете быть уверены, что он существует в кеше пользователей. Поскольку критический css также существует в таблице стилей, это не проблема, но рендеринг страницы будет медленнее.

Единственный способ узнать, когда это может быть полезно, — это проанализировать ваши журналы доступа, попытаться выяснить, как часто запрашивается таблица стилей, когда конкретная страница запрашивается конкретным пользователем. Используя это, вы можете создать вероятностную модель, когда полезно встроить критический css. Это похоже на слишком много работы для небольшого выигрыша. Я предполагаю, что использование встроенного критического css наиболее полезно для целевых страниц или страниц, которые становятся вирусными.

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

Я собираюсь ответить здесь, так как это лучше сделать, а не в комментариях.

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

Во-первых, ваша производительность увеличивается. Поскольку вы хотите иметь более высокую производительность, использование встроенных стилей является технически правильным ответом. Есть некоторые незначительные выгоды, потому что вы не выполняете запрос. Все исходящие запросы требуют времени, и в зависимости от времени, которое требуется серверу для передачи каждого запроса, вы увидите возможное падение производительности. Вот почему некоторые запросы, которые намного больше, считаются чрезмерными, и Google обычно информирует вас о спрайте изображения или какой-либо другой форме соединения.

Другая часть заключается в том, что вам нужна простота доступа и возможность быстрого обновления, что будет обеспечено реальным файлом CSS. В какой-то момент вам нужно будет вызвать этот файл CSS, чтобы его можно было кэшировать в браузере, как вы ожидаете. Вы можете выполнить некоторые проверки файлов cookie, и в зависимости от того, был ли пользователь на сайте или нет, у него будет конкретный вызов, но вот основная проблема:

В какой-то момент вы ДОЛЖНЫ его загрузить. Вам придется сделать звонок. Будь то первая загрузка или последняя, ​​в какой-то момент для кэширования ее на самом деле нужно извлечь. Вы потратите массу времени на проверку каждой переменной, если у них ее нет, им нужно будет загрузить таблицу стилей. Если вам уже требуется загружать его в какой-то момент, то это сводится к тому, что никогда не нужно делать встроенные стили. И если у вас есть встроенные стили, вам никогда не нужно их загружать.

Потенциально вы можете сделать PHP-включение файла и заставить его тянуть таким образом. Вы просто включили бы файл между объявлением стиля, и таким образом он заполнил бы CSS. Я бы не сказал, что это лучший способ сделать это, но это возможно. Это может быть сделано. Я по-прежнему настаиваю на том, что inline — это неправильный путь. Технически да, это может помочь. Реальность... нет. Я не видел, чтобы это было выгодно когда-либо в мое время. Если кто-то хочет показать мне один, это нормально, но я сомневаюсь, что буду использовать эту практику, если только это не будет крайним средством.

Имейте в виду эту последнюю мысль. В большинстве случаев встроенные стили — это стили, предназначенные для финальных стилей; те, которые заканчиваются перезаписью исходных внешних таблиц стилей, которые мы, как разработчики, не можем редактировать сами (или не хотим изменять по другим причинам).

Google великолепен, и они предоставляют отличные исследования, но исследования предназначены для рассмотрения и не всегда используются именно так, как они пишут. Это должно дать понимание. Обычно не является проводником в пути.