Comments 30
Не вижу бага.
Для скриптов есть ещё атрибут async.
Все содержание верхней части страницы отображается только после загрузки указанных далее ресурсов.Вы сделали точно по совету гугла, избавились от файла и встроили в код, теперь загружать отдельный файл (делать http запрос) не нужно.
Для скриптов есть ещё атрибут async.
Да, но я тестировал и с большим файлом CSS, размером большим, разница одна результат лучше, анализатор считает что все хорошо…
А на самом деле то отображаться контент начнет только лишь после загрузки всех стилей и время загрузки сократили на время http запроса, а для медленного интернета (мобильника все станет появляться позже).
Данная рекомендация говорит лишь о том, что поместите в самый верх лишь часть стилей, которые нужны для визуального отображения первоначальной стадии сайта (аналогично методу прогрессивного jpg), а все остальное вниз
А на самом деле то отображаться контент начнет только лишь после загрузки всех стилей и время загрузки сократили на время http запроса, а для медленного интернета (мобильника все станет появляться позже).
Данная рекомендация говорит лишь о том, что поместите в самый верх лишь часть стилей, которые нужны для визуального отображения первоначальной стадии сайта (аналогично методу прогрессивного jpg), а все остальное вниз
Если внешние ресурсы CSS имеют малый объем, их можно вставить непосредственно в документ HTML. Подобное встраивание позволяет браузеру продолжать загрузку страницы. Обратите внимание: если файл CSS слишком велик, после его встраивания PageSpeed Insights может вас предупредить, что верхняя часть страницы имеет слишком большой объем (правило приоритета видимого контента). Если файл CSS слишком велик, вам необходимо найти код CSS, отвечающий за контент в верхней части страницы и встроить его в HTML, отложив загрузку остальных стилей.
developers.google.com/speed/docs/insights/OptimizeCSSDelivery — вот отсюда
Скорее багофича, по идее в топе должны быть только стили страницы, которая видна до того, как пользователь начнет скроллить.
Да, для генерации этого css есть уже много разных средств — github.com/addyosmani/critical-path-css-tools
Вчера только оптимизировал сайт для pagespeed, получил 100/100.
Вчера только оптимизировал сайт для pagespeed, получил 100/100.
А также мы не забываем, что все-таки мы не решили проблему описанную выше:
колько они весили в файле, столько же весят и в коде!
Именно её вы и решили, был совет убрать загрузку 3-х ресурсов css и встроить их прямо в HTML, вы это сделали и получили оценку выше. Про сократить размер это вы уже сами придумали.
Так что это не баг и не фича, а самое обычное правильное поведение анализатора.
UFO just landed and posted this here
Напряг, только если не использовать CMS. При использовании любой CMS это уже не напряг, а вопрос целесообразности. Если css большой и используется в куче файлов, то лучше уж один раз его загрузить и дальше он будет браться из кэша, чем каждый раз по новой бОльший html файл скачивать. Так что тут надо смотреть по ситуации. Ну и по возможностям CMS.
А если верстать вручную, то тут однозначно отдельный файл. Или однозначно inline, если страниц одна-две. Всё ОЧЕНЬ однозначно.)
А если верстать вручную, то тут однозначно отдельный файл. Или однозначно inline, если страниц одна-две. Всё ОЧЕНЬ однозначно.)
UFO just landed and posted this here
Внукам будем рассказывать, что в стародавние времена читать новости в интернетах можно было на слабеньких четырёх-ядерных компьютерах с 8 гигабайтами оперативки и одной дискретной видеокартой и практически без тормозов, а они будут улыбаться и считать нас старыми пердунами, которые опять выдумывают какие-то небылицы.
Извините, но что это здесь делает? При вставке стилей непосредственно в код у вас быстрее начинается рендеринг страницы. Это рекомендация, и вообще хороший тон для фронтендера — выделить CriticalPath-стили (по-крайней мере первый viewport и mobile) и вставить их непосредственно на страницу. Анализатор детектит, что страница рендерится быстрее — отсюда и подкинул баллов.
http://alex.ru.net/sitebigfile.html (Файл 5 Мегабайт, стили продублированы 700 раз, которые занимают большую часть веса страницы, + сжал его)
А тест как всегда 100 из 100:
https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Falex.ru.net%2Fsitebigfile.html
Норма?
Баг?
Фича?
А тест как всегда 100 из 100:
https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Falex.ru.net%2Fsitebigfile.html
Норма?
Баг?
Фича?
Ну на момент моего коммента не было теста с большим файлом. Но давайте не забывать, что у вас на сайте сжатие — а текст ой как неплохо жмется. Так что нагрузили Вы лишь браузер — что тоже нехорошо, и анализатор обязан бы это подмечать.
Значит баг? анализатор же показывает каждую мелочь для мобильного, что кнопки близко, почему бы ему не показывать что у Вас много стилей в head'ере?
Лично мне больше греет душу показатель «Удобство для пользователей 100/100»
Эх.
У меня не выходит достигнуть 100/100 банально потому, что PageSpeed ругается на те файлы, до которых у меня нет возможности получить доступ: всякие расшаривалки, агент newrelic, счетчики mailru и liverinternet и, что самое забавное, гугл ругается на то, что файл ga.js с их же домена (google-analytics.com) является недостаточно сжатым)
Плюс, я не могу убрать из шапки страницы некоторый JS-код, так как он необходим для того, чтобы в контенте страницы могли успешно выполниться некоторые небольшие скрипты. Просто привык писать сайт таким образом, не вижу здесь чего-то нереально страшного… Ну гугл меня за это не очень любит.
Итого, результат одного из моих самых важных сайтов — 73/100, по всем этим причинам.
Плюс, я не могу убрать из шапки страницы некоторый JS-код, так как он необходим для того, чтобы в контенте страницы могли успешно выполниться некоторые небольшие скрипты. Просто привык писать сайт таким образом, не вижу здесь чего-то нереально страшного… Ну гугл меня за это не очень любит.
Итого, результат одного из моих самых важных сайтов — 73/100, по всем этим причинам.
Есть у вас доступ.
Всякие расшаривалки можно убрать, а код для них загружать только по запросу пользователя.
С остальным, думаю, аналогично.
Все привыкли говнокодить, а потом на смартфоне не дождёшься загрузки сайта.
Всякие расшаривалки можно убрать, а код для них загружать только по запросу пользователя.
С остальным, думаю, аналогично.
Все привыкли говнокодить, а потом на смартфоне не дождёшься загрузки сайта.
Используйте Google TAG Manager, чтобы все счетчики засунуть в один гугловый скрипт.
У меня 99 из 100 только потому, что:
Google TAG Manager исправит эту ситуацию? Или так же кэшируется только на 2 часа?
Используйте кеш браузера для следующих ресурсов:
www.google-analytics.com/analytics.js (2 часа)
Google TAG Manager исправит эту ситуацию? Или так же кэшируется только на 2 часа?
Нет, он не кешируется вообще.
Он просто позволяет собрать весь сторонний ява-скрипт (счетчики) в один файл. Туда можно еще кучу всяких отслеживаний событий для аналитикса засунуть, код для A/B тестирования и прочее.
Обычно всякие SEO агентства просят его установить, чтобы потом спокойно добавлять/убирать ява-скрипт, не прибегая к разработчикам.
Он просто позволяет собрать весь сторонний ява-скрипт (счетчики) в один файл. Туда можно еще кучу всяких отслеживаний событий для аналитикса засунуть, код для A/B тестирования и прочее.
Обычно всякие SEO агентства просят его установить, чтобы потом спокойно добавлять/убирать ява-скрипт, не прибегая к разработчикам.
Ну по факту он слегка кешируется, по мнению того PageSpeed. Но проблему с внешними скриптами никуда не убирает:
На момент запуска новой версии инструмента был опрос, какие внешние скрипты надо убрать (аналитика, метрика и т.д.), и что собрали, было убрано. Сейчас наверное что-то заглючило, что снова эти скрипты всплыли в проверке PSI и SearchPanel. Не стоит обращать внимания.
Sign up to leave a comment.
100 из 100 в Google PageSpeed Insights (Баг или фича)?