Комментарии 40
Да, спасибо, удобно. Однако, некоторые вещи непонятны:
Едва ли загруженная картинка важнее работающей вкладки?
Т.е. Google советует ссылки не делать для мобильных устройств?
Как Google поймет, что есть замена? Какой нужно код конкретно написать?
Удалите из верхней части страницы код JavaScript и CSS, блокирующий отображение.
ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js
Едва ли загруженная картинка важнее работающей вкладки?
Высота текстового фрагмента «18 117» на экране составляет всего 4 пикс. (14 CSS-пикс.). открыть скриншот
Т.е. Google советует ссылки не делать для мобильных устройств?
Найдите замену следующим плагинам Flash.
Как Google поймет, что есть замена? Какой нужно код конкретно написать?
Едва ли загруженная картинка важнее работающей вкладки?
JavaScript можно всегда опустить в самый низ, особенно если он работает по событию ready(). А вот CSS опускать в самый низ по моему бредово. На секунду (или больше, если пропускная способность канала у пользователя не высокая), пользователь видит «голый» html, без стилизации. Возможно имело бы смысл дать рекомендацию вынести весь CSS, кроме основной разметки макета, в нижнюю часть страницы, да только никто так не будет делать.
Как Google поймет, что есть замена? Какой нужно код конкретно написать?
Flash уже не актуален. Есть CSS3 / WebGL / Canvas. Они меньше весят и легче внедряются.
p.s. developers.google.com/speed/pagespeed/insights/?hl=ru&utm_source=blogspot&utm_campaign=mobile_ux&url=google.ru&tab=mobile
p.s. появилась мысль на счет CSS. Во время исполнения серверного кода, можно импортировать CSS в тег style напрямую в head. Тогда не будет ругаться
Flash уже не актуален. Есть CSS3 / WebGL / Canvas. Они меньше весят и легче внедряются.
Я другой вопрос задавала. И Flash пока еще как актуален, несмотря на вышеперечисленные технологии.
p.s. появилась мысль на счет CSS. Во время исполнения серверного кода, можно импортировать CSS в тег style напрямую в head. Тогда не будет ругаться
Прощай повторное использование стилей? В целом подход имеет право на жизнь, первый раз загрузку он ускорит, зато все последующие разы замедлит.
JavaScript можно всегда опустить в самый низ, особенно если он работает по событию ready().
Написала ниже.
Я другой вопрос задавала. И Flash пока еще как актуален, несмотря на вышеперечисленные технологии.
Приведите пример пожалуйста.
На мой взгляд тенденция развития веба сильно разнится с Flash-технологиями, из-за чего он и теряет актуальность.
Прощай повторное использование стилей?
Почему же? Что мешает использовать стили повторно, изменив метод их загрузки на страницу? Проанализировав код главной страницы google, я сделал вывод, что именно так они и делают.
Приведите пример пожалуйста.
На мой взгляд тенденция развития веба сильно разнится с Flash-технологиями, из-за чего он и теряет актуальность.
Вы говорили о настоящем времени, а теперь про тенденцию развития. Это разные вещи.
Да, когда тысячи разработчиков переучатся с Flash на что-то другое и старые браузеры канут в лету (меньше 1%) — ваша фраза про неактуальность Flash станет актуальной.
Почему же? Что мешает использовать стили повторно, изменив метод их загрузки на страницу? Проанализировав код главной страницы google, я сделал вывод, что именно так они и делают.
Т.е. хранить стили вместо файлов локально, в localStorage? Ничего не мешает, только в чем смысл? Обновлять их нужно точно также, посылая запрос к серверу о необходимости изменений. Или я тут чего-то не понимаю, тогда объясните, пожалуйста.
Я понял в чем дело. Мы с вами на разных языках говорим. Для меня использование стилей повторно — это их использование в разметке, а хранение стилей на клиенте это браузерный кэш, для Вас, видимо, все по другому. Ну да ладно.
Действительно при импорте стилей в тег style последующие хиты будут работать помедленнее, чем при подходе с файлами и это не даст общей оптимизации ресурса. С другой стороны всегда есть минификация «на лету».
Не вижу никакого смысла применять сейчас Flash (Вы обратное доказать не можете), никогда не видел задачи, с которой не может справиться HTML5, а Flash может (я говорю про реальные задачи, которые продаются на рынке веб-разработки). К тому же, я не видел в профессиональной разработке «тысячи разработчиков», которые создают сайты на Flash и тем более в портфолио у таких людей Flash не значится.
На мой взгляд, Flash это такая же заноза, как и верстка через ID. Сотни компаний по всей России (причем из топ-10 в РР) продают каждый год по два десятка сайтов сверстанных по ID и без компонентной структуры, код, который невозможно поддерживать (не говоря уже про серверную часть). То же самое и с Flash сайтами и плагинами. И что теперь? Будем считать что не компонентная верстка через контекст идентификаторов это хорошо, потому что 90% специалистов так делают, или будем считать что Flash все еще актуален потому что люди учились на нем работать? Я знаю специалистов которые до сих пор таблицами верстают и на div переходить не собираются. Их тоже припишем к актуальным или нет?
Действительно при импорте стилей в тег style последующие хиты будут работать помедленнее, чем при подходе с файлами и это не даст общей оптимизации ресурса. С другой стороны всегда есть минификация «на лету».
Вы говорили о настоящем времени, а теперь про тенденцию развития. Это разные вещи.
Да, когда тысячи разработчиков переучатся с Flash на что-то другое и старые браузеры канут в лету (меньше 1%) — ваша фраза про неактуальность Flash станет актуальной.
Не вижу никакого смысла применять сейчас Flash (Вы обратное доказать не можете), никогда не видел задачи, с которой не может справиться HTML5, а Flash может (я говорю про реальные задачи, которые продаются на рынке веб-разработки). К тому же, я не видел в профессиональной разработке «тысячи разработчиков», которые создают сайты на Flash и тем более в портфолио у таких людей Flash не значится.
На мой взгляд, Flash это такая же заноза, как и верстка через ID. Сотни компаний по всей России (причем из топ-10 в РР) продают каждый год по два десятка сайтов сверстанных по ID и без компонентной структуры, код, который невозможно поддерживать (не говоря уже про серверную часть). То же самое и с Flash сайтами и плагинами. И что теперь? Будем считать что не компонентная верстка через контекст идентификаторов это хорошо, потому что 90% специалистов так делают, или будем считать что Flash все еще актуален потому что люди учились на нем работать? Я знаю специалистов которые до сих пор таблицами верстают и на div переходить не собираются. Их тоже припишем к актуальным или нет?
Не вижу никакого смысла применять сейчас Flash (Вы обратное доказать не можете), никогда не видел задачи, с которой не может справиться HTML5
Ну вы игнорируете мой аргумент про поддержку HTML5. Эта дискуссия ведется по поводу каждой новой технологии, которая лучше предыдущей, но пока всеми не поддерживается.
Да, IE6 был занозой и очень большой и много лет, но те тысячи пользователей у которых он стоял того стоили (спросите у Интернет-магазинов).
И еще раз обращу ваше внимание, что вопрос мой был задан про другое. А конкретно, как сделать так, чтобы Google понял, что в браузерах не поддерживающих Flash у меня есть замена, а в тех, что не поддерживают HTML5 — Flash.
А то пока получается какая-то корпоративная борьба за мой счет.
это не помогает?
Наверное помогает, но это опять противоречит советам Google. JS должен грузиться после DOM. И если я хочу Flash в интерфейсе, то облом.
А кому нужен Flash на мобильных девайсах ( вы не забывайте что статья про оптимизацию под мобильные девайсы)? Вы о чем? Apple iOS и Windows Phone — с самого рождения не поддерживают Flash. Google Chrome под Android перестал поддерживать Flash ( или изначально не поддерживал ). Google вам мягко намекает что даже им уже Flash не интересен. И они вас просят не подключать замену Flash — а выкинуть Flash и использовать HTML5
И они вас просят не подключать замену Flash — а выкинуть Flash и использовать HTML5
Очень часто нужно на десктопе показывать анимацию, а на мобильном просто картинку и не всегда мобильная версия — это отдельная версия сайта. С адаптивным дизайном это чаще может быть один код. И не всегда есть возможность тонко настраивать что отдавать на клиент. Соглашусь, это скорее моя проблема, но к примеру тег noscript когда-то здорово выручал.
Я с вами согласен. Данный инструмент ( PageSpeed Analizer ) далек от совершенства — мало того они навязывают свое видение «быстрого и качественного» сайта (аргументированно — но всеже). Я к тому что Flash ( по их мнению ) уже туда не входит. Когда они говорят «найдите замену» — они фактически говорят «удалите флеш» :/
тогда начинает ругаться, что размер страница до основного содержимого слишком большой. Советы Page Speed здесь противоречат друг другу
Скорее всего он имел ввиду «перенесите скрипты вниз, поставив их перед закрывающим тегом body». В таком случае, браузер загрузит почти все дом-дерево, попутно его отрисовывая, иначе он сначала целиком грузит скрипты и выполнит их, не отрисовывая страницу, да и вообще ничего больше не делая. В интернете много информации по этому поводу, с наскока правда более менее полной статьи не нашел, чтобы привести тут, но чуть подробнее описано здесь и на stackoveflow.
CSS, правда, принято поднимать максимально высоко, да и не блокирует он ничего.
CSS, правда, принято поднимать максимально высоко, да и не блокирует он ничего.
CSS пока не умеет загружаться асинхронно с DOM. Когда браузер встречает тег link, он начинает загрузку CSS с отдельным HTTP запросом к серверу, прерывая загрузку оставшейся страницы. Получается что, чем больше файлов подключено в head, тем больше запросов на сервер, тем больше скорость приложения зависит от сервера. Это, конечно, в нынешнем мир, измеряется милисекундами, но все же полезно, особенно когда файлов много.
JСкорее всего он имел ввиду «перенесите скрипты вниз, поставив их перед закрывающим тегом body»
Я поняла, что он имел ввиду! Но меня лично ужасно бесит когда элементы уже прогрузились, но ничего не работает. Зато картинку видать…
В таком случае, браузер загрузит почти все дом-дерево, попутно его отрисовывая, иначе он сначала целиком грузит скрипты и выполнит их, не отрисовывая страницу, да и вообще ничего больше не делая.
Ну и что плохого? Сначала грузим JQuery, затем элемент, затем сразу после появления элемента навешиваем на него события (а для этого, например, нужно JQuery).
Просто принято считать, что людям не нравится смотреть на белый экран и не видеть прогресса, в отличие от случая когда видно, как страница подгружается. Браузер в любом случае показывает когда загрузка окончена и со страницей можно взаимодействовать.
На самом деле зависит от сайта. Если я зашел за информацией, то мне не нужны комментарии и прочее, мне нужна там самая картинка и текст. Если мы говорим о приложении, то естественно имеет смысл сначала все подгрузить, но и в этом случае, расположив скрипты снизу, можно показав прелоадер одновременно и заблокировать оверлеем действия со страницей и уведомить человека о том, что все по плану. В отличие опять же, от случая, если мы в веб-приложении переместили все скрипты вверх, и раз это приложение, то их много, и все время их загрузки и инициализации мы видим просто белый экран.
На самом деле зависит от сайта. Если я зашел за информацией, то мне не нужны комментарии и прочее, мне нужна там самая картинка и текст. Если мы говорим о приложении, то естественно имеет смысл сначала все подгрузить, но и в этом случае, расположив скрипты снизу, можно показав прелоадер одновременно и заблокировать оверлеем действия со страницей и уведомить человека о том, что все по плану. В отличие опять же, от случая, если мы в веб-приложении переместили все скрипты вверх, и раз это приложение, то их много, и все время их загрузки и инициализации мы видим просто белый экран.
В отличие опять же, от случая, если мы в веб-приложении переместили все скрипты вверх, и раз это приложение, то их много, и все время их загрузки и инициализации мы видим просто белый экран.
можно показав прелоадер одновременно и заблокировать оверлеем действия со страницей и уведомить человека о том, что все по плану.
Ну и что мешает прогрузить прелоадер, затем прогрузить JS, а затем всю оставшуюся страницу?
Зачем мне прогружать нерабочий интерфейс?
Если я зашел за информацией, то мне не нужны комментарии и прочее, мне нужна там самая картинка и текст.
Таких сайтов все меньше и будет еще меньше, но и тут ничто не мешает подгрузить основной текст картинку, потом скрипт и весь остальной интерфейс.
Зачем мне прогружать нерабочий интерфейс?
Очень не красиво строить веб-приложение, интерфейс которого зависит от JS. Хорошей практикой и хорошим тоном считается разрабатывать рабочее приложение и для устройств с выключенным JS. Если же с выключенным JS Ваше приложение разъезжается в разные стороны — это плохо, в конце концов клиент может что то не отработать в 1 случае из 100.
Показывать прелоадер, если скрипты в head находятся до их загрузки не получится, так как body еще не будет. Еще раз: скрипты в head блокируют и отображение и загрузку всего, что после них, а так как они в head, до их загрузки прелоадер не показать, только после. Показать можно, если разместить их в body, но тут опять же непонятно, почему их не опустить еще ниже.
У вас просто странная позиция
Вы все ровно до события dom-ready не сможете его сделать рабочим. Даже если скрипты в шапке, то они подгрузятся, выполнятся, но что-то делать с интерфейсом будут только после того как он подгрузится и браузер кинет событие dom-ready.
Отличие в итоге только в том, что у вас человек видит белый экран во время загрузки скриптов, вместо того, чтобы видеть загрузку страницы.
У вас просто странная позиция
Зачем мне прогружать нерабочий интерфейс?
Вы все ровно до события dom-ready не сможете его сделать рабочим. Даже если скрипты в шапке, то они подгрузятся, выполнятся, но что-то делать с интерфейсом будут только после того как он подгрузится и браузер кинет событие dom-ready.
Отличие в итоге только в том, что у вас человек видит белый экран во время загрузки скриптов, вместо того, чтобы видеть загрузку страницы.
Показать можно, если разместить их в body, но тут опять же непонятно, почему их не опустить еще ниже.
Потому что элементы будут прогружаться постепенно. И события на них я навешиваю постепенно, по мере их загрузки.
В итоге, у меня нет нерабочих элементов.
Вы все ровно до события dom-ready не сможете его сделать рабочим.
Конечно смогу и всегда это делаю.
На самом деле интересно, но мне кажется, что у вас есть какой-то тонкий момент, иначе непонятно, как вы это делаете.
Если взять сценарий, допустим у меня скрипы в head, а в body, есть три секции, в первой менюшка, во второй основной интерфейс, в последней пусть будут комментарии.
Вы говорите, что
Как вы узнаете, что меню подгрузилось, чтобы его оживить? Раз постепенно, это значит, что события вы вешаете до загрузки основной секции и последней.
Можно, конечно, после каждой секции ставить тег script, но про это не было сказано, да и не хорошая это практика. У вас есть какой-то другой способ?
Если вы собираете интерфейс с помощью js, или что-то подгружаете асинхронно, то это другое дело.
Если взять сценарий, допустим у меня скрипы в head, а в body, есть три секции, в первой менюшка, во второй основной интерфейс, в последней пусть будут комментарии.
Вы говорите, что
Потому что элементы будут прогружаться постепенно. И события на них я навешиваю постепенно, по мере их загрузки.
Как вы узнаете, что меню подгрузилось, чтобы его оживить? Раз постепенно, это значит, что события вы вешаете до загрузки основной секции и последней.
Можно, конечно, после каждой секции ставить тег script, но про это не было сказано, да и не хорошая это практика. У вас есть какой-то другой способ?
Если вы собираете интерфейс с помощью js, или что-то подгружаете асинхронно, то это другое дело.
Можно, конечно, после каждой секции ставить тег script, но про это не было сказано, да и не хорошая это практика.
Аргументы в студию. У меня есть основной framework и блоки.
После загрузки каждого блока вызывается загрузка блока именно тегом script. Упрощенно, что-то вроде
block.load();
Если вы собираете интерфейс с помощью js, или что-то подгружаете асинхронно, то это другое дело.
При загрузке блока это происходит в том числе.
В отличие от вопроса простого позиционирования скриптов, где суммарное время загрузки одно и тоже и разница чисто визуальная, здесь время загрузки увеличиться в общем случае.
Скрипты блокируют вообще все на время своего исполнения, в итоге, те же самые картинки, которые могли бы группироваться для паралелльной загрузки, обычно это 2-6 потоков, смогут объединяться только по секциям, в итоге очередей будет больше, а значит и время загрузки.
Для примера, у вас по две картинки в трех секциях, хром мог бы загрузить их все параллельно, вместо этого, они будут грузиться последовательно тремя группами по две штуки.
Чуть подробнее есть у тут, статья хоть и старая, но проблема в ней описана.
Скрипты блокируют вообще все на время своего исполнения, в итоге, те же самые картинки, которые могли бы группироваться для паралелльной загрузки, обычно это 2-6 потоков, смогут объединяться только по секциям, в итоге очередей будет больше, а значит и время загрузки.
Для примера, у вас по две картинки в трех секциях, хром мог бы загрузить их все параллельно, вместо этого, они будут грузиться последовательно тремя группами по две штуки.
Чуть подробнее есть у тут, статья хоть и старая, но проблема в ней описана.
Это все решается и очень просто. Если нужно поместить загрузку картинок в параллельную загрузку, то можно грузить их в фоне в невидимости (в том числе и асинхронными скриптами). А если речь о картинках для оформления, то их вообще суют в спрайты, значит опять не наша тема.
Конечно, только время выполнения синхронных скриптов настолько мало, что при нормальной архитектуре — говорить об этом бессмысленно.
Скрипты блокируют вообще все на время своего исполнения, в итоге,
Конечно, только время выполнения синхронных скриптов настолько мало, что при нормальной архитектуре — говорить об этом бессмысленно.
Есть шапка с аватаркой залогиненного пользователя и фоном, который из спрайта со всеми остальными картинками интерфейса, две картинки в статье и две в комментариях. В обычном случае, это все грузится параллельно в шесть потоков, в вашем из-за блокировок разделяется на три группы в два потока.
Ваше решение, это заранее узнать, что за картинки и подгрузить в невидимости. Такой подход может быть оправдан только в каком-то специальном случае, но тогда понятно почему советы универсального инструмента от гугл вам не подходят.
Ваше решение, это заранее узнать, что за картинки и подгрузить в невидимости. Такой подход может быть оправдан только в каком-то специальном случае, но тогда понятно почему советы универсального инструмента от гугл вам не подходят.
Каких блокировок то?
Есть код webkit допустим, который загружает DOM и отображает его визуально. В том числе у HTML-элементов есть события onclick, которые навешиваются сразу при загрузке этого элемента.
JavaScript в чуть более удобном виде позволяет навесить эти события на загружаемый элемент или изменить визуальный вид, точно так же как webkit.
Логика не меняется, ровно те же «блокировки», что и у самого движка.
И еще раз повторю, в нормальной системе те миллисекунды, нужные для обработки синхронных операций с DOM и Events даже разговора о них не стоят.
Что происходит у меня:
1. Грузится шапка, начинает грузиться аватарка и фон.
2. Выполняется max 100мс JS, при этом все элементы из шапки становятся активными, а пользователь только шапку и видит.
3. Грузится статья и ее фотки.
4. Выполняется max 100мс JS, после чего все элементы статьи активны. а пользователь ее видит.
5. Грузятся фотки из комментариев
и т.д.
Не вижу ни одной причины почему пользователь должен заиметь фотку из комментария, которую он еще нескоро увидит раньше, чем работоспособные элементы из шапки и статьи, которую он видит сразу…
Ничего хорошо в загрузке в 100 потоков всех фоток на странице я тоже не вижу. До которых пользователь может вовсе не доскролить.
Есть код webkit допустим, который загружает DOM и отображает его визуально. В том числе у HTML-элементов есть события onclick, которые навешиваются сразу при загрузке этого элемента.
JavaScript в чуть более удобном виде позволяет навесить эти события на загружаемый элемент или изменить визуальный вид, точно так же как webkit.
Логика не меняется, ровно те же «блокировки», что и у самого движка.
И еще раз повторю, в нормальной системе те миллисекунды, нужные для обработки синхронных операций с DOM и Events даже разговора о них не стоят.
Что происходит у меня:
1. Грузится шапка, начинает грузиться аватарка и фон.
2. Выполняется max 100мс JS, при этом все элементы из шапки становятся активными, а пользователь только шапку и видит.
3. Грузится статья и ее фотки.
4. Выполняется max 100мс JS, после чего все элементы статьи активны. а пользователь ее видит.
5. Грузятся фотки из комментариев
и т.д.
Не вижу ни одной причины почему пользователь должен заиметь фотку из комментария, которую он еще нескоро увидит раньше, чем работоспособные элементы из шапки и статьи, которую он видит сразу…
Ничего хорошо в загрузке в 100 потоков всех фоток на странице я тоже не вижу. До которых пользователь может вовсе не доскролить.
Конечно смогу и всегда это делаю.
С учетом выше сказанного, а так же использование исключительно jQuery. Могу догадываться только что тег script лежит сразу после каждой секции.
jQuery может выполняться синхронно только в том случае, если dom уже загружен (или по крайней мере необходимый элемент). В противном случае вызывается callback после ready или load.
На сколько хорош хабр по мнению PageSpeed Insights?
— developers.google.com/speed/pagespeed/insights/?hl=ru&utm_source=blogspot&utm_campaign=mobile_ux&url=http%3A%2F%2Fhabrahabr.ru%2F&tab=mobile
— developers.google.com/speed/pagespeed/insights/?hl=ru&utm_source=blogspot&utm_campaign=mobile_ux&url=http%3A%2F%2Fhabrahabr.ru%2Fcompany%2Fsibirix%2Fblog%2F223501%2F&tab=mobile
— developers.google.com/speed/pagespeed/insights/?hl=ru&utm_source=blogspot&utm_campaign=mobile_ux&url=http%3A%2F%2Fhabrahabr.ru%2F&tab=mobile
— developers.google.com/speed/pagespeed/insights/?hl=ru&utm_source=blogspot&utm_campaign=mobile_ux&url=http%3A%2F%2Fhabrahabr.ru%2Fcompany%2Fsibirix%2Fblog%2F223501%2F&tab=mobile
Так смешнее: developers.google.com/speed/pagespeed/insights/?hl=ru&utm_source=blogspot&utm_campaign=mobile_ux&url=http%3A%2F%2Fdevelopers.google.com
Насколько оптимизирован developers.google.com.
Насколько оптимизирован developers.google.com.
Пожалуйста, добавьте рекомендацию про веб-шрифты.
Зачастую они весят в десятки раз больше самой страницы (50–400 Кб) и их загрузка требует значимого времени в условиях слабого 3G, EDGE или GPRS. Тем временем, браузер резервирует место, но не отображает текст, оформленный этим шрифтом.
Было бы хорошо рекомендовать оптимизацию или асинхронную загрузку веб-шрифтов.
Зачастую они весят в десятки раз больше самой страницы (50–400 Кб) и их загрузка требует значимого времени в условиях слабого 3G, EDGE или GPRS. Тем временем, браузер резервирует место, но не отображает текст, оформленный этим шрифтом.
Было бы хорошо рекомендовать оптимизацию или асинхронную загрузку веб-шрифтов.
Коллеги, инструмент хороший, пользуюсь давно, НО.
Но очень не хватает ему «человечности». В данном случае под человечностью я понимаю тот факт, что выдавать предупреждения нужно с долей здравого смысла.
Вот таких предупреждений я насмотрелся на куче сайтов.
Человек бы понял, что 2.4Кб это то ради чего не стоит волноваться.
Но очень не хватает ему «человечности». В данном случае под человечностью я понимаю тот факт, что выдавать предупреждения нужно с долей здравого смысла.
Вот таких предупреждений я насмотрелся на куче сайтов.
Человек бы понял, что 2.4Кб это то ради чего не стоит волноваться.
Предложение оптимизировать доставку единственного на весь сайт CSS-файла, 3.5 КБ в сжатом виде, выглядит странно.
Разбивать ассет и встраивать стили в документ, во-первых, глупо, потому как раздувается объем html (а на соседних страницах вы же сами даете советы по сокращению объема кода html), а во-вторых, статика — это как раз тот случай, когда яйца лучше хранить в одной корзине, особенно когда их немного.
Опять же, вы сами пишете: «если файл CSS слишком велик, после его встраивания PageSpeed Insights может вас предупредить, что верхняя часть страницы имеет слишком большой объем». В случае, например, с главной страницей Яндекса «42,8 КБ ответа необходимо для отображения верхней части страницы», но это убивает меньше попугаев, чем 10КБ внешнего css-файла.
Вопрос: учитывает ли ваш инструмент при оценке скорости события load и DOMContentLoaded? Я не нашел упоминания.
В целом инструмент хорош, но как и всегда, лучше использовать его вместе с другими подобными инструментами.
Разбивать ассет и встраивать стили в документ, во-первых, глупо, потому как раздувается объем html (а на соседних страницах вы же сами даете советы по сокращению объема кода html), а во-вторых, статика — это как раз тот случай, когда яйца лучше хранить в одной корзине, особенно когда их немного.
Опять же, вы сами пишете: «если файл CSS слишком велик, после его встраивания PageSpeed Insights может вас предупредить, что верхняя часть страницы имеет слишком большой объем». В случае, например, с главной страницей Яндекса «42,8 КБ ответа необходимо для отображения верхней части страницы», но это убивает меньше попугаев, чем 10КБ внешнего css-файла.
Вопрос: учитывает ли ваш инструмент при оценке скорости события load и DOMContentLoaded? Я не нашел упоминания.
В целом инструмент хорош, но как и всегда, лучше использовать его вместе с другими подобными инструментами.
Привет всем! Спасибо всем за комментарии, постараюсь ответить на некоторые из них.
В: Когда и как загружать JS?
O: Мы рекомендуем организовать загрузку ресурсов таким образом, чтобы часть контента “above the fold” загрузилась как можно быстрее (почти мгновенно), а потом уже грузить весь остальной контент.
В случае с сайтом donorsearch.ru, вы можете загрузить JS сразу после того как произойдет первый paint:
sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
Это обеспечит минимальную задержку; даже возможно, что элементы страницы активируются быстрее.
В:“1. Грузится шапка, начинает грузиться аватарка и фон.
2. Выполняется max 100мс JS, при этом все элементы из шапки становятся активными, а пользователь только шапку и видит.
3. Грузится статья и ее фотки.”
О: Проблема здесь в том, что “max 100мс JS” нельзя обеспечить. Здесь главное не скорость выполнения скрипта, а скорость мобильной сети. На мобильном телефоне скачивание даже пустого JS файла может добавить несколько сотен миллисекунд задержки из-за медленной сети.
В: «Т.е. Google советует ссылки не делать для мобильных устройств?»
О: Совсем нет. Мы не делаем рекоммендации для конкретного количества ссылок на мобильном сайте. Для нас самое важное, чтобы их было легко прочитать и открыть пальцем. В данном конкретном случае, кажется, это нельзя сделать.
В: «Как Google поймет, что есть замена? Какой нужно код конкретно написать?»
О: PageSpeed Insights не может знать, что контент не во всех случаях грузится если он находится в DOM, поэтому отмечает этот плагин. В данном случае можете использовать скрипт, который будет добавлять плагин в DOM только в случаях, когда поддерживается Flash, а еще лучше – заменить его файлом GIF.
В:
«Действительно при импорте стилей в тег style последующие хиты будут работать помедленнее, чем при подходе с файлами и это не даст общей оптимизации ресурса.»
О: Мы рекоммендуем разместить очень малую часть CSS непосредственно в коде, а для остального использовать async stylesheet.
В:
«Человек бы понял, что 2.4Кб это то ради чего не стоит волноваться.»
О: Мы пока ищем самый оптимальный порог оптимизации, для которого показываем предупреждения. Проценты не самый хороший способ измерять полезность улучшений. Если у вас есть предложения по этому поводу, поделитесь с нами! Например, если вы можете удалить 1Мб из 100 мегабайтовой страницы, это стоит ваших усилий, даже если это только 1%. В конкретном случае, 2.4Kб, кажется, даёт значительное улучшение
В: Когда и как загружать JS?
O: Мы рекомендуем организовать загрузку ресурсов таким образом, чтобы часть контента “above the fold” загрузилась как можно быстрее (почти мгновенно), а потом уже грузить весь остальной контент.
В случае с сайтом donorsearch.ru, вы можете загрузить JS сразу после того как произойдет первый paint:
sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
Это обеспечит минимальную задержку; даже возможно, что элементы страницы активируются быстрее.
В:“1. Грузится шапка, начинает грузиться аватарка и фон.
2. Выполняется max 100мс JS, при этом все элементы из шапки становятся активными, а пользователь только шапку и видит.
3. Грузится статья и ее фотки.”
О: Проблема здесь в том, что “max 100мс JS” нельзя обеспечить. Здесь главное не скорость выполнения скрипта, а скорость мобильной сети. На мобильном телефоне скачивание даже пустого JS файла может добавить несколько сотен миллисекунд задержки из-за медленной сети.
В: «Т.е. Google советует ссылки не делать для мобильных устройств?»
О: Совсем нет. Мы не делаем рекоммендации для конкретного количества ссылок на мобильном сайте. Для нас самое важное, чтобы их было легко прочитать и открыть пальцем. В данном конкретном случае, кажется, это нельзя сделать.
В: «Как Google поймет, что есть замена? Какой нужно код конкретно написать?»
О: PageSpeed Insights не может знать, что контент не во всех случаях грузится если он находится в DOM, поэтому отмечает этот плагин. В данном случае можете использовать скрипт, который будет добавлять плагин в DOM только в случаях, когда поддерживается Flash, а еще лучше – заменить его файлом GIF.
В:
«Действительно при импорте стилей в тег style последующие хиты будут работать помедленнее, чем при подходе с файлами и это не даст общей оптимизации ресурса.»
О: Мы рекоммендуем разместить очень малую часть CSS непосредственно в коде, а для остального использовать async stylesheet.
В:
«Человек бы понял, что 2.4Кб это то ради чего не стоит волноваться.»
О: Мы пока ищем самый оптимальный порог оптимизации, для которого показываем предупреждения. Проценты не самый хороший способ измерять полезность улучшений. Если у вас есть предложения по этому поводу, поделитесь с нами! Например, если вы можете удалить 1Мб из 100 мегабайтовой страницы, это стоит ваших усилий, даже если это только 1%. В конкретном случае, 2.4Kб, кажется, даёт значительное улучшение
Здравствуйте. Есть рекомендация настроить область просмотра.
При этом, при:
Объясните это противоречие, пожалуйста.
P.s. Кстати, кто будет с этим тегом работать, рекомендую ещё максимальный масштаб задавать атрибутом «maximum-scale=1», а то по умолчанию сайт может очень сильно растягиваться и корёжится на устройствах с небольшим экраном.
А вообще инструмент неплохой, если его умело использовать, конечно.
При этом, при:
<meta name=viewport content="width=device-width, initial-scale=1"> сайт в область просмотра не влезает, и рекомендация не пропадает. А если сделать initial-scale меньше единицы, то сайт открывается мелким и приходится зумить, что есть спорный момент.Объясните это противоречие, пожалуйста.
P.s. Кстати, кто будет с этим тегом работать, рекомендую ещё максимальный масштаб задавать атрибутом «maximum-scale=1», а то по умолчанию сайт может очень сильно растягиваться и корёжится на устройствах с небольшим экраном.
А вообще инструмент неплохой, если его умело использовать, конечно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как оптимизировать сайт для мобильных устройств с помощью PageSpeed Insights