Google PageSpeed - это бесплатный инструмент, который оценивает производительность и удобство использования вашего сайта для мобильных и настольных платформ. Это очень важно, потому что Google использует его для определения ключевых элементов нашего SEO рейтинга, то есть того, насколько высоко мы оказываемся в их результатах поиска.
Если вы хотите больше узнать о преимуществах повышения скорости сайта, прочитайте статью Moz, Почему Оптимизация скорости сайта должна быть частью вашей стратегии SEO , в которой подчеркивается: «… несколько примеров показали, что более быстрая загрузка страниц сильно коррелирует с более высоким доходом».
В этом уроке я расскажу вам о некоторых технических подходах для оптимизации PageSpeed вашего сайта WordPress. Хотя базовые изменения могут быть довольно простыми и легкими, более комплексные обновления могут быть довольно сложными.
Интересно, что пользовательские сайты легче оптимизировать, чем сайты WordPress, — это связано с широким использованием в платформе сторонних тем и плагинов. Он также основан на архитектуре, которая была разработана до его популярности и опирается на несовершенную архитектуру для обратной совместимости.
Прежде чем мы начнем, пожалуйста, помните, я стараюсь участвовать в обсуждениях ниже. Если у вас есть вопрос или предложение по теме, пожалуйста, оставьте комментарий ниже или свяжитесь со мной в Twitter @reifman . Мне интересен ваш опыт работы с WordPress и PageSpeed.
Мой начальный балл PageSpeed
В этом уроке я сосредоточусь на улучшении своего личного сайта JeffReifman.com .
Некоторое время назад моим PageSpeed были Mobile 65 и Desktop 64 — не так уж и здорово:
Прежде чем приступить к оптимизации, давайте поговорим о некоторых основных факторах производительности WordPress.
Основная производительность WordPress
Есть несколько основных способов начать оптимизацию вашего сайта WordPress для повышения производительности и увеличения PageSpeed.
Выбор темы
На PageSpeed различных тем большое влияние оказывают количество и размер файлов JavaScript и CSS, которые они используют, количество используемых изображений и их размер, а также подход их мобильной реализации, то есть, как правило, отзывчивый в настоящее время.
Если вы ищете новую тему WordPress и хотите оценить PageSpeed, вы можете быть удивлены тем, что оценки по известным темам часто идут в 60–70-х годах, но также и в 90-х годах. Вот пара статей, оценивающих темы и PageSpeed через ColorLib и WPMU . В любом случае я ожидал большего.
Однако, поскольку больше не будет обновлений для темы, мне будет немного легче внести некоторые радикальные изменения в его производительность для этого учебника, не имея дело с будущими обновлениями кода от компании. Я вернусь к этому в ближайшее время.
Хостинг Компания
Использование выделенных серверов, скорее всего, будет работать лучше, чем все более распространенные и более доступные виртуальные общие серверы. В прошлом я писал о том, как установить WordPress на общих провайдеров, таких как Digital Ocean . Также есть промежуточные сервисы, такие как WP Engine , которые предлагают внимание разработчикам, а также общим и выделенным серверам.
Качество хоста тоже будет иметь значение. Многие открытые провайдеры WordPress могут обеспечить непоследовательную производительность.
Например, я использую тему KnowHow как в публикации с WordPress, размещенной на виртуальном сервере Digital Ocean, так и в Flee the Jungle, размещенной на WP Engine. Сайты довольно похожи по весу контента, например, использование текста и изображений. PageSpeed для публикации с использованием WordPress PageSpeed - это Mobile 73 и Desktop 88, а «Побег из джунглей» в WP Engine был немного быстрее (Mobile 78 и Desktop 91); Управляемый хостинг WP Engine немного быстрее моего собственного хостинга с общим сервером.
Я также видел низкую производительность с низким уровнем хостинга Amazon AWS. Ты получаешь то, за что платишь.
Регулярное уменьшение размеров и размера файлов изображений в WordPress является трудоемким, но критически важным.
Я регулярно использую Acorn как легкий инструмент для быстрого уменьшения изображений в Интернете. Я смеялся, когда кто-то недавно написал в твиттере, что он только что открыл Photoshop и будет доступен для телефонных звонков, пока он загружен — Acorn маленький и быстрый. Эта модель подписки Adobe загружается очень медленно — извините, подписчики.
Все чаще я также получаю доступ к изображениям на своем посту извне из Flickr. Например, когда моя публикация о росте соседства в Сиэтле, вызванном Амазоной, стала невероятной для Slashdot , проблем с производительностью и пропускной способностью для всех фотографий не было, поскольку Flickr справился с этим.
Вы можете прочитать Руководство по оптимизации изображений Google PageSpeed, но я все чаще обнаруживаю, что справка Google чрезмерно ориентирована на исследования (что приятно иметь в качестве ресурса), но не очень полезна для самостоятельного решения проблем. Там может быть слишком много докторов наук и слишком мало реальных пользователей.
Мои обновленные баллы PageSpeed
Хотя у меня всегда были W3TC и Varnish, добавление KeyCDN и Optimus увеличило мой PageSpeed для Mobile 72 и Desktop 82, что является хорошим улучшением с 65 и 64:
Интересно, что жалобы Google на кэширование изображений выглядят так, как будто они могут продолжаться бесконечно, независимо от того, что вы улучшаете. В этом уроке я экспериментировал с оптимизацией некоторых из оставшихся преступников, чтобы увидеть, что произойдет. Результат был интересным, и я расскажу вам больше об этом в ближайшее время.
Задача оптимизации скорости страницы
Если вы выполнили все основные основы, описанные выше, то улучшение вашей PageSpeed с помощью WordPress требует значительных усилий и может занять довольно много времени.
Вызов WordPress
Статический сайт обычно имеет один файл с CSS и JS-включениями, которые можно легко минимизировать и комбинировать. WordPress намного сложнее.
Так много создается динамически с помощью WordPress — хм — не идеальная архитектура. Может потребоваться время, чтобы найти, где создаются файлы, находятся ли они в темах или плагинах, и как решить эти проблемы. Оказывается, когда у вас есть семь плагинов, включая файлы JavaScript, и вы хотите свести их к минимуму и объединить в одно включение, допуская регулярные обновления плагинов, это довольно сложная задача.
Использование минификации
HTML минификация
Обновление настроек W3TC HTML для минимизации быстро разрешило жалобу PageSpeed по этому поводу.
Минификация CSS
Для CSS мне пришлось по отдельности добавлять файлы, о которых меня предупредил PageSpeed, в W3TC CSS File Management. Затем W3TC начал минимизировать мой CSS и объединять названные файлы в один файл для включения.
Это решило требование минимизации CSS для PageSpeed.
Это также уменьшило число файлов CSS, о которых сообщалось для блокировки рендера, с семи до четырех файлов, связанных с темами (сначала перечисленных в разделе «Оптимизация доставки CSS»):
Три оставшихся файла были из каталогов плагинов вне моей темы (которые мы рассмотрим позже):
Я надеюсь, что это дает вам ощущение кроличьей норы, которой быстро становится оптимизация WordPress PageSpeed.
JavaScript минификация
Хотя минимизация и объединение CSS, как правило, довольно просты, JavaScript, как правило, часто терпит неудачу, когда вы пытаетесь это сделать, создавая серьезные, разрушающие сайт ошибки.
Интересно, что PageSpeed теперь предлагает полные заархивированные загрузки своих сжатых версий ваших файлов, которые ему не нравятся.
Он перечислил десять моих файлов JS, которые он хотел, чтобы я исправил:
Для справки, вот больше ресурсов по минимизации Google PageSpeed для HTML, CSS и JS. Я также использовал Refresh SF , который обеспечивает легкий веб-доступ к различным инструментам сжатия.
Сжатие и объединение JavaScript, безусловно, может привести к ошибкам, поэтому мне пришлось действовать шаг за шагом. Используя W3TC JS File Management, я минимизировал и объединил семь файлов JS в теме Construct:
Это не позволило мне обратиться к JS-файлам моих плагинов или к проблемам, с которыми я столкнулся при загадочном неисчислимом размещенном во внешнем файле base.js. Давайте перейдем к проблемам блокирования рендеринга, а затем вернемся к минификации JS.
Устранение блокировки рендера
Если у вас есть большое количество файлов, которые необходимо загрузить для стилизации (CSS) и активации (JS) функциональности вашей веб-страницы, большинство браузеров будут замедляться после параллельного запроса четырех ресурсов.
Вот пример жалобы на блокировку рендера CSS в PageSpeed:
Хотя W3TC объединил многие из них в свой include.c46b63.css, следующие три выше были из моих плагинов.
if ( !$this->options[‘exclude_css’] ) wp_enqueue_style(«toc-screen»);
if ( $this->options[‘smooth_scroll’] ) $js_vars[‘smooth_scroll’] = true;
wp_enqueue_script( ‘toc-front’ );
Следуя предложению Тэдлока, я перерегистрировал мой плагин, включающий в файл functions.php моей темы, в первую очередь, CSS — вы должны найти ссылки, используемые разработчиком плагина:
Я вручную создал комбинированные CSS-файлы с этими тремя таблицами стилей плагинов. Затем я попросил W3TC минимизировать и объединить этот файл в свою собственную таблицу мега-стилей:
Здесь существует серьезная проблема, заключающаяся в том, что при обновлении моих плагинов мне может потребоваться обновить этот комбинированный файл CSS и сопровождающие его файлы JS.
Используя подход Tadlock, вот как выглядела блокировка рендера PageSpeed:
Я следовал тем же шагам для файлов JS, только немного более тщательно. Постепенно жалоба JS моего PageSpeed на мой сайт стала довольно незначительной:
Однако, как вы можете видеть ниже, он также жаловался на проблемы кеширования браузера с файлами JS, на которые я не смог найти ссылки в моей базе кода, такие как ad_status.js от Doubleclick.
Удаление устаревшего YouTube Player Embed
В конце концов я понял, что проблема минимизации JS и проблема с кэшированием связаны с моим использованием внешнего видеоплеера YouTube.
Вероятно, способ, которым моя тема Construct внедрила файлы YouTube, был устаревшим решением. Поддержка YouTube5 в HTML5 может работать намного лучше. Тем не менее, довольно забавно, как сервис Google влияет на оценку производительности другого сервиса Google.
Удаление одной функции на моей домашней странице, которая встраивала видео YouTube, решило несколько проблем:
Поскольку я не хочу, чтобы вы упустили возможность увидеть мою лучшую половину до того, как WordPress повредил меня, я добавлю сюда видео. Я был хорошим парнем.
Вот что происходит:
Размещенный извне файл s.ytimg.com base.js, который он хотел сжать, был создан с помощью этого видео на YouTube.
И static.doubleclick.net/instream/ad_status.js был тоже. Потребовалось время, чтобы отследить местоположение этого файла. Помогла консоль разработчика Safari, когда я увидел и base.js, и ad_status.js в кадре YouTube (так глубоко в кроличьей норе улучшения страницы PageSpeed я был теперь, когда Алиса представилась мне):
После внесения ранее сделанных JS-изменений и удаления видео проблема минимизации JavaScript была решена для моего мастера PageSpeed:
Ошибка кэширования браузера с Doubleclick, показанным ниже, также исчезла.
Использование кеширования браузера
Теперь мне нужно было только кэшировать gpt.js и ga.js, еще два внешних сервиса Google:
Я посмотрел другие темы, которые я использую с плагином Google Analytics (в Construct есть настройки для Google Analytics), и они тоже не рассматривали это.
Итак, я сделал локальные копии скриптов для Google Analytics и Google DFP, и вскоре после этого кеширование моего браузера было решено в PageSpeed:
Вот еще информация от Google о браузерном кэшировании , опять же очень глубоком техническом ресурсе без особого руководства для администраторов WordPress.
Google может предоставить общие группы своих популярных файлов JavaScript, сведенные к минимуму и объединенные для лучшей поддержки PageSpeed издателей. Это также помогло бы, если бы они не загружали свои файлы индивидуально и неявно в сценариях.
Давайте кратко вернемся к жалобам на размер изображения PageSpeed, прежде чем закончить.
Возвращаясь к оптимизации изображения
Предложения Google PageSpeed по изображениям на самом деле могут ослабить удобство использования вашего сайта. Вот один из примеров, рекомендуемое изображение, которое я разместил на своей домашней странице.
Для того, чтобы мои сообщения отображались в Facebook с миниатюрным изображением, социальной сети требуется минимальные размеры 200 пикселей с самой короткой стороны. Моя версия 281 x 200 ( показана здесь с небольшой поправкой на требования Tuts + ):
И вот версия, предоставленная PageSpeed в архивированной загрузке:
Вы можете видеть, что качество еще хуже, но, что более важно, PageSpeed хочет, чтобы я сократил изображение до размеров, которые Facebook не принял бы показывать в своих сообщениях.
В конечном итоге я решил покинуть свой сайт с несколькими жалобами на оптимизацию изображений PageSpeed, что снизило мои оценки.
В заключение
После всей этой работы, где мой сайт оказался?
Моя последняя страница Скорость счета
Mobile PageSpeed
Окончательные оценки PageSpeed включали Mobile 70, показывая некоторые из оставшихся жалоб ниже:
Вот оставшиеся оптимизации изображения:
И вот краткое изложение всех пройденных правил:
Кроме того, вот окончательные результаты UX. Большинство сайтов не имеют больших проблем с ними, поэтому я не обращался к ним сегодня:
Desktop PageSpeed
Итоговый счет на рабочем столе составил 86, неплохо:
JavaScript привередлив. Мне никогда не удавалось успешно минимизировать и объединить эти последние два файла в первый. Даже оставлять их без сжатия никогда не получалось. Работать с темами и плагинами сложно. Чтобы решить эту проблему, потребовалось бы несколько дней самоотверженной работы.
Вот его жалобы размера файла изображения:
В конечном счете, оптимизация моего PageSpeed заняла много времени и усилий и сделала мой сайт уязвимым для будущих плагинов и обновлений скриптов Google. Большая часть этой работы довольно запутанная, детализированная и отнимающая много времени. Это также немного сводит с ума и ошеломляет. Спасибо Google.
Скорость страницы других основных сайтов
PageSpeed это еще не все. Содержание тоже имеет значение. Вот несколько известных сайтов и их PageSpeed. Результаты вас удивят.
Смелый огненный шар Джона Грубера
Daring Fireball (DF) — один из самых быстрых блогов, ориентированных на контент. Это продвигает рекламодателей в минимальной форме. Страницы бегут легко и быстро. CMS Gruber является настроенной версией Movable Type. Результаты немного лучше, чем на моем сайте. DF также генерирует тонны дохода с минимальной рекламой.
Нью-Йорк Таймс
Очевидно крупная новостная организация, у них ужасные оценки PageSpeed:
Сиэтл Таймс
Поразительно, но наша местная тряпка с ее ужасной рекламой и моделью отказов подписки намного хуже:
B & H Photo
Популярный сайт электронной коммерции, B & H Photo , имеет ужасную мобильную оценку и оценку на рабочем столе чуть ниже моей:
Амазонка
Возможно, вы слышали об этой компании в моем недавнем эссе « Как отличить сайты WordPress от географии — они продают много вещей в Интернете». Мои оценки PageSpeed значительно выше их:
Что дальше?
В будущем я рассмотрю еще несколько улучшений, чтобы улучшить PageSpeed моего сайта:
Переход на новую тему WordPress. Прежде всего, я ищу более чистый, высокопроизводительный и отзывчивый дизайн с быстрой PageSpeeds.
Обновление моего сервера до PHP7. Обновление обещает почти двукратное улучшение производительности. Это не просто обновить до выпуска Ubuntu в комплекте, но это не так уж сложно.
Обновление моего сервера до Varnish4. Обновление требует доработки конфигурационных файлов, и я не уверен в его совместимости с W3 Total Cache, но я готов попробовать.
Просмотрите мою PageSpeed на всех страницах моего сайта, а не только на главной странице.
Если я не перенесу темы в ближайшее время, мне нужно будет внедрить этот скрипт cron для синхронизации моих собственных скриптов Google для Analytics и DFP и выяснить, как отслеживать обновления плагинов для изменений JS и CSS. Честно говоря, мне, возможно, придется вернуть эти специфические достижения PageSpeed.
