Pull to refresh

Comments 19

Есть информация — насколько сильно это повлияет на продвижение?
Это критически важно для факта наличия в мобильной выдаче. При 60-80 баллах могут вообще убрать из выдачи (и информацию об этом присылают вебмастеру)
UFO landed and left these words here
Этот гугл странный, прежде чем нагонять страху, начал бы сначала с себя:



А это вообще «класс»:

тыц


Причём одинаково, как с десктопа, так и с мобильного.

То ли дело «я»:

тыц


4 пункта отжирают сторонние скрипты.
CSS нужно подгружать скриптами, сами скрипты перенести в футер


Это что-то новенькое!
Оказалось, что 2800 картинок можно скачать с сервера, прогнать через веб-интерфейс Tinygrab, и закачать обратно всего за 4 часа. После этого был установлен плагин tinygrab, который жмет все загружаемые изображения PNG и JPEG, до 500 картинок в месяц бесплатно.


Ручками перегоняли через веб-интерфейс?

Плагин «tinygrab» в репозитории Wordpress плагинов почему-то не находится.

Ну и раз уж есть доступ с серверу, то проще пройтись по всем изображениям чем-то типа «jpegoptim» с параметрами на свой вкус и цвет, чтобы обработать все картинки без сторонних сервисов и не за 4 часа.
«К серверу» имеется в виду простой ftp-доступ, обычный шаред.
Но спасибо за наводку.
есть замечательный плагин EWWW Image Optimizer. И еще Imsanity может пригодиться. Оба — фри.
А насколько в реальной разработке удобнее подгружать CSS скриптами?
Ну то есть, следует ли брать и бежать все <link rel="stylesheet"> менять на инъекцию js'ом?

Не сильно ли изменится user-experience в этом случае? Например, заторможенная отрисовка стилей при неважном соединении. При классическом подключении стилей браузер ждет загрузки css и рендерит уже стилизованную страницу, а при асинхронном подключении css браузер сначала отрисует «голый скелет», догрузит стили, мигнет и только потом выплюнет стилизованную страницу.
Поэтому автор написал:
Все стили, отвечающие за отрисовку первого экрана, минимизированы и вынесены прямо на страницу, в head.

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

Конечно все индивидуально, будем тестировать, пока «полет нормальный».
Статью-то прочитал. Вопрос скорее не по описанному решению, а по гугловской рекомендации избавиться от блокирующих стилей в шапке. В теории это поможет быстрее отрисовать страницу, но на практике может привести к нежелательным последствиям.
PageSpeed является всего лишь одним из 200 факторов ранжирования backlinko.com/google-ranking-factors
Я когда-то заморачивался с оптимизацией сайтов под PageSpeed Insight тест. Но через каждые пару месяцев Гугл обновлял алгоритимы подсчета и мои сайты теряли 10-20 пунктов рейтинга. В итоге я забил на это дело и не заметил никакой разницы в поисковых выдачах.
На сегодняшний день горячей темой SEO является Mobile-Friendly Test www.google.co.uk/webmasters/tools/mobile-friendly.
Главное чтобы было 90+. У нас в основном 95-96, без фанатизма, описанного в статье. Но достигается благодаря своим быстрым серверам с Nginx + HHVM + Redis, нормальным сжатием и тд. В шапке только стили и jQuery, остальное в подвале. Картинки оптимизированы. Мелкое все в SVG-спрайте. Сейчас вот тестируем SPDY и HTTP/2 ждем. 90 или 98 PageSpeed score не столь принципиально, если страницы сайта грузятся за 600мс.
самое обидное, что эти усилия не дают гарантии того, что вы поднимитесь в выдаче:(
Мне сейчас прилетело про 14 (!) баллов в мобайле и 30+ в десктопе. Смотрю статью и думаю, нужен ли мне Гугл -))) С реально скоростью проблем вообще нет -)
Only those users with full accounts are able to leave comments. Log in, please.