Анализ и оптимизация сайта на UMI CMS

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

Подготовка

Во-первых, любая оптимизация — это измерение. Оптимизируя, мы что-то ускоряем, то есть делаем это быстрее, чем было раньше. Так что, если вы хотите понять, ускорили вы или нет, то неплохо бы проводить измерения до и после.

Во-вторых, 2 + 2 не всегда равно 4.  Как бы странно это не выглядело, но такое бывает очень часто. В связи в этим, измерения приобретают куда более важное значение, чем могло бы показаться сначала. Примеры и подводные камни далее.

Итак, начнём.

Google PageSpeed

Это самый простой, самый тривиальный инструмент, самый эффективный и самый ироничный одновременно.

Суть его в следующем: google оценивает выбранную страницу по набору параметров и ставит оценку по шкале от 0 до 100. И тот и другой результат достижимы. Но ирония этого инструмента заключается в том, что сами сервисы гугла не получают 100, да и не могут получить. Поэтому, отнеситесь к этой оценке весьма условно. 100 баллов достижимы почти всегда, но сайт после этого может стать значительно медленнее. Моя рекомендация — смотреть на измерения, а не на оценку, но учитывать и оценку тоже.

Пользоваться инструментом просто: идёте по ссылке, вставляете url нужной страницы, например главной, нажимаете "Анализировать", ждёте, профит.

Сила инструмента заключается ещё и в том, что он сразу оценивает «мобильность» сайта. И тут вы внезапно можете увидеть проблемы, о которых даже и не догадывались.

Рекомендации, которые даёт PageSpeed, иногда можно решить без программиста, но такое бывает крайне редко. Обычно тут требуются совместные усилия контентщика, программиста и администратора сервера. Ну или нужен просто опытный прогер.

Google Chrome DevTools

Гугл в вопросах оптимизации серьезно закрепился на первых местах. Безусловно, сейчас уже есть похожие инструменты и в FIreFox, Opera. Да что там, даже Safari и IE уже могут подобное. Ну и, конечно, есть куча сторонних сервисов, позволяющих почти такое же. Но пальма первенства уже отдана.

Речь идет о маленьком пункте выпадающего меню «Просмотреть код». В некоторых редакциях он назывался «Проверить элемент», но видимо в какой-то момент было решено его переназвать. И теперь это может вызвать некоторую путаницу с пунктом, открывающим реальный исходный код страницы HTML.

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

Оптимизация, опять же, является ситуативной. Если вы видите битые ссылки — исправляйте. Видите большое количество ресурсов — исправляйте. Видите медленный запрос к серверу — исправляйте. И так в каждом конкретном случае свой механизм, свое решение, свои действия. Но увидеть все это вы точно сможете.

Яндекс.Метрика

Не мог обойти Яндекс стороной — вдруг он поднимет меня в выдаче за это? Шутка.

На самом деле, в Яндекс.Метрике есть отчет о самых долго загружаемых страницах. Этот отчет — не эталон. Он может сбоить. Ну то есть вы смотрите на отчет, открываете страницу и не видите проблему. Такое может случиться (очевидно, что в момент загрузки яндексом сервер мог быть занят чем-то, а сейчас уже освободился).

Но анализировать его нужно. Нужно смотреть за теми местами, которые вызывают проблемы постоянно и устранять именно их.

Основной профит сервиса — объем анализируемых страниц. Я думаю, что открыть все страницы на своем сайте и проверить скорость их загрузки — это весьма сложная задача. Так воспользуйтесь Яндексом — он уже сделал это за вас.

showStreamsCalls

Это конструкция, свойственная исключительно для UMI CMS и позволяющая понять, какие именно запросы из тех, что генерируют страницу, действительно тормозят.

Разработчики на UMI знают об этом. А те, что поопытней, еще и проверяют сайт перед сдачей. Но ничто не стоит на месте. И если перед сдачей в каталоге было 1000 товаров и сайт не тормозил, а вдруг через год каталог увеличился в разы и сайт стал жестко тупить, то тут я бы рекомендовал предпринимать конкретные действия, а не пытаться говорить, что кто-то что-то не предусмотрел при разработке: когда дети растут — им нужна новая одежда. Когда растет сайт — ему нужны новые методы оптимизации и работы, возможно новый хостинг (кстати, рекомендую Sprinthost).

Пользоваться инструментом так: в конце интересующей вас страницы добавляете ?showStreamsCalls=1 и видите список всех вызовов на странице со временем их выполнения (например, https://umi-cms.ru/?showStreamsCalls=1).

Подводный камень 1: некоторые, особо усердные защитники информации, закрывают эту команду для внешнего использования. На мой взгляд это тупо: зачем делать сайт таким, что зная внутреннюю структуру ты можешь что-то там навертеть? Нужно сразу делать нормально и все будет ок.

Подводный камень 2: если у вас PHP-шаблонизатор, то вы можете вообще ничего не понять из увиденного, особенно если сайт сваяли криворукие прогеры. С TPL чуть проще. С XSLT — кристальная ясность.

Опять же, решения принимаются ситуативно. Видите самые тяжелые блоки и пытаетесь их уменьшить. Ну или видите маленькие, но одинаково повторяющиеся и думаете «а зачем оно тут?».

Заключение

Обычно, этих инструментов хватает для решения базовых проблем сайта. Но есть то самое 2+2=5, о котором не стоит забывать.

Пример 1:

По рекомендации Googlу PageSpeed вы уменьшили файл css или js, убрав из него комментарии, и теперь он ушел из этого сообщения. Казалось бы, должно стать лучше, но нет. Файл внезапно появился в блоке «Эти файлы могут быть сжаты с помощью GZIP». Почему такое случилось и что делать? (это, кстати, реальный пример, довольно характерный для UMI CMS — файл jquery.cookie.js)

Решение простое — нужно увеличить файл в размере.

Дело в том, что GZIP сжимает файлы ТОЛЬКО если они больше1Кбайт (дефолтные настройки, у вас может быть не так). А ваш файл после устранения комментариев стал весить, например, 600 байт. Добавьте немного комментариев (но только до килобайта) и все получится.

Пример 2:

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

Решение — вернуть все на место.

Дело в том, что UMI кеширует результаты запросов. Обратившись единожды к какому-то объекту или макросу, следующие обращения к нему будут почти мгновенными. А вы просто не смогли отследить все запросы, вот и получили проблем. Мало того, может случится, что на какой-либо из страниц (которую вы пока не видите) уже все сломалось и там ошибка на ошибке из-за убранного куска. Так что с такими вещами нужно быть аккуратнее.

А вообще, думайте об оптимизации. Ваши пользователи точно будут довольны быстрым сайтом.

Ваш отзыв