В этой всей движухе с Apple почему-то никто не говорит об очень важном ньюансе. Закрытость их архитектуры позволила добиться победы над пиратским ПО. Как результат — разработчики приложений получают все деньги, никто не взламывает и не распространяет нелегально их продукты. Именно поэтому разработка под Apple выгодней, чем под Android.
И это преимущество пропадет, как только их вынудят разблокировать установку приложений из третьих источников.
То есть, основные баллы отжирают соц-кнопки. А удалось надежно замерить эффект от метрик/аналитик?
А по скриншотам — это правильно. Иначе бы обходили для накрутки баллов отложенной загрузкой контента через 2-3 секунды после показа страницы, а страдали бы посетители.
Ну, если бы вся страница до конца загружалась за 1,3 сек, у вас бы было 100 баллов.
Сейчас главная проблема, что нет стабильного измерителя — на PageSpeed Insights баллы скачут, у меня на ноуте в Хроме — тоже (возможно, от нагрева и троттлинга). Я планирую чуть попозже поднять на DigitalOcean машину с консольным Litehouse, посмотреть как будет там.
А с таким шумом оценок, тяжело оценить эффект от мелких изменений (типа выкидывания аналитики или шрифтов), просто невозможно понять, дают они что-то или доли балла.
Я пока что «на уровне Ванги» рекомендую:
Однозначно делать различные версии для мобильных и десктопа (хоть на разных шаблонах, хоть на ifах)
Выкидывать по возможности весь внешний визуальный обвес сторонних сервисов — по крайней мере, пока они не начнут всапываться в то, чтобы делать его легким
В особо критичных ситуациях можно делать загрузку комментов/карт/социалок в момент, когда до них доскроллят, что в принципе разумно со всех сторон.
Карты можно вставлять простыми картинками, которые по клику переходят к странице с картой.
Не знаю как кого, а меня все эти выпрыгивающие живочаты всю дорогу бесили. Я бы делал простую кнопку, которая переносит на страницу с чатом, или хотя бы загружает чат уже после нажатия.
Попапы и извещения всякие только при острой необходимости, особенно в мобильном варианте. Дико бесит, когда приходишь куда-то из гугла, а там лезет попап на 2/3 экрана — вот как раз, еще не увидел что у вас есть, а уже подпишусь и лайкну.
Предупреждение о cookie — выключаем, если вы не под жесткими законодательными требованиями (находитесь юридически в Евросоюзе)
Уменьшать количество элементов DOM на странице, особенно на мобильной — никаких ветвистых вложенных меню, товаров/анонсов статей на 10 экранов вниз и т. д.
Картинки, аналитики, веб-шрифты, CSS — по моему мнению — не особо влияют на скорость, по сравнению с вышеперечисленным. Их я бы не трогал.
И да, AMP дико рулит, безотносительно PageSpeed. Я, если вижу в выдаче поиска молнийку, нажимаю в первую очередь. Потому что знаю, что откроется мгновенно и будет без свистелок, сразу к сути. Думаю, я такой не один. И нет там минусов, кроме необходимости приложить чуть усилий.
Модуль pagespeed для серверов и раньше был таким себе решением, а теперь он совсем неактуален, можно без колебаний его отключать.
Рекомендации имеют мало общего с баллами. Основной посыл нового PageSpeed Insights — делайте мобильные страницы легче, до минимализма. Что, в принципе, правильно — где десктоп чуть поморщится, смартфон уже кучу заряда потратит на загрузку и обработку.
Реально реализовали все рекомендации Lighthouse?
Расскажите пожалуйста, реализация каких из них улучшила баллы, каких — нет. И действительно ли вы получали от них выгоду, близкую к обещаной.
Это правда, рекомендации очень далеки от того, что реально поможет. Лучше всего помогает уменьшать количество элементов на странице и отказываться от всякого интерактивного обвеса типа социалок и карт.
Пока не прикроют старое API, скачать оптимизированные ресурсы можно на speed.devs.mx.
Я работаю с интернет-магазинами, страницы чаще всего тяжелые, включают и CSS, и JS вставки. На моем опыте минификация такой средней html-страницы занимает около 100мс — что и не странно, учитывая, что надо лексически анализировать HTML, CSS и JS для корректной минификации.
Если у вас есть другие замеры времени мифиникации HTML — не стесняйтесь, озвучивайте.
А дальше происходит такая история — HTML сжимается GZIP и выгода он минификации уменьшается в несколько раз, так как ZIP очень хорошо ужимает все эти пробелы и переводы строк.
В результате, для сжатой страницы размером 60 кб вы получаете после минификации 55 кб — что в принципе практически незаметно при загрузке — потому как основные расходы для файла такого размера — это установить соединение, начать загрузку и т. д. Но при этой минификации браузер получает ответ на 100 мс позже, и это очень дорогое время — так как вся паралельная обработка и загрузка начнется только когда будет получен этот ответ.
А примеров плохого применения рекомендаций полно:
pagespeed_mod, который делал красивые очки, но при этом становился посредником между сервером и клиентом, анализируя каждый отправляемый html, проверяя все упомянутые в нем ресурсы, что внушительно ухудшало TTFB
отложенная загрузка JavaScript, что приводило к тому, что страница значительно дольше приходила в себя после загрузки — хотя реальный результат был значительно лучше, если просто сложить скрипты в футер
включение critical CSS в тело каждой страницы, хотя он бы мог загружаться из кеша при дальнейшей навигации по сайту, если бы лежал в отдельном файле
требование о соответствии реального размера изображений показываемому размеру, хотя есть немало случаев, когда это необходимо нарушить — например, если картинка увеличивается при наведении. Пару картинок такого типа было достаточно, чтобы просесть в оценке пунктов на 30
Я имел ввиду панику, которую поднимут люди тяжелых сайтов, заточенных ранее на хорошие показатели.
На моем сервисе speed.devs.mx пока еще можно скачать Magic ZIP для вашего сайта — это переформатированный архив оптимизированных ресурсов с гугла, который содержит также оригиналы и готов к простому накатыванию на сайт по FTP.
На моем опыте все варианты с отложенной загрузкой модулей и lazy-loadом картинок реально замедляют финальную готовность страницы. Нужны эксперименты, но мне кажется что будет побеждать стратегия «грузим все по простому».
Только надо дождаться, когда оценивать будет стабильно, а то пока разброс не дает почувствовать разницу )
Кстати, есть одна мысль. Базу ведь можно выкачивать периодически и делать оценки по динамике.
Как пример, банально:
— акк, который за месяц не набрал ни одного друга, быстрее всего бот.
— акк, который набирает друзей со скоростью пылесоса (установить порог) — врядли знает их в реале.
Мне невольно довелось перелопатить все руководства подобного толка в поисках решения проблем. Но согласен, «самое полное» звучит несколько вызывающе…
Работа с ADT-компилятором через консоль очень уж муторная — вызов с ключами занимает 3 полные строки. Утилита ADT Helper, упоминание о которой я добавил в конце статьи, имеет интерфейс и функционал не хуже родного Flash'евского и требует только AIR SDK. Спасибо за напоминание об этом факте, докинул его в статью.
У меня через «brew install yurikoles/yurikoles/far2l --HEAD» не ставится, может где-то есть обычный пакет?
И это преимущество пропадет, как только их вынудят разблокировать установку приложений из третьих источников.
А по скриншотам — это правильно. Иначе бы обходили для накрутки баллов отложенной загрузкой контента через 2-3 секунды после показа страницы, а страдали бы посетители.
Сейчас главная проблема, что нет стабильного измерителя — на PageSpeed Insights баллы скачут, у меня на ноуте в Хроме — тоже (возможно, от нагрева и троттлинга). Я планирую чуть попозже поднять на DigitalOcean машину с консольным Litehouse, посмотреть как будет там.
А с таким шумом оценок, тяжело оценить эффект от мелких изменений (типа выкидывания аналитики или шрифтов), просто невозможно понять, дают они что-то или доли балла.
Я пока что «на уровне Ванги» рекомендую:
Рекомендации имеют мало общего с баллами. Основной посыл нового PageSpeed Insights — делайте мобильные страницы легче, до минимализма. Что, в принципе, правильно — где десктоп чуть поморщится, смартфон уже кучу заряда потратит на загрузку и обработку.
Расскажите пожалуйста, реализация каких из них улучшила баллы, каких — нет. И действительно ли вы получали от них выгоду, близкую к обещаной.
Пока не прикроют старое API, скачать оптимизированные ресурсы можно на speed.devs.mx.
Если у вас есть другие замеры времени мифиникации HTML — не стесняйтесь, озвучивайте.
А дальше происходит такая история — HTML сжимается GZIP и выгода он минификации уменьшается в несколько раз, так как ZIP очень хорошо ужимает все эти пробелы и переводы строк.
В результате, для сжатой страницы размером 60 кб вы получаете после минификации 55 кб — что в принципе практически незаметно при загрузке — потому как основные расходы для файла такого размера — это установить соединение, начать загрузку и т. д. Но при этой минификации браузер получает ответ на 100 мс позже, и это очень дорогое время — так как вся паралельная обработка и загрузка начнется только когда будет получен этот ответ.
А примеров плохого применения рекомендаций полно:
А так да, скорость сайта в общих понятиях влияет на рейтинг в поисковиках.
На моем сервисе speed.devs.mx пока еще можно скачать Magic ZIP для вашего сайта — это переформатированный архив оптимизированных ресурсов с гугла, который содержит также оригиналы и готов к простому накатыванию на сайт по FTP.
Только надо дождаться, когда оценивать будет стабильно, а то пока разброс не дает почувствовать разницу )
Как пример, банально:
— акк, который за месяц не набрал ни одного друга, быстрее всего бот.
— акк, который набирает друзей со скоростью пылесоса (установить порог) — врядли знает их в реале.
Работа с ADT-компилятором через консоль очень уж муторная — вызов с ключами занимает 3 полные строки. Утилита ADT Helper, упоминание о которой я добавил в конце статьи, имеет интерфейс и функционал не хуже родного Flash'евского и требует только AIR SDK. Спасибо за напоминание об этом факте, докинул его в статью.