Представьте, что у вас есть самый красивый сайт в мире — ну, не считая галереи Микияко Кобаяши. Но теперь, когда ваш сайт наконец-то услаждает глаз, он загружается медленнее, чем YouTube по GPRS-соединению! И несмотря на крутой дизайн, им откровенно неприятно пользоваться.
Если это произошло — нужно что-то с этим делать. Потому что согласно исследованиям Amazon, Wallmart, Amakai и Aberdeen Group, чем быстрее загружается сайт — тем больше на нём конверсий.
1. HTTP-запросы — зло
Каждый раз, когда пользователь загружает ваш сайт, помимо самой страницы он загружает и все медиафайлы на ней (картинки, анимацию, аудио и т.д.). Даже если эти файлы маленькие, для каждого из них на сервер отправляется запрос, который потом нужно еще обработать и отправить результат обратно. Часть этой проблемы можно решить используя GZip-компрессию и кеширование файлов — и мы обсудим эти решения чуть ниже. Но сначала, ответьте на вопрос — зачем вам вообще все эти файлы?
И если у вас нет ответа — здесь и стоит начать оптимизацию.
- Уберите ненужные картинки. Даже если вы — владелец галереи, количество полноразмерных HD-изображений на странице должно стремиться к одному. Используйте миниатюры везде, где только можно. и используйте полноразмерную картинку только когда она доминирует над остальным контентом.
- Перенесите всю простую графику в CSS. Даже если это увеличит объём файла, который пользователь загружает при первом заходе на сайт. CSS со встроенной графикой снижает число запросов в будущем и в результате ускоряет загрузку в разы. Также, старайтесь объединять CSS, когда это возможно — за одним исключением, о котором мы поговорим позже.
- Снизьте число скриптов. А если это нереально — передвиньте их вниз страницы, чтобы пользователь мог сначала загрузить хотя бы все визуальные элементы и увидеть, что на странице хоть что-то происходит.
И если вы собираетесь делать для вашего сайта новые страницы в будущем — запомните эти правила. Лучше сразу всё сделать хорошо, чем пытаться потом оптимизировать уже опубликованную страницу.
2. О плюсах и минусах кэширования
Кэш — замечательная штука. Он позволяет браузерам загружать только те части сайта, которые изменились с последнего визита. Ну, в идеале. На деле, только вы решаете, какие части страницы должны кэшироваться и как долго будет храниться кэш. Чрезмерное кэширование может даже навредить работе сайта, но в то же время, грамотное использование кэш-файлов поможет снизить время загрузки страницы на пару секунд.
Есть несколько способов проверки актуальности кэш-файлов. Лучший — ETag, который проверяет наличие у пользователя последней версии файла. Но это не оптимальный метод — он всё равно включает в себя HTML-запрос.
Лучше использовать параметр max-age — он определяет как долго будет храниться кэш на компьютере пользователя и не создаёт излишних запросов. Только не стоит ставить слишком высокие значения — кэш занимает место на жестком диске ваших пользователей. Но и слишком низкие ставить не стоит — теряется смысл всей этой затеи. Оптимальное решение — 1 неделя для полноразмерных изображений и 1 год для CSS, маленьких картинок и прочего. Но если вы планируете менять эти элементы — тут уже стоит использовать eTags.
3. Фокусы с GZip
Современный HTML — неоптимален. Каждый тэг имеет закрывающий аргумент, который выглядит почти точно так же. Поэтому, одинаковые комбинации символов повторяются по всему HTML-документу. И к контенту это тоже относится — зачастую словарь текста намного меньше, чем общее число слов в нём.
Всё это значит, что используя современные техники сжатия — например GZip — можно уменьшить размер страницы. Увы, эта технология не работает с картинками, аудио и прочими медиа — они обычно уже сжаты с использованием более эффективных, специально разработанных алгоритмов.
Все компьютеры, выпущенные в последние 15 лет, могут сжимать в GZip на лету — даже если аппаратной поддержки этого стандарта в них нет. Так что включить эту функцию на своём сервере или хостинге нужно обязательно. Вы можете сделать это в cPanel или любой другой панели управления.
А если у вас такой нет — отправляйтесь на wiki той серверной системы, которую вы используете, и поищите GZip или HTTP Compression. Эту функцию точно поддерживают IIS, Apache и NGINX. В Apache даже есть возможность предварительного сжатия, которая позволяет снизить нагрузку на сервер.
4. JPEG, PNG, MP3 и другие аббревиатуры
GZip — замечательная штука для сжатия HTML, но, как мы уже говорили, она не работает с медиафайлами. Вообще, выбор форматов для медиа — это очень спорный момент. Потому что вместо одного волшебного решения, тут предлагается широкий набор компромиссов.
Для изображений, очень долгое время стандартом был JPEG. Не очень хорошее решение, так как после сжатия на картинке оставались артефакты (искажения). В то же время размер файлов JPEG крайне мал.
PNG — другой интересный формат. Он оставляет намного меньше артефактов и имеет несколько преимуществ перед JPEG — например, поддержку прозрачности. Но размер файлов PNG несколько больше, чем файлов JPEG — как раз за счет дополнительных функций.
Наконец, в 2010 Google представил свой собственный формат — WebP. Он призван заменить как PNG, так и JPEG. Результаты у него отличные — как в плане размера, так и в плане качества — но использовать его на сайтах пока рановато. Хотя настольные компьютеры в основном справляются с WebP даже если у них нет его аппаратной поддержки, неновым мобильным устройствам может прийтись туго. Хотя если у вас есть отдельная версия сайта для настольных ПК — WebP станет отличным решением.
Касательно разрешения, то чем оно выше — тем лучше результат. В то же время, размер изображения растёт с ростом разрешения. Лучшим выбором будет использование стандарта Retina — загружайте изображения в разрешении, которое в два раза выше, чем то разрешение, в котором их будут просматривать. Максимальный размер — ~4000 точек в ширину, но только если это изображение — единственное полноразмерное на этой странице. Также можно попробовать снизить глубину цвета изображений, особенно если они простые. Но это не всегда себя оправдывает.
Наконец, выучите HTML. Более подробно мы поговорим об этом в следующей главе, но пока что убедитесь, что вы заполняете тэги img src. Если вы этого не делаете — страница будет тормозить или вообще перестанет загружаться.
5. Посмотрите на код
WYSIWYG-редакторы — отличное средство разработки HTML. Серьёзно, я даже редактировал эту статью в одном из них, под названием Remarkable. Но я буду первым, кто скажет —- они не идеальны. Да, они значительно упрощают жизнь веб-дизайнера и даже позволяют тому, кто не знаком с HTML, добиваться хороших результатов. Но тот код, что они выдают, далёк от идеала. Или даже от просто стандартов хорошего кода.
Существуют приложения, которые помогут вам оптимизировать такой код — PageSpeed Insights for Chrome поможет с HTML, CSS Compressor пригодится при работе с CSS, а Closure Compiler обязателен для JavaScript — но даже их результаты далеки от кода хорошего программиста. Поэтому, хотя вы и должны ими пользоваться, стоит также вложить время и деньги в получение хоть какого-то опыта веб-программирования. Поверьте, это вам пригодится.
ВАЖНО: Даже опытные веб-дизайнеры часто забывают про встроенное CSS. Точнее о том, что его вообще не должно быть. На то есть причина — эта техника медленнее, чем хранение всего CSS в одном внешнем файле и запрос нужных частей при отображении страницы. К тому же, HTML-код без встроенного CSS намного проще читать.
6. О боже, смотрите, шапка!
Иногда, сделать что-то быстро — просто невозможно. Например, это может быть большая страница с кучей медиасодержимого, которую просто нереально загрузить за 2 секунды. В таком случае, вам помогут ловкость рук и немного мошенничества.
Используя второй (хотя, технически, он будет первым) внешний CSS лист, который содержит только шапку страницы, вы сможете показать пользователю, что по крайней мере на странице что-то происходит и нужно просто немного подождать, пока их браузер обработает оставшуюся информацию. Даже если проблема совсем не в браузере и это ваша страница, которая всё еще передаёт медиафайлы.
Собственно тут используется тот же принцип, что и загрузкой скриптов в последнюю очередь — пускай страницей еще и нельзя пользоваться, он выглядит загруженной. И это уже лучше, чем совсем ничего.
7. Перенаправление и как его готовить
Как именно работает мобильная версия вашего сайта? Если вы используете адаптивный CSS или динамичную систему, которая передает мобильным пользователям специальную версию страницы — вы всё правильно сделали. А вот если у вас есть полностью отдельная мобильная версия сайта, с другими URL, на которые настроено перенаправление с настольной версии — вы сделали большую ошибку.
Каждое перенаправление — это серия HTTP-запросов, которые сильно замедляют загрузку сайта. К счастью, если вы уже используете такое решение, вам не придется переделывать весь сайт — хотя может и стоит этим заняться, ведь отзывчивый дизайн намного лучше. В любом случае, вы можете исправить сложившуюся ситуацию с использованием Googlebot, который может настроить на вашем сайте куда более эффективное HTTP-перенаправление. Придется внести кое-какие изменения в код страницы, но ничего особо сложного.
8. Просто смените сервер
«Нет ничего невозможного», гласит слоган Adidas. Но иногда это — не правда. Бывает так, что вы уже используете все ресурсы, а результат всё равно не соответствует ожиданиям. Я это понял, когда несмотря на все усилия, я так и не смог оптимизировать страницу под срок загрузки в три секунды. Поэтому апгрейд сервера, или даже смена хостинговой компании — это вполне адекватное решение.
К счастью, в этой сфере до монополии далеко — существует множество различных провайдеров, как старых и уважаемых, так и молодых и готовых идти на компромисс. С другой стороны, это значит, что подбор хорошего хостинга может занять время. Я в конце концов остановился на Unihost, но тут уж каждый выбирает по себе.
9. HTTP/2 и эпоха нового интернета
Не так давно, публике был представлен новый стандарт HTTP 2.0 (также известный как HTTP/2). И он уже лучше предшественника — даже несмотря на обязательное шифрование. HTTP-запросы в новом протоколе были оптимизированы — так что большая часть советов выше в нём просто не нужна.
К несчастью, многие хостинг-компании и даже некоторые браузеры еще не поддерживают HTTP/2. И до тех пор, пока вы не получите возможность перейти на новый стандарт, вам придется оптимизировать ваш сайт для HTTP 1.1. Но для везунчиков, которые имеют как желание, так и возможность перейти на новый стандарт — мы сделаем обзор HTTP/2 на следующей неделе, а также опубликуем список того, что стоит изменить на своём сайте при переходе на этот протокол.
Это скорее рекомендации…
Не считайте всё вышеописанное какими-то откровениями веб-оптимизации. Это не было задачей статьи и, если честно, мне не хватит знаний и опыта для того, чтобы написать нечто подобное. Например, я сам видел решения, которые идут наперекор моим советам и при этом вполне себе работают.
Но если вы вообще не знакомы с веб-оптимизацией — надеюсь, я хотя бы немного вам помог.