Периодически в поддержку приходят запросы примерно следующего содержания:
Праверил тему в Google PageSpeed. Оценки низкие. Тема гавно. Вы гавно.
Ну или как-то так... Надоело объяснять и учить людей пользоваться этим инструментом. Да и не обязан вроде. Мы техподдержку оказываем, а не технологиям обучаем.
Начнем с самого главного: PageSpeed - инструмент для разработчика. Если вы не имеете нужной квалификации, то не стоит за это браться. Я сильно сомневаюсь в том, что если у вас или у кого-то из близких заботил зуб, то вы возьметесь за стоматологическую бормашину. Вы пойдете к квалифицированному специалисту. И это несмотря на то, что обучиться "обтачиванию" зубов в десятки раз проще, чем всем тонкостям веб-разработки.
Но давайте всё же рассмотрим на понятном языке из чего складываются оценки и почему подобные запросы вызывают одновременно и смех и "испанский стыд" и стыд в целом за нацию и её менталитет. Сразу оговорюсь, что на время тестов я оставил работать лишь 2 небольших плагина, т.к. наличие плагинов очень сильно влияет на эти показатели.
Оценка главной страницы:
Вроде и не так плохо, но всё же не зеленая зона. Почему так? Идем ниже и смотрим то, на что жалуется инструмент:
В принципе тут всё чёрным по белому написано. И тут есть лишь 2 возможных улучшения, которые предлагает инструмент. Это устранение ресурсов, блокирующих изображение и время ответа сервера.
Начнем со второго - Сократите время ответа сервера
Всегда плюйте на этот параметр. Особенно если вы хоститесь в регионе на который и работает ваш сайт. Почитайте уже отдельно статьи о том, как устроены сети и магистрали в целом. И почему такой показатель - не показатель. Особенно с учетом того, что проверяется он с европейского сервера гугла. Если у вас дома 2 компьютера, которые не подключены друг к другу напрямую и имеют разные внешние IP-адреса, то можете сделать трейс от одного до второго(в инете тоже полно информации о том, как это сделать). Трейс покажет путь, который проделывают отправляемые вами ему пакеты. И, например, находясь в Астрахане, ваши пакеты сначала пойдут к вашему провайдеру. От него к его аплинку(вышестоящий провайдер). Оттуда на ближайшую главную магистраль, далее в Москву... А уже оттуда примерно таким же рандомным путем на второй компьютер. И вроде расстояние между компьютерами и всего в пару метров, но информация проходит тысячи километров. Потому и задержка в этом случае будет не 1мс. Объяснил вроде просто, но на самом деле всё гораздо сложнее. Даже находясь в одном месте задержка может быть абсолютно разной при использовании разных провайдеров. Один использует одного аплинка, второй другого. Один из тех аплинков протянул свой кабель сразу к магистрали, а второй к главному по региону, а тот к другой магистрали... Сетью оно не просто так называется. В итоге задержка до одного и того же узла с одним провайдером составит 30мс, а со вторым 800мс. Но это не значит, что второй провайдер плохой. Т.к. задержка до узла Б может быть абсолютно противоположной. Как с автодорогами. Только тут маршрут не вы выбираете.
А теперь, имея хотя бы примерное представление об устройсте передачи информации по сети и "задержках", подумайте о том, имеет ли вообще какую-то цену оценка задержки до вас с европейского сервера? Если имеет - меняйте хостинг. Либо просите перенести ваш сайт на сервера в другом дата-центре. Но пример о двух провайдерах выше я дал не зря. Может получиться так, что оценка гугла станет лучше, а вот для ваших пользователей наоборот сайт станет грузиться медленнее. А ведь не гугл у вас покупки делает.
Перейдем к устранению ресурсов, блокирующих содержимое.
Если кликнуть на подробности, то инструмент подскажет, о каком содержимом идет речь. А именно:
Так как я отключил практически все плагины на время замеров, тут в списке только файлы темы. И, прошу заметить, только CSS и главная библиотека jQuery. Наших скриптов тут нет. Почему же они "блокируют отображение"? Они прописаны внутри тега <head>. Это невидимая часть страницы, которая и предназначена для подобных вещей. Она находится ДО всего контента. Соответственно браузер клиента сначала будет грузить их, а потом уже содержимое страницы. "Лечится" это довольно просто. Нужно всего лишь перенести подключение всех этих файлов в конец страницы. Со всеми JS-файлами темы это уже сделано. В верхней части осталась лишь сама главная библиотека jQuery. Её убирать вниз нельзя по техническим причинам. По крайней мере в условиях темы для маркетплейса. Ведь в противном случае вам придется отдельно дорабатывать каждый второй плагин под такие условия работы. Многие плагины используют jQuery прямо в том месте, где выводятся. То есть в середине документа. Если сама библиотека к этому времени еще не подключена - будет фатальная ошибка и страница не будет работать. Даже сама система использует jQuery в середине документа. Во всех формах регистрации/авторизации и в новом оформлении заказа в корзине. Если используются какие-то плагины, то список "блокирующих отображение" файлов будет в разы больше. А оценка существенно ниже. Мы легко можем перенести место вывода подключения этих файлов в конец страницы. Но многие плагины от этого перестанут работать в принципе. Т.к. они подгружают в верхнюю часть свои библиотеки, а в теле документа уже к ним обращаются. И если к середине документа они не будут подключены... читайте выше. С нашей стороны мы можем лишь наши CSS-файлы перенести в конец. Это даст до 5 баллов к итоговой оценке. Но это означает, что сначала загрузится голая страница без стилей и лишь потом все стили к ней. Гуглобот не человек и с его точки зрения это плюс. На самом деле у посетителя будет такая картина:
Именно так выглядит страница без стилей. Да, ЭТО пользователь увидит быстрее. Но итоговая рабочая версия всё равно загрузится с той же скоростью. И какой в этом смысл? Это скорее минус, чем плюс. Во время прогрузки стилей контент будет еще и постоянно прыгать, что раздражает посетителя куда сильнее, чем белый экран ожидания.
Ну и далее в двух словах по пунктам:
Сократите размер DOM-структуры - увы, но нет. Это не какой-то домашний сайт. Это здоровенный магазин с кучей всего. При сильном желании сократить конечно можно, но не так существенно. И да, если что, то речь тут о большой вложенности HTML-элементов.
Настройте показ текста во время загрузки шрифтов - CSS в конец не вынесен. Так что не имеет особого смысла.
Остальное - либо техническая необходимость, либо рекомендации к использованию серверных оптимизаций, что уже к теме отношения не имеет.
Ну и не лишним будет напомнить о том, что тест выше делался для главной страницы https://balance.designmyshop.ru/. И так как это демо-витрина, там включены абсолютно все секции. То есть размер этой страницы неправдоподобно и неоправданно огромен. И естественно тут работает правило банальной логики: "чем больше нужно загружать, тем больше придется загружать". Никто не заставляет вас использовать все секции. Оставьте одну и радуйтесь оценкам гугла, если для вас это важнее качественного и красивого представления товаров.
Вот пример замера страницы менее нагруженной лишней информацией(страница категории с фильтром и подкатегориями):
И та же страница для мобильной версии:
Да, оценка мобильной версии никогда не будет зеленой на основных страницах(главная, каталог, страница товара). Это уже технически не совсем возможно. Для этого мобильная версия должна быть отдельной темой. Максимально урезанной и облегченной. В условиях адаптивного шаблона так не сделать. Ведь мы выдаем мобильным пользователям ту же страницу. Просто стили у него применяются другие. То есть она еще и таскает за собой мертвым грузом кучу скриптов и стилей для десктопной версии.
Наболело...
Ну и напоследок. Я включил обратно лишь 3 относительно простых плагина на этой витрине: определение города, купить в 1 клик и заказ обратного звонка. После этого сделал новый замер с главной страницы:
Минус 18 попугаев. Если подключить еще больше плагинов, то результат будет еще хуже. Подключение сторонних сервисов замедляет скорость загрузки больше всего. Ведь компьютер клиента сначала обращается к вашему сайту, лишь оттуда узнает, что ему нужно еще на сторонний сервис зайти и загрузить оттуда контент, потом вернуться. И когда люди, у которых включен десяток плагинов(особенно СЕО-регионы, который отгрызает дополнительную секунду лишь на внутреннюю часть еще до выдачи HTML), консультанты, метрики, аналитики и пр. мусор, обращаются к нам с претензиями на то, что тема медленно грузится... Извините, но от таких фейспалмов уже череп болит.
PS И да, это не значит, что плагины плохие. Так уж технически устроена экосистема вебасист. И это не значит, что вебасист плохой. Он сделал так, чтобы вы могли себе это позволить. Представьте, что функционал всех существующих плагинов будет вшит в базу системы. Опустим тот момент, что это будет огромная неповоротливая и тормозящая система. Представьте лишь то, сколько работы потребовалось бы для создания всего этого. А для поддержания еще больше. И сколько такая система стоила бы? Купили бы вы её за 1000000₽? Не думаю.
Ну и коротко о том, почему тема называется именно так, как называется. Ведь люди копают в сторону PageSpeed в надежде на то, что после этого их позиции в поисковой выдаче просто устремятся вверх, сметая всех на своём пути. Это конечно не всех людей касается. Ведь способные мыслить могут поставить себя на место руководства поисковика и понять, что такие банальные ухищрения, о которых вам твердит ваш "мамкин сеошник" с фриланса, являются слабым местом, благодаря которому в топе выдачи будет одни лишь сайты-мошенники. Поисковик напрямую заинтересован в том, чтобы в первых позициях его результатов было именно то, что нужно клиенту. Ведь иначе он уйдет в другой поисковик. И рекламу уже так дорого продать не получится(покойся с миром, Рамблер). Хотите выйти в топ - делайте сайт для вашего клиента, а не гуглоробота. Последним мы, разработчики, проверяем свои работы. В своих целях.
Кстати вот вам оценки с самого быстроразвивающегося магазина в РФ:
Ну и для мобильных устройств:
И это сейчас еще получше стало. Раньше там и 20 для десктопа не было.
Ну и отдельно умиляет тот факт, что жалующиеся люди почему-то даже не пытаются посмотреть в сторону проделанной работы. А ведь об этом инструмент тоже говорит: