Привет всем! давно я хотел написать статью про сервис google page speed, хотя я итак писал уже про ускорение и оптимизацию сайта и давал советы, которые помогут вам повысить показатель в google page speed. Но речь сегодня о другом, с недавних пор я перестал беспокоиться о своём показатели в сервисе google speed и пытаться его как то повысить. В своё время я увеличил показатель с 2% до 87% впечатляет не правда ли!? Но спустя некоторое время мне пришлось поменять шаблон моего wordpress сайта, после чего показатель упал до 63%, наверное шаблон оказался тяжелее предыдущего.
Так же в дальнейшем при установке одного плагина, который выводит на сайт адаптивную сетку анонсов записей, показатель ещё упал до 30%. То есть я так понял мне нужно было выбирать либо красивый сайт, либо высокий показатель в сервисе google speed. Причём я заметил, что показатель может быть не высоким 50-70% и это никак не влияет на скорость открытия сайта в браузере. При показателе 63% мой сайт работает без проблем, конечно если отказаться практически от всех плагинов и выбрать себе тему для сайта по легче, то можно повысить показатель до 90-100%. Но ради чего это делать? Ради цифры? Ради самомнения?
Google page speed считает каждый килобайт! если изображение на вашем сайте можно оптимизировать, то есть сжать ещё на пару килобайт, то google понизит показатель, до тех пор пока вы не уберёте эти пару килобайт. То есть всего из-за нескольких килобайт показатель может быть понижен, но при этом для сайта это не несёт абсолютно никаких изменений в плане скорости, всё по прежнему! Тогда зачем я буду загоняться из-за этих килобайт, пыхтеть там, время своё тратить? Опять же получается только ради цифр, ради того, что я всех лучше и круче, вот посмотрите какой у меня высокий показатель, это бред!
Просто я хочу огорчить тех, кто якобы думает, что после того как они повысят себе показатель в сервисе google page speed, их сайт тут же чудесным образом станет популярным, посещаемым, их поисковые запросы вырастут и т.д.. Да вы что ребят, очнитесь! хватит часами зависать там, тратить своё время впустую, займитесь лучше своим сайтом, напишите что-нибудь полезное лучше. Я не удивлюсь что есть люди, которые ночами не спят из-за того, что у них низкий показатель в google speed. В общем эта гонка за высоким показателем может довести до абсурда…нет, играть в игры Google я больше не хочу, с меня хватит.
Я знаю как сделать высокий показатель, но мне это больше не интересно, мне интересно писать полезные записи на своём сайте. И менять свой шаблон ради высокого показателя я то же не собираюсь, на данный момент меня всё устраивает. На последок хочу показать скриншот с показателем в google page speed самого популярного и посещаемого сайта в России – Вконтакте, наверное там и не слышали о таком сервисе.
Мои рекомендации: если у вас проблемы с сайтом, он медленно загружается, проблемы с сервером, создаёт большую нагрузку, то возможно сервис google page speed может помочь вам выявить причины и помочь вам их устранить. Если проблем у вас нет с производительностью сайта, то вам не нужно знать об этом сервисе, он не нужен вам, повышение показателя ни чем вам не поможет, только отнимет время и спутает все карты.
Нужно понять, что сам по себе движок wordpress это тяжёлая система, много функций и прибамбасов, на что нужны ресурсы. Проблему с нагрузкой сервера может решить только увеличение лимитов хостинга, то есть переход на более высокий тариф или выделенный сервер. При достижении определённого показателя этот процесс неизбежен и здесь google page speed вам уже не поможет.
На этом у меня всё, жду ваших комментариев, до новых встреч!
Почему я забил на Google page speed Insights обновлено: Январь 7, 2019 автором: Илья Журавлёв
12 ноября Google по тихому обновил PageSpeed Insights , изменив в нем практически все. Это станет большой переменой для всей индустрии сайтостроения. Похоже, сейчас настанет некоторая волна паники и хайпа вокруг этого события. В статье - анализ перемен и что они нам принесут.
Что такое PageSpeed Insights Буквально пару слов для тех, кто не в курсе. Вот уже 8 лет PageSpeed Insights является главной пузомеркой скорости сайтов, в нее можно ввести адрес страницы и узнать ее оценку по шкале от 0 до 100 вкупе с рекомендациями по улучшению.Конечно, есть много других хороших инструментов для проверки скорости. Но так как этот - от Google, и они заявляли, что скорость сайта влияет на рейтинг в выдаче, для большинства эта оценка кажется самой важной. Особенно для заказчиков и начальников, и как результат - практически все пытаются поднять PageSpeed Score своих проектов, а метрика стала практически самой важной в индустрии.
Что изменилось? Если коротко - все. Старый PageSpeed отставили в сторону, заменив его оценками и аналитикой Lighthouse , open-source инструмента для аудита сайтов, который помимо прочего встроен в Google Chrome.Кардинальное отличие подхода - очки теперь присуждаются не за выполнение правил, а за скорость . Загрузка страницы оценивается по нескольким временным характеристикам - через сколько времени после начала загрузки уже что-то видно, когда уже можно кликать, насколько все тормозит, пока прогружается, и когда загрузится все. Эти характеристики сравниваются с показателями лучших сайтов и превращаются в баллы. Ниже мы разберем это подетальней, сейчас важен сам принцип.
Рекомендации есть, как и раньше - но теперь они несут совсем другую нагрузку. Рекомендации никак напрямую не связаны с баллами , и абсолютно не факт, что их воплощение улучшит ситуацию (но запросто может ухудшить при бездумной реализации).
Паника неминуема Сейчас ночь 13го, и все относительно тихо. Только пару профильных ресурсов выложило короткие заметки об обновлении, только пару клиентов написали взволнованные письма о странном поведении PageSpeed Insights. Кажется, это затишье перед бурей.Прямо сейчас видно, что инструмент ведет себя нестабильно - оценки для одной и той же страницы колеблются в пределах 20 пунктов, иногда выходят жалобы о невозможности получить страницу оцениваемого сайта. Некоторые сайты вообще, по его мнению, недоступны - хотя на самом отлично себя чувствуют.
Очевидно, что скоро очень много людей бросятся смотреть оценки своих проектов, накрывая сервис международным хабра-эффектом. Все будет работать через пень-колоду, глючить и пугать прыгающими оценками.
Это непросто, но постарайтесь расслабиться и сохранять спокойствие. Первое, что надо помнить - обновление PageSpeed Insights никак не влияет на принципы ранжирования в поисковой выдаче. Второе - понадобится не меньше двух недель, чтобы обновление обкатали, поправили и оно начало стабильно работать. Не делайте резких движений , возможно их потом придется откатывать.
Размышления и прогнозы В этих изменениях много позитива. Господство старого PageSpeed Insights с его принудительными рекомендациями наделало немало бед. Во первых, любая рекомендация может быть близка к бесполезной в вашей конкретной ситуации. Во вторых, ее можно реализовать в ущерб более важным вещам, например времени генерации страницы. Но выбора не было - приходилось все это делать, чтобы получить красивую оценку.Например, чего стоит рекомендация о минификации html кода страницы? В среднем эта операция занимает около 100 мс, и эта задержка в десятки раз перекрывает любую возможную выгоду от уменьшения размера страницы. Единственный вариант, когда это может быть выгодно - если вы выдаете готовые заранее минифицированые страницы из кеша.
В любом проекте последних лет немало усилий уходило на оптимизацию изображений, минификацию и группировку ресурсов, отложенный запуск JavaScript, который бы ничего не сломал. Чаще всего это уводило фокус внимания от сути - скорости работы сайта для посетителей. Интернет был полон как примерами тормозных сайтов с отличными оценками, так и быстрых сайтов, которые оценивались плохо.
Теперь эта мишура будет понемногу отваливаться. На первых тестах оценки с минификацией-группировкой ресурсов и без практически не отличаются. Значимыми становятся реально важные вещи - как быстро сервер отвечает и сколько тяжелого материала на странице. Все свистелки - виджеты социальных сетей, интерактивные карты, чаты и роскошные попапы будут неумолимо бить по оценке, как их не заворачивай.
Вполне вероятно, что это все приведет к действительно быстрым сайтам и пониманию, как их делать. По крайней мере, очень хочется в это верить.
Новые метрики А для самых стойких - подробный разбор новых метрик, которые влияют на оценку. Всего их 6, и они имеют разный вес в формировании финальной оценки. Пройдемся по ним в порядке уменьшения значимости.1. Время загрузки для взаимодействия Это самая важная характеристика - и самая тяжелая. Отметка времени, когда страница становится полностью готова к взаимодействию с пользователем. Этот момент наступает, когда:- отобразилась страница
- зарегистрировались обработчики событий для большинства видимых елементов
Это время, когда страница в браузере перестает изменяться визуально. Для определения используется покадровое сравнение вида страницы.
3. Время загрузки первого контента Показатель, который определяет интервал времени между началом загрузки страницы и появлением первого изображения или блока текста.4. Время окончания работы ЦП Этот параметр показывает время, в которое основной поток страницы становится достаточно свободен для обработки ручного ввода. Этот момент наступает, когда:- большинство элементов на странице уже интерактивны
- страница реагирует на действия пользователя за разумное время
- отклик на действия пользователя составляет менее 50 мс
- случилось наибольшее изменение вида страницы
- прогрузились шрифты
Каждая метрика сравнивается с показателями всех оцененных сайтов. Если у вас она лучше, чем у 98% сайтов, вы получаете 100 баллов. Если лучше, чем у 75% сайтов - вы получаете 50 баллов.
На первый взгляд, эти метрики весьма жизненные и обмануть их грязными манипуляциями, которые на самом деле не ускоряют сайт, будет практически невозможно.
Пока что остается загадкой принцип оценки мобильной версии сайта. Вернее, принцип тот же, но часто баллы ощутимо ниже. Непонятно, на какой виртуальной конфигурации мобильного устройства они прогоняются.
Скорость загрузки сайта является одним из важнейших показателей юзабильности ресурса, и что немаловажно, это один из сотни факторов ранжирования . Действительно, современный пользователь, который кликнул по ссылке, не ждет загрузку страницы более 5 секунд. Поэтому, чем дольше грузится ваш сайт, тем больше вы теряете потенциальных клиентов.
Более 50% пользователей интернета с мобильных устройств, ожидают практически мгновенной загрузки сайта. Исходя из такой статистики, речь в этой статье пойдет о том, как достичь показателей 100/100 в сервисе Google PageSpeed Insights для стационарных и мобильных устройств на примере сайта "Monitor Backlinks".
Сайт-образец и так загружается довольно быстро, поэтому в данном случае будут улучшаться результаты до возможного максимума.
Однажды, при работе с PageSpeed Tool, было замечено, что сайт компании Google имеет удивительно низкие показатели для мобильных устройств - 59/100. Ситуация с версией для стационарных устройств была лучше - 92/100.
Казалось бы, что они должны были использовать свой же инструмент для оптимизации своего веб-сайта, не так ли? Так неужели результат 100/100 недостижим?
Именно это послужило стимулом для достижения максимально быстрой загрузки сайта, чтобы доказать, что достичь результатов 100/100 реально, и при желании вы также сможете это сделать. Это не одержимость, это просто стремление достичь совершенства.
Стартовые показатели подопытного сайта - 87/100.
В итоге, после применения определенных манипуляций, было получено следующие результаты:
О том, как удалось достичь таких показателей, читайте далее.
Как ускорить загрузку страниц?Прежде чем приступить к пошаговым действиям согласно инструкции, позвольте отметить, что инструмент PageSpeed является всего лишь ориентиром для веб-мастеров на пути оптимизации ресурса. К тому же инструмент содержит рекомендации по ускорению загрузки страниц вашего сайта, а достижение положительных результатов во многом зависит от настроек сервера.
Обратите внимание, на то, что некоторые из шагов инструкции могут потребовать технических знаний, независимо от используемой системы управления контентом (CMS).
Итак, приступим:
Шаг № 1: Оптимизация изображений
Чтобы изображения загружались быстрее, PageSpeed Insights Tool предложил оптимизировать их за счет уменьшения размеров файлов. Чтобы решить эту задачу, необходимо выполнить две важные вещи:
- Сжать все изображения, используя такие инструменты как Compressor.io и TinyPNG. Это бесплатные инструменты, при помощи которых можно уменьшить размер графического файла более чем на 80%, а в некоторых случаях, без ухудшения качества самого изображения.
- Уменьшить размеры изображений до минимума без понижения их качества. Например, если на сайте нам нужна картинка 150x150px, то и на сервере картинка должна быть соответствующих размеров. Параметры изображений не должны подгоняться при помощи CSS или HTML-тегов.
Согласно вышеупомянутым правилам каждое изображение на сайте было загружено, а также вручную сжато и подогнано по размерам. А чтобы не заморачиваться с оптимизацией изображений после их загрузки на сайт, лучше выработайте привычку изначально оптимизировать все новые изображения, загружаемые на сервер. Каждое новое изображение должно быть сжато и подогнано до необходимых параметров.
PageSpeed Insights предлагает опцию загрузки уже оптимизированных изображений, поэтому их можно загрузить на сервер непосредственно с данного сервиса. То же самое можно сделать и с JavaScript и CSS.
В примере, Google предлагает сократить объемы JavaScript и CSS файлов.
Процесс минимизации позволяет сократить объемы файлов, устраняя ненужные пробелы, переносы, строки, символы и комментарии в JavaScript и CSS файлах. Программисты часто оставляют много места и комментарии во время кодирования, что может удвоить объем JavaScript и CSS файлов.
Чтобы устранить эту проблему, на сервере был установлен Gulpjs. Это инструмент, который автоматически создает новый файл CSS и удаляет все ненужные пробелы. Также он автоматически создает новый файл CSS каждый раз, когда вы вносите новые изменения. В приведенном примере, это помогло уменьшить размер основного файла CSS приблизительно с 300Kb до 150Kb. Такая разница в размерах обусловлена ненужными символами.
Дополнительно уменьшить размеры JavaScript и CSS можно за счет переименования переменных, при условии корректной работы селекторов и обновления HTML.
Оптимизировать JavaScript можно при помощи Closure Compiler, JSMin или YUI Compressor. Вы можете создать специальную программу, которая используя вышеперечисленные инструменты, будет переименовывать файлы и сохранять их в рабочий каталог.
Уменьшить CSS можно, используя инструменты YUI Compressor и cssmin.js.
Минимизировать HTML код можно через PageSpeed Insights. Выполните анализ страницы и выберите "Сократить HTML". Чтобы оптимизировать код кликните на "Просмотреть оптимизированное содержание".
Детальнее об оптимизации JavaScript и CSS файлов вы узнаете по ссылке:
Также можно загрузить оптимизированные файлы непосредственно из PageSpeed Tool.
Вот результаты, полученные после минимизации JavaScript и CSS:
Для многих веб-мастеров этап использования кэширования браузера является самым сложным.
Чтобы решить этот вопрос, пришлось перенести все статические файлы с сайта на CDN (content delivery network/сеть доставки контента).
CDN представляет собой сеть серверов, расположенных в различных местах по всему миру. Они кэшируют статические версии веб-сайтов, такие как изображения, файлы JavaScript и CSS. На серверах CDN хранятся копии содержимого сайта, а при заходе на этот сайт, статическое содержимое загружается с ближайшего сервера.
Например, если основной сервер сайта находится в Техасае, то без CDN, посетителю из Амстердама придется ждать, пока контент сайта преодолеет весь путь от сервера расположенного в США. С CDN, сайт загрузится гораздо быстрее из ближайшего к пользователю сервера, в данном случае из Амстердама. Таким образом, сокращается расстояние доступа к данным и сайт загружаться практически мгновенно.
Вот визуализация того, как работает CDN:
На подопытном сайте все изображения, файлы JavaScript и CSS были перенесены на CDN, а на главном сервере остались храниться только файлы HTML. Размещение изображений на CDN играет важную роль в том, насколько быстро будут загружаться страницы сайта для посетителей.
После вышеупомянутых манипуляций инструмент PageSpeed досадно продолжал предлагать использовать кэширование браузера для отдельных сторонних ресурсов. Вот скриншот:
Чтобы решить этот вопрос, пришлось исправить скрипты социальных сетей путем замены счетчиков, на статические изображения, размещенные на CDN. Вместо сторонних скриптов, которые пытались получать доступ к данным из Twitter, Facebook или Google Plus, для подсчета подписчиков, был установлен автономный счетчик, что и помогло решить данный вопрос.
Но более досадным было то, что вдобавок к проблемам со скриптами социальных сетей работу веб-сайта замедлял код Google Analytics.
Решения проблемы со скриптом Google Analytics довольно сложная задача. Так как Analytics был нужен, и его нельзя удалять с сайта, пришлось искать другие решения.
Google довольно редко меняет код Analytics, раз или два в год. Поэтому, Razvan создал специальный скрипт, который каждые восемь часов проверяет наличие последних обновлений кода Analytics, и при обнаружении обновлений загружает их. Таким образом, можно разместить JavaScript код Analytics на сервер, исключая необходимость загружать его с серверов Google, при каждом посещении.
В случае отсутствия обновлений, код Analytics будет загружаться из кэшированной версии на CDN.
А когда Google обновит код JavaScript, то сервер автоматически загрузит новую версию и обновит его на CDN. Этот скрипт был использован для всех внешних сторонних скриптов.
Вот скриншот из Pingdom Tools на котором показаны все загрузки из CDN, в том числе и код Google Analytics. Единственный файл загрузки с сервера, это файл домашней страницы, объем которого всего лишь 15,5Kb. Устранение всех сторонних скриптов значительно улучшило общую скорость загрузки.
Устранение блокираторов также является довольно сложным этапом в процессе повышения скорости загрузки страниц, требующий хороших технических знаний. Основная проблема, которую пришлось решать - это ревизия всего кода JavaScript начиная сверху от "header" и "body" до расположенного внизу "footer" на всех страницах сайта.
Если ваш сайт на платформе Wordpress, плагин Autopmize, скорее всего, поможет вам решить эту задачу. Проверьте свои настройки, а затем в снимите отметку с "Force JavaScript" и установите ее на "Inline all CSS".
Шаг № 5: Включение сжатия Шаг № 6: Оптимизация мобильного форматаАнализ мобильного формата показывает адаптивность мобильной версии сайта под различные типы разрешения, использование подходящих шрифтов, и наличие хорошей навигационной системы.
С помощью Google Chrome вы можете посмотреть, как ваш сайт выглядит в различных мобильных версиях. Для этого нажмите на иконку меню (гамбургер) настроек и управления браузером в верхнем правом углу, а затем выберите "Дополнительные инструменты → Инструменты разработчика". На панели инструментов выберите иконку с изображением мобильных устройств. Вот и все, смотрите:
В случае примера, не потребовалось каких-либо радикальных изменений.
ВыводВ результате было выполнено 6 самых важных шагов, которые помогли достичь идеальных показателей 100/100 в Google PageSpeed Tools для сайта "Monitor Backlinks". В итоге была оптимизирована не только главная страница, но и все внутренние страницы.
Среди всех выполненных действий по оптимизации сайта можно выделить три самых важных:
Хочется еще раз напомнить о том, что Google PageSpeed Tools является всего лишь вспомогательным инструментом для оптимизации ресурса. Инструменты предназначены для сокращения времени между запросом (кликом по ссылке) и откликом страницы сайта (отображения первых элементов страницы), чтобы посетители не покидали сайт, так и не дождавшись его загрузки. Также рекомендации, предоставляемые инструментом, необходимо применять с осторожностью, чтобы пользователям не показывалась разваленная верстка или какой-то не стилизованный набор блоков.
Обратите внимание. Быстрая загрузка страниц сайта косвенно влияет на ранжирование ресурса в поисковых системах, то есть: выше скорость загрузки → больше и длительнее посещения → выше ранжирование.
Если вы использовали инструмент Google PageSpeed Insights для оптимизации своего сайта, поделитесь достигнутыми результатами в комментариях.
Также не забывайте о том, что специалисты UAWEB всегда готовы предоставить необходимую помощь в вопросах создания, оптимизации и продвижения вашего веб-ресурса, чтобы каждая секунда проведенная пользователями на вашем сайте приносила вам выгоду!
Здравствуйте, уважаемые читатели блога сайт. Сегодня хочу поговорить с вами на такую важную тему, как скорость загрузки сайта. Наверное, вы уже все слышали, что наряду со множеством других факторов, влияющих на продвижение Web проекта, поисковые системы с недавних пор стали учитывать еще и это. Да и посетителей тормоза на сайте сильно раздражают, особенно тех, кто привык .
Но тем не менее для многих вебмастеров скорость загрузки не является той темой, над которой стоит начинать ломать голову немедленно, обычно это откладывают на потом в долгий ящик, а на первый план выходят насущные проблемы, связанные с наполнением ресурса уникальными материалами, улучшением его внутренней оптимизацией, но всю совокупность факторов, влияющих . Как говорится, крепость цепи определяется ее самым слабым звеном...
Онлайн сервисы для измерения скорости загрузки сайтаВо всяком случае именно так я относился до недавних пор к тому, чтобы попытаться ускорить свой ресурс. Но мне пришло в голову, что лучше не дожидаться неприятных тенденций в (а именно уменьшения трафика с , ибо она более критично относится к скорости загрузки), а исправить очевидный недочет прямо сейчас.
Надо просто осознать, что скорость , с которой загружается ваш сайт, блог или форум, является очень важным показателем . Если у вашего проекта с этим показателем не все в порядке, то это может повлечь за собой довольно неприятные последствия. И самое важное из них то, что посетители могут отказаться от работы с вашим ресурсом, т.к. он очень долго подгружает страницы. Кроме этого поисковики, в особенности Гугл, учитывают ее при общей оценке полезности того или иного ресурса.
Для того, чтобы понять, а как быстро подгружаются страницы вашего ресурса, можно воспользоваться, например, возможностями такого , подробно описанный в статье по приведенной ссылке. А можно воспользоваться услугами сервисов, которые предназначены для этого. Далее я приведу в качестве примера несколько таких.
В результате будет представлена диаграмма времени закачки отдельных объектов вебстраницы, а также их Урл и вес. Чем меньше объектов будет загружаться и чем легче будет весить каждый из них , тем лучше. Например, я для этой цели:
Собственно, некоторые проблемы и историю измерения скорости вашего сайта вы сможете отследить на соседних вкладках верхнего меню Pingdom.
Во всплывающем окне вам предложат скопировать постоянную ссылку на проделанный тест, а также отправить его по E-mail или в Твитер. Также в нижней части окна можно подписаться на на предмет доступности. Если ваш ресурс упадет (станет недоступен для посетителей), то вам будет выслано сообщение на E-mail, либо SMS на сотовый. Но эта услуга является платной, хотя и имеется возможность бесплатного триала.
Для вашего сайта, а также для просмотра Traceroute, нужно будет выбрать в самом верху страницы вкладку «Ping and Traceroute». Вводите в предлагаемую форму Урл без http, ставите галочку в чекбокс «Traceroute» или «Ping» под этой формой, и жмете «Test now».
На первой диаграмме уделяете внимание положению фиолетовой вертикальной линии - это будет время окончания отрисовки сайта . Вторая вертикальная линия (синяя) будет означать время полной загрузки . Хорошо, если первая линия находится на 1-1,5 секундах загрузки сайта, а вторая - раньше 4 секунд. Тогда следующие абзацы можно прочитать «для справки». Если сайт загружается дольше 4 секунд - то нужно озабачиваться исправлением этой ситуации.
Как видно из приведенного скриншота, Google PageSpeed Insights дает комплексную оценку — для компьютерного браузера и для мобильного. Кроме этого, внизу будет приведена оценка удобства пользования вашим ресурсом на различных гаджетах. Если вы еще не озаботились, то оценка там будет очень низкая (да и на приведенном справа скрине вашего сайта в окне смартфона все будет наглядно видно).
Но самое главное то, что Google PageSpeed Insights дает рекомендации, как увеличить оценку вашего сайта , т.е. как его ускорить. Начинать нужно, естественно, с самого верха, ибо эти исправления внесут наибольший вклад в ускорение.
У меня, например, была проблема с настройкой gzip сжатия и с заданием времени кеширования статики (картинок, css файлов и скриптов) в браузерах пользователей, ибо у меня Апач работает в связке с nginx, а с ним я работать не умею. Пришлось писать в техподдержку Инфобокса с просьбой все настроить — сделали, и даже денежек не взяли (спасибо им!). Кстати, изначально они мне поставили время хранения кеша в 1 час, но Google PageSpeed Insights по-прежнему ругался:
Пришлось покопаться в инструкции к этому онлайн сервису и вычитать там, что минимум нужно ставить 1 день хранения статики в кеше. Я попросил техподдержку хостинга поставить с запасом 1 неделю, что они и сделали. Теперича оценка чуток повысилась и шибко важных претензий к моему ресурсу у Гугла в плане скорости загрузки не имеется, что есть хорошо.
Простенько и со вкусом, что называется. Можно подписаться на рассылку изменений.
Про то, я уже довольно подробно писал и поэтому повторяться не буду, чтобы не загромождать и без того уже громоздкую статью (дочитаете до конца — можете считать себя героем).
Но вернемся от измерения скорости к поиску возможностей ее увеличения. , раньше работала экспериментальная вкладка «Эффективность сайта», где давалась оценка скорости загрузки сайта.
В общем-то ничего криминального в указанной там скорости загрузки нет, но вот то, что мой блог сайт загружался медленнее, чем 84 процента всех web ресурсов в интернете — это уже звоночек, на который следовало бы отреагировать. Но раз Гугл думает, что по скорости мой блог является аутсайдером, то стоит всерьез отнестись к этой проблеме и вплотную заняться решением вопроса — как ее увеличить.
Собственно, ничего особенно придумывать и не пришлось, ибо Google сам подсказывает наиболее оптимальное решение. Точнее, он предлагает воспользоваться инструментом, который в свою очередь поможет понять, что именно нужно предпринять для того, чтобы ваш сайт немного (или много) ускорить. Я говорю об онлайн-сервисе Page Speed (раньше были еще и одноименные расширения для браузера FireFox и Хром, которыми я в основном и пользовался).
Сразу оговорюсь, что этот инструмент оперирует достаточно сложными и не совсем понятными вещами рядовым вебмастерам, которые в основном связаны с тонкостями и нюансами работы Web сервера. Если вы никогда сервер не администрировали, но будет сложно.
Есть выход — напрячь вашего хостера на тему выполнения действий, которые предписывает Пейдж Спид. Согласится или нет — это уже другой вопрос. я так и не решился, ибо стремно предоставлять доступ к серваку абы кому (вот такой вот я недоверчивый).
На главной странице PageSpeed даже предлагает установить модуль на свой сервер, если он работает под управлением Apache или Nginx (как раз мой случай):
Но я так и не понял, как это делается, ибо совсем не смыслю в администрировании серверов и никогда не работал с юникс подобными системами. Это намного сложнее, чем программу установить или плагин в WordPress залить. Другой уровень погружения. Хостера тоже не решился по этому поводу напрягать. В общем, сей модуль остался мною не испытан — возможно, что вы его уже попробовали и имеет место что сказать...
Вообще, в первый раз я использовал Page Speed в качестве расширения для браузера (сейчас оно, как я понял не фунциклирует). Раньше оно интегрировалось в инструменты для разработчиков в Фаерфоксе и в Хроме. Правда, попервости (несколько лет назад) я лишь мельком посмотрел какие советы он мне дает, и практически ничего не поняв решил, что это не для меня, после чего с легкой душой удалил плагин PageSpeed как не нужный и чуждый моему разуму элемент.
Дело в том, что даже понимая на что ругается этот плагин, я толком не знал что нужно сделать , чтобы все это устранить и хоть как-то ускорить свой блог. В общем, у меня нашлось сразу очень много более важных дел, по сравнению с которыми мышиная возня с настройками Web сервера (тем более, что я в них и не разбираюсь особо) показалась мелкой и несущественной.
Правда, в свое время я тоже отложил в долгий ящик решение проблемы безопасности и в результате поплатился за это потерей всех этих самых денег. Памятуя о случившемся, на днях решил упереться рогом и попробовать сдвинуть с места проблему увеличения скорости загрузки сайта, несмотря на всю непонятность и сложность для меня данного вопроса.
Короче, установил я повторно Пейдж Спид в Мазилу (сейчас этого делать уже не надо), посмотрел на что именно он особо сильно ругается и кое-что мне все же удалось улучшить и, надеюсь, хотя бы немного увеличить скорость.
P.S. Сейчас Page Speed можно использовать только онлайн и устанавливать его в браузер уже не требуется (во всяком случае с новыми версиями хрома этот плагин несовместим), хотя сути это не меняет.
Итак, раньше нужно было установить в свой браузер плагин, но сейчас достаточно перейти сюда , ввести Урл адрес страницы, которую вы хотите проанализировать (на разных типах страниц могут возникать разные проблемы со скоростью загрузки, посему в этом инструменте имеет смысл проверять все варианты) и нажать на синюю кнопку «Анализировать».
Дождавшись результатов процесса проверки вы увидите окно подобное тому, что я уже приводил на скриншоте выше по тексту (в пункте 3 описаний онлайн сервисов по проверки скорости загрузки сайтов). Т.о. в результате вы увидите целый список претензий, которые этот онлайн сервис имеет к вашему ресурсу, а именно к скорости его загрузки. Пир этом он даст вам некоторые указания по оптимизации работы Web сервера в купе с используемым вами движком.
Причем, в самом верху окна Page Speed будут расположены замечания и рекомендации, которые вам желательно будет посмотреть и изменить в первую очередь («исправьте обязательно»), ибо это даст наибольший эффект в плане увеличения скорости загрузки и потребует от вас не слишком больших усилий. Приведу пример анализа одного из моих второстепенных проектов, до которых руки особо не доходят:
Т.е. рекомендации и обнаруженные проблемы, помеченные красным прямоугольником с восклицательным знаком и расположенные в самом верху списка, являются наиболее важным и начать оптимизацию желательно именно с них (дешево и сердито, что называется), тем самым добьетесь наибольшего эффекта.
Замечания, помеченные оранжевым цветом, потребуют от вас больших усилий по исправлению, но при этом могут и не привести к очень значительному росту скорости. Увы и ах, пока их можно отложить в долгий ящик и заняться первостепенными задачами, которые помогут существенно ускорить проект.
У меня первоначальная картина несколько лет назад (еще при использовании плагина — сейчас то же самое можно увидеть в http://gtmetrix.com/ , ибо он испльзует АПИ PageSpeed) для https://сайт была такой:
Я решил тогда начать с самого первого пункта «Leverage browser caching» (сейчас это называется «Используйте кеш браузера» ), ибо по логике работы Page Speed, эти рекомендации должны привести к наибольшему ускорению моего блога.
Если нажать на спойлер рядом с этой надписью, то появится список различных файлов, которые не удовлетворяют оптимальным требованиям кэширования статических объектов (скрипты, CSS файлы, файлы изображений используемых на web странице) в браузерах пользователей (т.е. у читателей):
Т.е. PageSpeed Insights советует нам для увеличения скорости загрузки настроить оптимальным образом кэширование различных элементов web страниц в браузерах пользователей для того, чтобы при просмотре других эти статические элементы не подгружались бы заново с сервера. В теории все это звучит довольно запутано, ибо я понятия не имею о механизмах кэширования используемого браузерами (читайте про то, и как его очистить).
К тому же, оптимизацию кэширования статических объектов мы будем проводить за счет механизмов самого сервера вашего хостинга. Довольно запутанно, но я вам предложу уже готовые решения, найденные на просторах рунета, а вы их попробуете в действии и решите, какое именно наилучшим образом будет работать именно на вашем хостинге.
Оптимизация кэширования в браузере и проверка его работыПравда на моем текущем хостинге это не сработало, ибо у меня сейчас стоит связка Апача с nginx (настраивать надо последний, что за меня сделал хостер не ведомым мне способом). Но если у вас чистый Апач, то предложенный ниже метод может сработать.
В общем, мы попытаемся повлиять на сервер где хостится ваш проект таким образом, чтобы он отдавал браузерам команды направленные на оптимизацию кэширования статических элементов. Делать это будем посредством довольно известного инструмента удаленного управления сервером — файла.htaccess . Знаете о существовании такого?
Живет он обычно в корневой папке. Естественно, что все нижеописанное будет работать только на серверах под управлением Apache, но их, как правило, большинство. После подключения к своему ресурсу по FTP (), откройте корневую папку (обычно это либо PUBLIC_HTML, либо HTDOCS) и проверьте наличие в ней файла.htaccess.
С этого момента вы все делаете на свой страх и риск. Посему обязательно скачайте на комп копию этого файла, чтобы в случае чего оперативно откатиться назад.
Если .htaccess не видно, то попробуйте в программе FileZilla выбрать из верхнего меню пункты «Сервер» — «Принудительно отображать скрытые файлы». Если и после этого он в корне не проявился, то создайте у себя на компьютере пустой текстовый файл в любом удобном для вас редакторе (я пользуюсь Нотепад плюс плюс), назовите его как-нибудь и скопируйте в корень.
После этого переименуйте этот файл в.htaccess в программе FileZilla. Теперь нужно будет открыть его на редактирование и добавить в него приведенный ниже код. Но сначала чуток поясню.
Наиболее популярные способы включения данной опции на веб-сервере под управлением Апач — с помщью модулей mod_headers или mod_expires. Расположенный ниже код поможет помочь вам включить кеширование статики в браузере, если онлайн-сервис хотя бы один из этих модулей Апача у вас на серваке установлен.
Сначала приведу код для модуля mod_headers . Обращаю ваше внимание, что в нем используется проверка наличия у вашего хостера данного модуля. Если его найдено не будет, то код выполняться не будет и никаких ошибок это не вызовет. Однако, я еще раз настоятельно рекомендую предварительно скопировать оригинальный (до внесения расположенного ниже кода) файл.htaccess к себе на комп во избежании эксцессов.
#кэшировать html и htm файлы на один день Header set Cache-Control "max-age=43200" #кэшировать css, javascript и текстовые файлы на одну неделю Header set Cache-Control "max-age=604800" #кэшировать флэш и изображения на месяц Header set Cache-Control "max-age=2592000" #отключить кэширование Header unset Cache-Control
Комментарии (их строки начинаются со знака решетки) потом можете удалить, но они по-любому на работу кода влияния оказывать не будут.
Можно будет еще добавить блок кода, рассчитанного на модуль для mod_expires , где опять же используется проверка его наличия на вашем сервере, что гарантирует безопасность использования этого фрагмента кода:
ExpiresActive On #по умолчанию кеш в 5 секунд ExpiresDefault "access plus 5 seconds" #кэшировать флэш и изображения на месяц ExpiresByType image/x-icon "access plus 2592000 seconds" ExpiresByType image/jpeg "access plus 2592000 seconds" ExpiresByType image/png "access plus 2592000 seconds" ExpiresByType image/gif "access plus 2592000 seconds" ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds" #кэшировать css, javascript и текстовые файлы на одну неделю ExpiresByType text/css "access plus 604800 seconds" ExpiresByType text/javascript "access plus 604800 seconds" ExpiresByType application/javascript "access plus 604800 seconds" ExpiresByType application/x-javascript "access plus 604800 seconds" #кэшировать html и htm файлы на один день ExpiresByType text/html "access plus 43200 seconds" #кэшировать xml файлы на десять минут ExpiresByType application/xhtml+xml "access plus 600 seconds"
Комментарии опять же потом можно будет удалить.
Если вдруг не сработало, но вы надеетесь на чудо, то вот еще несколько вариантов того же самого кода, но пробуйте их по очереди, а не все сразу:
Теперь после того, как вы вставили в.htaccess код, позволяющий повысить скорость за счет оптимизации кэширования в браузере на стороне посетителя, и сохранили произведенные изменения, снова проверьте страницу вашего ресурса в PageSpeed Insights и убедитесь что проблема пропала :
Как видите, в моем случае «Используйте кеш браузера» уже не является критической недоработкой замедляющей загрузку, и значок рядом с этим замечанием сменился на оранжевый, но не на зеленый. К сожалению, повлиять на сторонние сервисы, откуда мой сайт подгружает статики (типа Янедкс, Гугла, Фидбернера и Аптулайка), я не в состоянии.
Что и требовалось доказать. Вот так вот играючи мы с вами разобрались с одной из самых существенных и весомых проблем найденных в Page Speed.
Как включить сжатие статических объектов на сервереТакже очень частой проблемой, на которую ругается сервис GTmetrix, бывает отсутствие сжатия файлов на сервере перед их передачей в браузеры пользователей.
Используется при этом , о который я уже писал. Если вы анализируете не напрямую через PageSpeed Insights, а посредством GTmetrix, то в области PageSpeed «Включить сжатие» называется «Enable gzip compression», а в YSlow - «Compress components with gzip».
Для того, чтобы это самое Gzip сжатие включить на хостингах, где используется сервер Апач, достаточно будет добавить в файл.htaccess (он является дистанционным файлом управления сервером) соответствующий фрагмент кода. У Апача есть два модуля для сжатия и какой-нибудь из них будет установлен у вашего хостера (хотя не факт).
Наиболее распространен — с него и начнем. Мы опять же добавляем в код проверку наличия этого модуля, чтобы не получить 500 ошибку для всего сайта.
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
Чуть менее популярным и для него код включения Gzip сжатия для нужных типов файлов будет выглядеть так:
mod_gzip_on Yes mod_gzip_dechunk Yes mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$ mod_gzip_item_include mime ^text\.* mod_gzip_item_include mime ^application/x-javascript.* mod_gzip_item_exclude mime ^image\.* mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
Собственно, пробуйте и проверяйте страницу в PageSpeed Insights после установки кода. Если проблема ушла, то считайте, что вам повезло. Мне же в силу наличия Апач с nginx все это не помогло (хостер сказал, что за статику отвечает nginx, при таком раскладе и настраивать надо именно его — как он это сделал мне не ведомо).
Удачи вам! До скорых встреч на страницах блога сайт
Вам может быть интересно
Измерение и увеличение скорости сайта в GTmetrix, а так же настройка загрузки библиотеки jQuery с Google CDN
Gzip сжатие для ускорения загрузки сайта - как его включить для Js, Html и Css с помощью файла.htaccess
Как увеличить скорость загрузки сайта по максимуму и оптимизация нагрузки на сервер
Ускорение сайта - что дает, как измерить и как самому ускорить сайт
Создание CSS спрайтов в онлайн генераторе Sprites Me для снижения числа запросов к серверу
Оптимизация и сжатие CSS в Page Speed - как отключить внешние файлы стилей и объединить их в один для ускорения загрузки
Как получить быстрый сайт - оптимизация (сжатие) изображений и скриптов, а так же уменьшение числа Http запросов
Многие из Вас наверное пользовались замечательным сервисом от Google: PageSpeed Insights ? Хотите получить заветные 100 из 100?
Картинка для привлечения внимания
А дело-то за маленьким.
Итак, результаты моего теста. Берем любой сайт, например, я взял бесплатный готовый адаптивный шаблон сайта перенес к себе на хостинг и запустил тестирование: Результат первого тестирования (ссылка на сайт):- скорость для мобильных - 79/100;
- скорость для компьютера - 93/100;
Жалуется на:
Исправьте обязательно:Удалите из верхней части страницы код JavaScript и CSS, блокирующий отображение.
Количество блокирующих ресурсов CSS на странице: 3. Они замедляют отображение контента.
Все содержание верхней части страницы отображается только после загрузки указанных далее ресурсов. Попробуйте отложить загрузку этих ресурсов, загружать их асинхронно или встроить их самые важные компоненты непосредственно в код HTML.
Делаем небольшие махинации. Переносим стили из файла в код:
Было:
Стало:
article, aside, details, figcaption, figure, footer, header, hgroup, nav, section { display:block; }
/* и другие стили */
И - ура! - у нас результаты выше (ссылка на сайт):
- скорость для мобильных - 99/100;
- скорость для компьютера - 99/100;
Сократите HTML
Сжатие HTML-кода (в том числе встроенного кода JavaScript или CSS) позволяет сократить объем данных, чтобы ускорить загрузку и обработку. Но это проблему можно решить сжатием кода. К данной теме не относиться.
А также мы не забываем, что все-таки мы не решили проблему описанную выше:
Все содержание верхней части страницы отображается только после загрузки указанных далее ресурсов. Попробуйте отложить загрузку этих ресурсов, загружать их асинхронно или встроить их самые важные компоненты непосредственно в код HTML. Сколько они весили в файле, столько же весят и в коде!
А теперь самый главный вопрос: Баг или фича?
Спасибо!
