WedX - журнал о программировании и компьютерных науках

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

Я экспериментировал с Critical CSS от Filament (https://github.com/filamentgroup/grunt-criticalcss) и у вас есть вопросы по его использованию.

Когда я использую этот инструмент, он создает «критическую» таблицу для каждой страницы, на которую я указываю, чтобы я мог встроить эти файлы в свой HTML с помощью тега ‹style› в ‹head›. Все это имеет смысл.

Однако, как только пользователь посетит любую из страниц моего сайта, у него будет полностью кэширован основной лист. Имеет ли смысл прекратить встраивание CSS, поскольку у пользователя уже загружен CSS, и вместо этого ссылаться на него через традиционный тег?


  • Вы вообще не должны по умолчанию использовать встроенный css... 25.12.2014
  • Уточнил мой вопрос, под строкой я имел в виду вставку критического CSS в тег ‹style› в ‹head› 26.12.2014
  • Я бы все равно не рекомендовал этого делать вообще. В большинстве случаев увеличения вашей способности загружать страницу недостаточно. Изображения вызывают гораздо большую озабоченность ... Однако ... если вы хотите сделать либо или просто сделать файл cookie, который привязан только к css, а в заголовке html есть статус if else, который делает одно или другое, если они имеют печенье или нет. 29.12.2014
  • Google Page Insights (developers.google.com/speed/pagespeed/insights) не согласится с вами. Может быть недостаточно прироста производительности для всех веб-сайтов или приложений, чтобы оправдать эту конкретную практику; но это приносит дивиденды для определенных приложений. Я согласен с тем, что HTTP-запросы гораздо важнее! 29.12.2014

Ответы:


1

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

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

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

24.12.2014
  • Ну, на самом деле метод, о котором я думал, немного более грубый. Когда пользователь заходит в первый раз, обслуживайте критический CSS в заголовке и полном файле ajax. Затем просто установите посещаемый файл cookie. Я бы просто предположил, что если они посетили сайт, то им не нужно, чтобы я обслуживал документ с критическим CSS в голове. Это предположение, но загрузка встроенного CSS, когда у пользователя есть полный файл, кажется мне пустой тратой времени. 26.12.2014

  • 2

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

    24.12.2014
  • На самом деле встраивание критически важного CSS — это скорость страницы (developers.google.com/speed/pagespeed/insights) рекомендацию и обычно считается лучшей практикой внешнего интерфейса для оптимальной производительности. Этот вопрос не имеет ничего общего со спецификой, и когда я говорю встроенный, я имею в виду тег ‹style› в ‹head›. 26.12.2014
  • любой ‹стиль› в ‹head› называется стилем 'Header'. «Встроенный» стиль означает, что он буквально находится в одной строке. И да, это рекомендация для производительности, когда она абсолютна и не требует вмешательства извне. Вот почему встроенные стили перезаписывают все остальное, кроме !important. 26.12.2014
  • Я использовал термин встроенный в том же ключе, что и в этой статье (feedthebot.com/ pagespeed/inline-small-css.html). Для меня это просто означает вставить CSS в файл HTML (через теги стиля или атрибуты стиля). Я имею в виду стиль заголовка, как вы его называете. Мой вопрос не имеет ничего общего со стилем с помощью атрибута стиля элемента или встроенного стиля, как вы его называете. Я спрашиваю об оптимальной производительности с методами Critical или Above The Fold CSS, которые выполняются с помощью тега ‹style› в ‹head›. 26.12.2014

  • 3

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

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

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

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

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

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

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

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

    29.12.2014
  • Ценю ваши идеи, спасибо, что написали. Я рассматриваю критический css не только как реальный прирост производительности, но и как воспринимаемый. Но вы правы, это имеет смысл только в том случае, если вы можете легко прикрыть свои базы. 06.01.2015
  • Новые материалы

    Как создать диаграмму градиентной кисти с помощью D3.js
    Резюме: Из этого туториала Вы узнаете, как добавить градиентную кисть к диаграмме с областями в D3.js. Мы добавим градиент к значениям SVG и применим градиент в качестве заливки к диаграмме с..

    Я хотел выучить язык программирования MVC4, но не мог выучить его раньше, потому что это выглядит сложно…
    Просто начните и учитесь самостоятельно Я хотел выучить язык программирования MVC4, но не мог выучить его раньше, потому что он кажется мне сложным, и я бросил его. Это в основном инструмент..

    Лицензии с открытым исходным кодом: руководство для разработчиков и создателей
    В динамичном мире разработки программного обеспечения открытый исходный код стал мощной парадигмой, способствующей сотрудничеству, инновациям и прогрессу, движимому сообществом. В основе..

    Объяснение документов 02: BERT
    BERT представил двухступенчатую структуру обучения: предварительное обучение и тонкая настройка. Во время предварительного обучения модель обучается на неразмеченных данных с помощью..

    Как проанализировать работу вашего классификатора?
    Не всегда просто знать, какие показатели использовать С развитием глубокого обучения все больше и больше людей учатся обучать свой первый классификатор. Но как только вы закончите..

    Работа с цепями Маркова, часть 4 (Машинное обучение)
    Нелинейные цепи Маркова с агрегатором и их приложения (arXiv) Автор : Бар Лайт Аннотация: Изучаются свойства подкласса случайных процессов, называемых дискретными нелинейными цепями Маркова..

    Crazy Laravel Livewire упростил мне создание электронной коммерции (панель администратора и API) [Часть 3]
    Как вы сегодня, ребята? В этой части мы создадим CRUD для данных о продукте. Думаю, в этой части я не буду слишком много делиться теорией, но чаще буду делиться своим кодом. Потому что..


    Для любых предложений по сайту: [email protected]