Гугл спид

Еще в январе 2018 Google анонсировал новый алгоритм ранжирования, созданный специально для мобильного поиска – Speed Update. Запуск произойдет буквально через несколько дней, в июле этого года.

Скорость загрузки сайта

Алгоритм станет учитывать скорость загрузки страниц для мобильных устройств в мобильном поиске Google. До этого поисковик учитывал только скорость загрузки для компьютеров.

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

PageSpeed Insights

Важно: Не стоит всеми силами стремиться увеличить скорость до 100 пунктов. Сайт должен работать корректно и не доставлять проблем пользователям. Достаточно вывести сайт в зеленую зону.

Оригинал выступления со встречи можно увидеть на этом видео:


Проверить скорость загрузки сайта можно с помощью официального инструмента Google PageSpeed.

Особое внимание обратите на эти проблемы:

  • Оптимизация изображений. Используйте сжатие изображений перед загрузкой на сайт.
  • JavaScript и CSS код, блокирующий отображение верхней части страницы. Если это технически возможно, все скрипты рекомендуем размещать в подвале страницы. Так они не будут мешать загрузке.

Но важно помнить: скорость загрузки сайта – лишь один из факторов ранжирования в мобильном поиске. В первую очередь, нужно проверить, правильно ли адаптирован сайт под мобильные устройства. Если сайт не адаптирован, пишите нам, обязательно поможем.

1ps.ru

Онлайн сервисы для измерения скорости загрузки сайта


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

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

Для того, чтобы понять, а как быстро подгружаются страницы вашего ресурса, можно воспользоваться, например, возможностями такого расширения для браузера FireFox, как FireBug, подробно описанный в статье по приведенной ссылке. А можно воспользоваться услугами сервисов, которые предназначены для этого. Далее я приведу в качестве примера несколько таких.

  1. Pingdom — здесь достаточно просто указать адрес страницы, скорость загрузки которой вы хотите измерить (это не обязательно должна быть главная страница, ибо скорость загрузки внутренних страниц не менее, а зачастую даже более важна).

    Гугл спид

    В результате будет представлена диаграмма времени закачки отдельных объектов вебстраницы, а также их Урл и вес. Чем меньше объектов будет загружаться и чем легче будет весить каждый из них, тем лучше. Например, я для этой цели:


    1. объединил некоторые картинки из темы оформления сайта в так называемые спрайты
    2. а также по возможности уменьшил путем объединения число подгружаемых файлов стилей (CSS) и скриптов
    3. кроме этого имеется смысл включить Gzip сжатие статики на сервере
    4. и оптимизировать все используемые на сайте картинки

    Гугл спид

    Собственно, некоторые проблемы и историю измерения скорости вашего сайта вы сможете отследить на соседних вкладках верхнего меню Pingdom.

    Во всплывающем окне вам предложат скопировать постоянную ссылку на проделанный тест, а также отправить его по E-mail или в Твитер. Также в нижней части окна можно подписаться на мониторинг сайта на предмет доступности. Если ваш ресурс упадет (станет недоступен для посетителей), то вам будет выслано сообщение на E-mail, либо SMS на сотовый. Но эта услуга является платной, хотя и имеется возможность бесплатного триала.

    Для измерения пинга для вашего сайта, а также для просмотра Traceroute, нужно будет выбрать в самом верху страницы вкладку «Ping and Traceroute». Вводите в предлагаемую форму Урл без http, ставите галочку в чекбокс «Traceroute» или «Ping» под этой формой, и жмете «Test now».


  2. WebPageTest — как обычно, вводите Урл проверяемой страницы (не обязательно главной). Сервис некоторое время обсчитывает скорость загрузки всех элементов сайта, после чего выдает очень наглядную диаграмму (точнее даже две — за первый проход и за второй, когда уже часть элементов сайта загружаются из кеша браузера):

    Гугл спид

    На первой диаграмме уделяете внимание положению фиолетовой вертикальной линии — это будет время окончания отрисовки сайта. Вторая вертикальная линия (синяя) будет означать время полной загрузки. Хорошо, если первая линия находится на 1-1,5 секундах загрузки сайта, а вторая — раньше 4 секунд. Тогда следующие абзацы можно прочитать «для справки». Если сайт загружается дольше 4 секунд — то нужно озабачиваться исправлением этой ситуации.

  3. Google PageSpeed Insights — это инструмент для разработчиков от самого Гугла. Он дает оценку скорости загрузки вашего сайта (а точнее оптимизации этой скорости) по стобальной шкале. 100 — это идеал, который недостижим, а вот 80-90 получить вполне реально, тем более, что сервис дает очень подробные рекомендации по исправлению выявленных недочетов.


    Гугл спид

    Как видно из приведенного скриншота, Google PageSpeed Insights дает комплексную оценку — для компьютерного браузера и для мобильного. Кроме этого, внизу будет приведена оценка удобства пользования вашим ресурсом на различных гаджетах. Если оптимизацией сайта под мобильные устройства вы еще не озаботились, то оценка там будет очень низкая (да и на приведенном справа скрине вашего сайта в окне смартфона все будет наглядно видно).

    Но самое главное то, что Google PageSpeed Insights дает рекомендации, как увеличить оценку вашего сайта, т.е. как его ускорить. Начинать нужно, естественно, с самого верха, ибо эти исправления внесут наибольший вклад в ускорение.

    У меня, например, была проблема с настройкой gzip сжатия и с заданием времени кеширования статики (картинок, css файлов и скриптов) в браузерах пользователей, ибо у меня Апач работает в связке с nginx, а с ним я работать не умею. Пришлось писать в техподдержку Инфобокса с просьбой все настроить — сделали, и даже денежек не взяли (спасибо им!). Кстати, изначально они мне поставили время хранения кеша в 1 час, но Google PageSpeed Insights по-прежнему ругался:

    Гугл спид

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


  4. Test my Site — новый сервис опять же от Гугла. В основном он делает акцент на оценку мобильной версии вашего сайта в том числе и по критерию его скорости загрузки:

    Гугл спид

    Простенько и со вкусом, что называется. Можно подписаться на рассылку изменений.

  5. GTmetrix — опять таки «не мудрствуя лукаво» вводите Урл нужной страницы и чуток ждете окончания анализа. В результате вы получите отчет, сформированный на основе данных двух плагинов для браузеров — Page Speed (читайте о работе с ним ниже) и YSlow. Собственно, каким данным доверять и чьим рекомендациям следовать — решать вам.

    Гугл спид

    Про то, что еще хорошего есть в GTmetrix и как его использовать я уже довольно подробно писал и поэтому повторяться не буду, чтобы не загромождать и без того уже громоздкую статью (дочитаете до конца — можете считать себя героем).

  6. Ping Admin — аналогичный онлайн ресурс для измерения время ответа сервера с разных уголков нашей огромной планеты.
    Гугл спид

  7. Host Tracker — практически то же самое, только страны другие.
  8. ByteCheck — позволяет измерить значение TTFB (Time To First Byte) для вашего сайта, на который часто обращают внимание при оптимизации. Это время получения первого байта данных браузером с сервера. Чем выше значение TTFB, тем медленнее обработка ресурсов сервером, что есть плохо. Читайте советы по оптимизации загрузки сайтов.
  9. Load Impact — это не совсем про скорость, но тоже важный сервис. Он позволяет протестировать нагрузочную способность вашего сайта и то, падает ли при этом скорость загрузки страниц. Весьма полезная штука.
  10. Web Page Speed — онлайн-сервис с дизайном начала девяностых, но вполне себе такой информативный, если приспособитесь к отсутствию юзабилити. Внизу даются общие рекомендации по исправлению ситуации.

Так ли важно отслеживать скорость загрузки страниц?

Но вернемся от измерения скорости к поиску возможностей ее увеличения. В Гугл Вебмастере, о котором я писал тут, раньше работала экспериментальная вкладка «Эффективность сайта», где давалась оценка скорости загрузки сайта.

Гугл спид

В общем-то ничего криминального в указанной там скорости загрузки нет, но вот то, что мой блог KtoNaNovenkogo.ru загружался медленнее, чем 84 процента всех web ресурсов в интернете — это уже звоночек, на который следовало бы отреагировать. Но раз Гугл думает, что по скорости мой блог является аутсайдером, то стоит всерьез отнестись к этой проблеме и вплотную заняться решением вопроса — как ее увеличить.


Собственно, ничего особенно придумывать и не пришлось, ибо Google сам подсказывает наиболее оптимальное решение. Точнее, он предлагает воспользоваться инструментом, который в свою очередь поможет понять, что именно нужно предпринять для того, чтобы ваш сайт немного (или много) ускорить. Я говорю об онлайн-сервисе Page Speed (раньше были еще и одноименные расширения для браузера FireFox и Хром, которыми я в основном и пользовался).

Сразу оговорюсь, что этот инструмент оперирует достаточно сложными и не совсем понятными вещами рядовым вебмастерам, которые в основном связаны с тонкостями и нюансами работы Web сервера. Если вы никогда сервер не администрировали, но будет сложно.

Есть выход — напрячь вашего хостера на тему выполнения действий, которые предписывает Пейдж Спид. Согласится или нет — это уже другой вопрос. Нанимать для этой цели фрилансера я так и не решился, ибо стремно предоставлять доступ к серваку абы кому (вот такой вот я недоверчивый).

На главной странице PageSpeed даже предлагает установить модуль на свой сервер, если он работает под управлением Apache или Nginx (как раз мой случай):


Гугл спид

Но я так и не понял, как это делается, ибо совсем не смыслю в администрировании серверов и никогда не работал с юникс подобными системами. Это намного сложнее, чем программу установить или плагин в WordPress залить. Другой уровень погружения. Хостера тоже не решился по этому поводу напрягать. В общем, сей модуль остался мною не испытан — возможно, что вы его уже попробовали и имеет место что сказать…

Вообще, в первый раз я использовал Page Speed в качестве расширения для браузера (сейчас оно, как я понял не фунциклирует). Раньше оно интегрировалось в инструменты для разработчиков в Фаерфоксе и в Хроме. Правда, попервости (несколько лет назад) я лишь мельком посмотрел какие советы он мне дает, и практически ничего не поняв решил, что это не для меня, после чего с легкой душой удалил плагин PageSpeed как не нужный и чуждый моему разуму элемент.

Дело в том, что даже понимая на что ругается этот плагин, я толком не знал что нужно сделать, чтобы все это устранить и хоть как-то ускорить свой блог. В общем, у меня нашлось сразу очень много более важных дел, по сравнению с которыми мышиная возня с настройками Web сервера (тем более, что я в них и не разбираюсь особо) показалась мелкой и несущественной.

Правда, в свое время я тоже отложил в долгий ящик решение проблемы безопасности при работе с электронными деньгами Webmoney и в результате поплатился за это потерей всех этих самых денег. Памятуя о случившемся, на днях решил упереться рогом и попробовать сдвинуть с места проблему увеличения скорости загрузки сайта, несмотря на всю непонятность и сложность для меня данного вопроса.


Короче, установил я повторно Пейдж Спид в Мазилу (сейчас этого делать уже не надо), посмотрел на что именно он особо сильно ругается и кое-что мне все же удалось улучшить и, надеюсь, хотя бы немного увеличить скорость.

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

Page Speed — анализ скорости и советы по ее увеличению

P.S. Сейчас Page Speed можно использовать только онлайн и устанавливать его в браузер уже не требуется (во всяком случае с новыми версиями хрома этот плагин несовместим), хотя сути это не меняет.

Итак, раньше нужно было установить в свой браузер плагин, но сейчас достаточно перейти сюда, ввести Урл адрес страницы, которую вы хотите проанализировать (на разных типах страниц могут возникать разные проблемы со скоростью загрузки, посему в этом инструменте имеет смысл проверять все варианты) и нажать на синюю кнопку «Анализировать».

Гугл спид

Дождавшись результатов процесса проверки вы увидите окно подобное тому, что я уже приводил на скриншоте выше по тексту (в пункте 3 описаний онлайн сервисов по проверки скорости загрузки сайтов). Т.о. в результате вы увидите целый список претензий, которые этот онлайн сервис имеет к вашему ресурсу, а именно к скорости его загрузки. Пир этом он даст вам некоторые указания по оптимизации работы Web сервера в купе с используемым вами движком.

Причем, в самом верху окна Page Speed будут расположены замечания и рекомендации, которые вам желательно будет посмотреть и изменить в первую очередь («исправьте обязательно»), ибо это даст наибольший эффект в плане увеличения скорости загрузки и потребует от вас не слишком больших усилий. Приведу пример анализа одного из моих второстепенных проектов, до которых руки особо не доходят:

Гугл спид

Т.е. рекомендации и обнаруженные проблемы, помеченные красным прямоугольником с восклицательным знаком и расположенные в самом верху списка, являются наиболее важным и начать оптимизацию желательно именно с них (дешево и сердито, что называется), тем самым добьетесь наибольшего эффекта.

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

У меня первоначальная картина несколько лет назад (еще при использовании плагина — сейчас то же самое можно увидеть в http://gtmetrix.com/, ибо он испльзует АПИ PageSpeed) для https://ktonanovenkogo.ru была такой:

Гугл спид

Я решил тогда начать с самого первого пункта «Leverage browser caching» (сейчас это называется «Используйте кеш браузера»), ибо по логике работы Page Speed, эти рекомендации должны привести к наибольшему ускорению моего блога.

Если нажать на спойлер рядом с этой надписью, то появится список различных файлов, которые не удовлетворяют оптимальным требованиям кэширования статических объектов (скрипты, CSS файлы, файлы изображений используемых на web странице) в браузерах пользователей (т.е. у читателей):

Гугл спид

Т.е. PageSpeed Insights советует нам для увеличения скорости загрузки настроить оптимальным образом кэширование различных элементов web страниц в браузерах пользователей для того, чтобы при просмотре других эти статические элементы не подгружались бы заново с сервера. В теории все это звучит довольно запутано, ибо я понятия не имею о механизмах кэширования используемого браузерами (читайте про то, что такое кэш браузера и как его очистить).

К тому же, оптимизацию кэширования статических объектов мы будем проводить за счет механизмов самого сервера вашего хостинга. Довольно запутанно, но я вам предложу уже готовые решения, найденные на просторах рунета, а вы их попробуете в действии и решите, какое именно наилучшим образом будет работать именно на вашем хостинге.

Оптимизация кэширования в браузере и проверка его работы

Правда на моем текущем хостинге это не сработало, ибо у меня сейчас стоит связка Апача с nginx (настраивать надо последний, что за меня сделал хостер не ведомым мне способом). Но если у вас чистый Апач, то предложенный ниже метод может сработать.

В общем, мы попытаемся повлиять на сервер где хостится ваш проект таким образом, чтобы он отдавал браузерам команды направленные на оптимизацию кэширования статических элементов. Делать это будем посредством довольно известного инструмента удаленного управления сервером — файла .htaccess. Знаете о существовании такого?

Живет он обычно в корневой папке. Естественно, что все нижеописанное будет работать только на серверах под управлением Apache, но их, как правило, большинство. После подключения к своему ресурсу по FTP (FTP клиент FileZilla был описан мною тут), откройте корневую папку (обычно это либо PUBLIC_HTML, либо HTDOCS) и проверьте наличие в ней файла .htaccess.

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

Если .htaccess не видно, то попробуйте в программе FileZilla выбрать из верхнего меню пункты «Сервер» — «Принудительно отображать скрытые файлы». Если и после этого он в корне не проявился, то создайте у себя на компьютере пустой текстовый файл в любом удобном для вас редакторе (я пользуюсь Нотепад плюс плюс), назовите его как-нибудь и скопируйте в корень.

После этого переименуйте этот файл в .htaccess в программе FileZilla. Теперь нужно будет открыть его на редактирование и добавить в него приведенный ниже код. Но сначала чуток поясню.

Наиболее популярные способы включения данной опции на веб-сервере под управлением Апач — с помщью модулей mod_headers или mod_expires. Расположенный ниже код поможет помочь вам включить кеширование статики в браузере, если онлайн-сервис хотя бы один из этих модулей Апача у вас на серваке установлен.

Сначала приведу код для модуля mod_headers. Обращаю ваше внимание, что в нем используется проверка наличия у вашего хостера данного модуля. Если его найдено не будет, то код выполняться не будет и никаких ошибок это не вызовет. Однако, я еще раз настоятельно рекомендую предварительно скопировать оригинальный (до внесения расположенного ниже кода) файл .htaccess к себе на комп во избежании эксцессов.

<ifModule mod_headers.c>  #кэшировать html и htm файлы на один день  <FilesMatch ".(html|htm)$">  Header set Cache-Control "max-age=43200"  </FilesMatch>  #кэшировать css, javascript и текстовые файлы на одну неделю  <FilesMatch ".(js|css|txt)$">  Header set Cache-Control "max-age=604800"  </FilesMatch>  #кэшировать флэш и изображения на месяц  <FilesMatch ".(flv|swf|ico|gif|jpg|jpeg|png)$">  Header set Cache-Control "max-age=2592000"  </FilesMatch>  #отключить кэширование  <FilesMatch ".(pl|php|cgi|spl|scgi|fcgi)$">  Header unset Cache-Control  </FilesMatch> </IfModule>

Комментарии (их строки начинаются со знака решетки) потом можете удалить, но они по-любому на работу кода влияния оказывать не будут.

Можно будет еще добавить блок кода, рассчитанного на модуль для mod_expires, где опять же используется проверка его наличия на вашем сервере, что гарантирует безопасность использования этого фрагмента кода:

<ifModule mod_expires.c>  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" </ifModule>

Комментарии опять же потом можно будет удалить.

Если вдруг не сработало, но вы надеетесь на чудо, то вот еще несколько вариантов того же самого кода, но пробуйте их по очереди, а не все сразу:

  1. <IfModule mod_expires.c>  ExpiresActive On  ExpiresByType application/javascript "access plus 1 year"  ExpiresByType text/javascript "access plus 1 year"  ExpiresByType text/css "access plus 1 year"  ExpiresByType image/gif "access plus 1 year"  ExpiresByType image/jpeg "access plus 1 year"  ExpiresByType image/png "access plus 1 year" </IfModule>
  2. <IfModule mod_headers.c>  <FilesMatch .*.(js|css)$>  Header set Cache-control: private  </FilesMatch>  <FilesMatch .*.(gif|jpg|png)$>  Header set Cache-control: public  </FilesMatch> </IfModule>
  3. <IfModule mod_setenvif.c>  BrowserMatch "MSIE" force-no-vary  BrowserMatch "Mozilla/4.[0-9]{2}" force-no-vary </IfModule>
  4. FileETag MTime Size <ifmodule mod_expires.c> <filesmatch ".(jpg|jpeg|gif|png|ico|css|js)$"> ExpiresActive on ExpiresDefault "access plus 1 month" </filesmatch> </ifmodule>

Теперь после того, как вы вставили в .htaccess код, позволяющий повысить скорость за счет оптимизации кэширования в браузере на стороне посетителя, и сохранили произведенные изменения, снова проверьте страницу вашего ресурса в PageSpeed Insights и убедитесь что проблема пропала:

Гугл спид

Как видите, в моем случае «Используйте кеш браузера» уже не является критической недоработкой замедляющей загрузку, и значок рядом с этим замечанием сменился на оранжевый, но не на зеленый. К сожалению, повлиять на сторонние сервисы, откуда мой сайт подгружает статики (типа Янедкс, Гугла, Фидбернера и Аптулайка), я не в состоянии.

Что и требовалось доказать. Вот так вот играючи мы с вами разобрались с одной из самых существенных и весомых проблем найденных в Page Speed.

ktonanovenkogo.ru

Как увеличить скорость загрузки страниц

Прежде чем перейти непосредственно к советам, стоит обратить внимание, что Google PageSpeed Tool лишь предоставляет рекомендации, следуя которым можно достичь более высокой производительности сайта. Итоговый результат зависит, в первую очередь, от вашей серверной инфраструктуры, ресурсов и выбранных настроек.

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

Шаг #1: Оптимизируем изображения

lhyAb0mKmp5aPP8XkyMlLhHHTKbMURRWciyzWOeM

PageSpeed Insights Tool проверит изображения на вашем сайте, и если скорость их загрузки окажется недостаточно высокой, Google предложит их оптимизировать. Вы можете увеличить скорость загрузки изображений, уменьшив их вес и размер. Чтоб решить эту задачу достаточно выполнить два шага:

  • Для начала, сожмите все изображениями инструментами типа Compressor.io или TinyPNG. Оба инструменты бесплатны, но крайне эффективны. В некоторых случаях они сжимают картинки на 80% без потери качества.
  • Уменьшите размер изображений до минимально возможного. Допустим, вы хотите, чтоб размер отображаемой на сайте картинки составлял 150x150px. В таком случае фактический размер изображения, хранящегося на вашем сервере, не должен превышать размеров отображаемого изображения, то есть он также должен составлять 150x150px. Не стоит подгонять размер картинки с помощью CSS или HTML кода.

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

Google предложит сразу загрузить оптимизированные изображения на сайт.

Шаг #2: Максимально сократите CSS и JavaScript код

Jx0tpLCXrENgH1FJ-rGL_t0lA1IzMZ_KATNuSJiw

Google может попросить вас сократить JavaScript и CSS код.

Под сокращением в первую очередь подразумевается удаление лишних пробелов, пустых строк, ненужных комментариев и так далее, которые разработчики оставляют при написании кода. Все вместе эти нежелательные элементы могут увеличить размер JavaScript и CSS файла в два раза.

Например, код в документе, приведенном ниже,

3TaxMR3WaJjlByzESo6hO1FT65ZWD8BUfExWGpH1

может быть сокращен до:

Cf02oz7-5rKEFmSUJB4SrKaDDfhMocAVgKbQoRUZ

Чтобы быстро решить эту задачу можно установить на свой сервер инструмент, который называется Gulpjs. На основе вашего файла он автоматически создает новый CSS файл, в котором удалены все ненужные пробелы. Фактически, этот инструмент может помочь сократить размер файла в два раза. Еще больше информации о том, как удалить лишние элементы кода, можно почерпнуть в официальном справочном руководстве Google.

А для сайтов на WordPress рекомендуется установить плагин Autoptimize.

Шаг #3: Используйте кэш браузера

_T-5CIADwmap_A8EoAvgUm07z6qXX17q9rcVHn3j

Для многих сайтов пункт об использовании кэша браузера — настоящее испытание. Для решения этой проблемы можно использовать сеть CDN.

CDN — это сокращение от content delivery network, то есть “сеть доставки контента”. Чаще всего это множество серверов со специализированным ПО, которые ускоряют доставку (“отдачу”) контента конечному пользователю. С её помощью можно кэшировать и сохранять многие элементы сайта, такие как изображения, CSS и JavaScript файлы. CDN хранит копии содержимого сайта на серверах. Если пользователь заходит на сайт, контент для него загружается с ближайшего к нему сервера.

Допустим, главный сервер вашего сайта расположен в Техасе, если вы не используете CDN, то пользователь, который находится в Амстердаме, будет вынужден ждать, пока ваш американский сервер загрузит для него контент, а это может занять немало времени. В то же самое время использование CDN позволяет загружать сайт из точки, расположенной к пользователю максимально близко. А в данном случае, максимально близко к Амстердаму.

Как результат, сайт загружается значительно быстрее.

Если вы переместите все изображения, файлы JavaScript и CSS на сеть CDN, то ваши удаленные пользователи сразу заметят ощутимое увеличение скорости загрузки страниц. Но даже использование CDN не гарантирует, что вы пройдете тест Google. Google также обращает внимание на все внешние ресурсы, которые вы используете на своем сайте.

-QtxReg-QXJ4wGEz_8J1BydkLAMzsPvIy_HBbdqt

Эту проблему можно решить, заменив счетчики изображениями, которые вы можете спокойно хранить с помощью CDN. Вместо того чтобы размещать сторонние скрипты, которые получают информацию о количестве подписчиков из Twitter, Facebook, Google Plus и других соцсетей, можно хранить эти данные самостоятельно, снизив, таким образом, скорость загрузки страниц.

Если ваш сайт интегрирован с Google Analytics и вы не хотите отказываться от интеграции, то решение проблемы может потребовать дополнительных усилий.

Google редко меняет код Analytics, как правило, не более пары раз за год, поэтому можно создать скрипт, который будет проверять Analytics на наличие изменений раз в сутки. Новый код будет загружаться только, если были обнаружены изменения. В таком случае, вы сможете спокойно хранить JavaScript код Analytics, не скачивая его при этом с серверов Google каждый раз при обращении к ним.

Если скрипт обнаружит изменения, то новая версия автоматически скачается и сохранится в вашей сети CDN.

Та же самая операция будет повторяться каждый раз, когда происходит обновление кода. Новая версия скачивается и сохраняется на CDN. Этот же скрипт можно использовать и для других сторонних ресурсов.

Шаг #4: Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы

yg-2HcJJmFYRkXmeaDXOHJpdPLH1NDPd75qFiylQ

Удаление кода, блокирующего отображение верхней части страницы — один из самых сложных моментов при оптимизации скорости загрузки страницы, поскольку требует глубоких технических знаний. Обратите внимание, что код JavaScript следует всегда размещать в конце файла.

Если ваш сайт на WordPress, то решить задачу вам может помочь тот же самый плагин Autoptimize. Зайдите в настройки, уберите галочку возле “Force JavaScript in Head” и поставьте рядом с “Inline all CSS.”

Шаг #5: Включите сжатие

_vBJHGRwaF9MI8M2fxdvbgaexSLSfwXbzO5bSkDR

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

Шаг #6: Оптимизируйте сайт для мобильных устройств

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

vYDPyti8-3XD9RH89CIyZWLZL5RHMpW8LAND_9Mp

Google Chrome позволяет проверить, как ваш сайт будет отображаться при просмотре на разных мобильных устройствах. Нажмите на контекстное меню в правом верхнем углу, после этого выберите пункт “Дополнительные инструменты”, а затем “Инструменты разработчика”. В выпадающем меню вы можете выбрать тип устройства и проверить, как выглядит ваша страница при просмотре с каждого из них.

Заключение

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

Ниже кратко перечислены три основных шага, которые помогут добиться более высокой производительности сайта:

  1. Используйте сеть CDN (content delivery network).
  2. Удалите код, блокирующий отображение верхней части страницы. (Не размещайте JavaScript в середине файла. Код JavaScript должен находиться в конце документа).
  3. Оптимизируйте размер изображений и сожмите их.

Ставили ли вы перед собой задачу оптимизировать скорость работы сайта? Если да, то какие шаги вы предпринимали?

(перевод и адаптация статьи Felix Tarcomnicu How to Achieve 100/100 with the Google Page Speed Test Tool)

spark.ru


Привет всем! давно я хотел написать статью про сервис google page speed, хотя я итак писал уже про ускорение и оптимизацию сайта и давал советы, которые помогут вам повысить показатель в google page speed. Но речь сегодня о другом, с недавних пор я перестал беспокоиться о своём показатели в сервисе google speed и пытаться его как то повысить. В своё время я увеличил показатель с 2% до 87% впечатляет не правда ли!? Но спустя некоторое время мне пришлось поменять шаблон моего wordpress сайта, после чего показатель упал до 63%, наверное шаблон оказался тяжелее предыдущего.

Так же в дальнейшем при установке одного плагина, который выводит на сайт адаптивную сетку анонсов записей, показатель ещё упал до 30%. То есть я так понял мне нужно было выбирать либо красивый сайт, либо высокий показатель в сервисе google speed. Причём я заметил, что показатель может быть не высоким 50-70% и это никак не влияет на скорость открытия сайта в браузере. При показателе 63% мой сайт работает без проблем, конечно если отказаться практически от всех плагинов и выбрать себе тему для сайта по легче, то можно повысить показатель до 90-100%. Но ради чего это делать? Ради цифры? Ради самомнения?

Google page speed считает каждый килобайт! если изображение на вашем сайте можно оптимизировать, то есть сжать ещё на пару килобайт, то google понизит показатель, до тех пор пока вы не уберёте эти пару килобайт. То есть всего из-за нескольких килобайт показатель может быть понижен, но при этом для сайта это не несёт абсолютно никаких изменений в плане скорости, всё по прежнему! Тогда зачем я буду загоняться из-за этих килобайт, пыхтеть там, время своё тратить? Опять же получается только ради цифр, ради того, что я всех лучше и круче, вот посмотрите какой у меня высокий показатель, это бред!

 

treadmill-536126_640_mini

 

Просто я хочу огорчить тех, кто якобы думает, что после того как они повысят себе показатель в сервисе google page speed, их сайт тут же чудесным образом станет популярным, посещаемым, их поисковые запросы вырастут и т.д.. Да вы что ребят, очнитесь! хватит часами зависать там, тратить своё время впустую, займитесь лучше своим сайтом, напишите что-нибудь полезное лучше. Я не удивлюсь что есть люди, которые ночами не спят из-за того, что у них низкий показатель в google speed. В общем эта гонка за высоким показателем может довести до абсурда…нет, играть в игры Google я больше не хочу, с меня хватит.

Я знаю как сделать высокий показатель, но мне это больше не интересно, мне интересно писать полезные записи на своём сайте. И менять свой шаблон ради высокого показателя я то же не собираюсь, на данный момент меня всё устраивает. На последок хочу показать скриншот с показателем в google page speed самого популярного и посещаемого сайта в России – Вконтакте, наверное там и не слышали о таком сервисе.

 

03-01-2016 13-08-10_mini

 

Мои рекомендации: если у вас проблемы с сайтом, он медленно загружается, проблемы с сервером, создаёт большую нагрузку, то возможно сервис google page speed может помочь вам выявить причины и помочь вам их устранить. Если проблем у вас нет с производительностью сайта, то вам не нужно знать об этом сервисе, он не нужен вам, повышение показателя ни чем вам не поможет, только отнимет время и спутает все карты.

Нужно понять, что сам по себе движок wordpress это тяжёлая система, много функций и прибамбасов, на что нужны ресурсы. Проблему с нагрузкой сервера может решить только увеличение лимитов хостинга, то есть переход на более высокий тариф или выделенный сервер. При достижении определённого показателя этот процесс неизбежен и здесь google page speed вам уже не поможет.

 

На этом у меня всё, жду ваших комментариев, до новых встреч!

 

Поделиться ссылкой:




info-effect.ru

Chrome User Experience Report

Как уже было сказано выше, это отчёт, содержащий набор метрик. В статье я рассмотрю основные из них, которые стоит учитывать при работе над улучшением скорости загрузки сайта, а именно:

  • First Paint и First Contentful Paint.
  • First Meaningful Paint (FMP) и Hero Element Timing.
  • Time to Interactive.
  • Long Tasks.

Эти метрики показывают этапы загрузки сайта (кроме Long Tasks). Нужны, чтобы лучше понимать, как загружается страница. Этапы выглядят так:

Как загружается сайт по этапам

Про остальные метрики вы можете прочитать на сайте Google – «Chrome User Experience Report». Учтите, что материал на английском.

Теперь перейдём к первому ключевому этапу загрузки страницы.

First Paint и First Contentful Paint

First Paint (FP) – это время до начала прорисовки и появления контента. Первый ключевой момент, на который следует обращать внимание.

First Contentful Paint (FCP) – показывает время, когда браузер начал отображать любой текст, изображения (включая фоновые). Это первые элементы, которые пользователь увидит на странице.

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

Для отслеживания FP / FCP понадобится аккаунт в Google Analytics. Используя данные Google Analytics, нужно добавить в код сайта следующее:

<head>  <!-- Add the async Google Analytics snippet first. -->  <script>  window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;  ga('create', 'UA-XXXXX-Y', 'auto');  ga('send', 'pageview');  </script>  <script async src='https://www.google-analytics.com/analytics.js'></script>    <!-- Register the PerformanceObserver to track paint timing. -->  <script>  const observer = new PerformanceObserver((list) => {  for (const entry of list.getEntries()) {  // `name` will be either 'first-paint' or 'first-contentful-paint'.  const metricName = entry.name;  const time = Math.round(entry.startTime + entry.duration);    ga('send', 'event', {  eventCategory: 'Performance Metrics',  eventAction: metricName,  eventValue: time,  nonInteraction: true,  });  }  });  observer.observe({entryTypes: ['paint']});  </script>    <!-- Include any stylesheets after creating the PerformanceObserver. -->  <link rel="stylesheet" href="...">  </head>  

Таким образом вы сможете отслеживать скорость загрузки FP и FCP.

Для оптимизации FP/FCP попробуйте уменьшить время до отображения первого контента, удалив из <head> документа любые скрипты или стили, которые могут препятствовать отображению. Выберите минимальный набор стилей <head>, чтобы пользователь видел, что сайт начал загружаться.

First Meaningful Paint (FMP) и Hero Element Timing

First Meaningful Paint (FMP) и Hero Element Timing – это время загрузки наиболее важной части страницы.

Элемент, который должен грузиться в первую очередь, ещё называют «hero element». Чтобы понимать, что на странице должно быть «hero element», ответьте себе на вопрос «Полезна ли эта часть?». Само понятие «полезности» весьма специфично, но определить элемент легко – это наиболее полезная пользователю область страницы. Она и должна грузиться в первую очередь. Пример таких областей:

Пример областей «hero element»

В YouTube основной «hero elements» – видео – будет наиболее важной частью страницы. В Twitter, вероятнее всего, это будут значки уведомлений и первый твит. В приложении для прогноза погоды – область с прогнозом погоды. На новостном сайте – вероятнее, область с основным сюжетом и картинкой анонса.

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

Отслеживать FMP и «hero elements» сложно, так как нет стандарта для определения FMP. Учитывая, что все страницы Вашего сайта могут быть разными, то и «hero elements» на них могут отличаться. Лучше всего смотреть в контексте одной страницы. Тогда FMP будет моментом, когда «hero elements» лучше всего видны на экране.

Как определить эту метрику, Google рекомендует прочесть в статье Стива Сандерса: «User Timing and Custom Metrics». Материал на английском, но если он Вас заинтересует, пишите в комментариях – мы сделаем перевод этой статьи.

Для оптимизации FMP выберите наиболее важные элементы страницы и убедитесь, что исходная загрузка скрипта содержит только тот код, который необходим для отображения «hero elements». Любой код, не связанный с вашим «hero elements», но содержащийся в исходном JavaScript, замедлит время загрузки. Не нужно принуждать пользователя ждать, а его устройство – анализировать код JavaScript, который ему сразу не нужен.

Time to Interactive

Time to Interactive (TTI) – время загрузки элементов взаимодействия, которые будут надёжно реагировать на действия пользователя.

Также очень важная метрика. Позволяет понять, как быстро пользователь сможет взаимодействовать с сайтом. Представьте, что вы вводите запрос в Google на телефоне, нажимаете «поиск», но ничего не происходит, а загрузка началась только после 6 нажатия на кнопку «поиск». Время, которое прошло, чтобы кнопка среагировала на нажатие, и будет TTI.

Отслеживать TTI нам снова поможет Google Analytics. В этот раз используем следующий код:

import ttiPolyfill from './path/to/tti-polyfill.js';    ttiPolyfill.getFirstConsistentlyInteractive().then((tti) => {  ga('send', 'event', {  eventCategory: 'Performance Metrics',  eventAction: 'TTI',  eventValue: tti,  nonInteraction: true,  });  });  

Подробная инструкция по его установке и использованию – «Time to Interactive Polyfill».

Оптимизация TTI похожа на оптимизацию FMP. Вам нужно выбрать приоритетный элемент страницы и убедиться, что в исходной загрузке скрипта нет ничего лишнего, он содержит только тот код, который нужен, чтобы загружаемые элементы становились интерактивными. Любой другой код будет замедлять скорость загрузки элементов взаимодействия.

Long Tasks

Long Tasks – это задачи (скрипты), на выполнение которых уходит более 50 миллисекунд. Исходя из рекомендаций RAIL, они воспринимаются как долгие.

Нужно стараться упрощать Long Tasks. Так как скрипты грузятся поочерёдно, в случаях, когда выполнение одного скрипта занимает много времени, он блокирует загрузку других скриптов в очереди. Пользователь может принять это за лаг, что портит впечатление о сайте.

Пример Long Tasks

Для отслеживания Long Tasks нужно создать новый PerformanceObserver:

const observer = new PerformanceObserver((list) => {  for (const entry of list.getEntries()) {  ga('send', 'event', {  eventCategory: 'Performance Metrics',  eventAction: 'longtask',  eventValue: Math.round(entry.startTime + entry.duration),  eventLabel: JSON.stringify(entry.attribution),  });  }  });    observer.observe({entryTypes: ['longtask']});  

Чтобы сократить Long Tasks, нужно разделить большой скрипт на несколько маленьких и определить, какой скрипт должен загружаться в первую очередь. Таким образом, вы не только сократите Long Tasks, но и ускорите загрузку интерактивных элементов страниц.

Рекомендую к ознакомлению руководство на английском языке: «User-centric Performance Metrics».

Также есть видео на английском:

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

Сервис Google Developers PageSpeed Insights

Google Developers PageSpeed Insights

Сервис PageSpeed Insights довольно популярный у SEO-специалистов и веб-мастеров. Я уже писал о нём в статье: «Как провести анализ сайтов конкурентов? 7 видов анализа». С момента её написания прошло немного больше месяца, но сервис решили обновить перед выходом «Speed Update». Несколько недель назад в него добавили новый отчёт, который показывает общие данные о скорости загрузки всех страниц.

Для получения данных в поле ввода нужно ввести следующую конструкцию:

origin:https://www.site.ru/

Рассмотрим на примере сайта группы «Metallica»: https://www.metallica.com/.

Скриншот обычной проверки в Google PageSpeed Insights сайта https://www.metallica.com/

Так выглядит обычный отчёт после проверки сайта в PageSpeed Insights.

Теперь используем новую конструкцию:

Скриншот проверки в Google PageSpeed Insights конструкции origin:https://www.metallica.com/

На втором скриншоте мы видим сводный отчёт. Кроме того, в обоих отчётах данные о событиях первой отрисовки контента – это метрика FCP.

Несмотря на то, что Google рекомендует этот сервис для оценки производительности страниц, стоить помнить, что PageSpeed Insights показывает базовую информацию вроде: «Оптимизировать изображения» или «Использовать кеш браузера». Для более детального отчёта лучше использовать сервис Lighthouse.

Lighthouse

Lighthouse

Lighthouse – это автоматизированный сервис с открытым исходным кодом, который используется для проверки и анализа страниц. Рассмотрим, как его использовать.

Этот сервис, как и PageSpeed Insights, показывает информацию о загрузке страницы, но использует для своих отчётов большее метрик.

Для его использования потребуется браузер Chrome и плагин Lighthouse. После установки плагина открываем интересующий сайт, нажимаем на иконку маяка около адресной строки и на Generate report.

Запускаем Lighthouse

Так как проверяется больше метрик, анализ займёт больше времени, чем в случае с PageSpeed Insights.

Отчет проверки сайта https://www.metallica.com/ сервисом Lighthouse

В результате получаем несколько отчётов:

  • Performance.
  • Progressive Web App.
  • Accessibility.
  • Best Practices.
  • SEO.

Каждый из этих отчётов содержит информацию о том, что на сайте сделано хорошо, а что нужно исправить.

Например, отчёт о производительности (Performance) содержит данные об интересующих нас метриках: FCP, TTI, FMP.

Отчет проверки сайта https://www.metallica.com/ сервисом Lighthouse с метриками FCP, TTI, FMP

Основным минусом этого сервиса может быть английский язык – все отчёты на английском. Он бесплатный, так что рекомендую как минимум попробовать.

Если хотите испытать сервис без установки, можно протестировать онлайн-версию на сайте WebPagetest.

Запуск Lighthouse Audit на сайте http://www.webpagetest.org/

Отчёт в нём выглядит так:

Отчёт Lighthouse Audit в http://www.webpagetest.org/

Мне удобнее проводить анализ через плагин, не нужно ждать очереди на проверку в WebPagetest.

И ещё один сервис анализа Google, но уже от меня.

Compare your mobile site speed

Сервис Compare your mobile site speed позволяет сделать сравнение скорости загрузки нескольких мобильных версий сайтов (ограничение в 10 доменов). Вот так это выглядит на практике:

Результат сравнения скорости загрузки Big Four через Compare your mobile site speed

Сервис позволяет указать регион и тип сети: 3G или 4G. Подойдёт для быстрого базового анализа вашего сайта и сайтов конкурентов.

siteclinic.ru

Проверяем скорость загрузки сайта в Google Page Speed

На ваш личный взгляд ваш сайт может летать, но это еще ни о чем не говорит для Гугла.

У него свои критерии проверки скорости сайта, поэтому идем сюда https://developers.google.com/speed/pagespeed/insights/

Вводим адрес сайта и жмем проверить.

Адрес вводите с http или https и при этом убедитесь, что сайт включен в нормальном режиме (не в режиме обслуживания), а robots.txt разрешает индексацию всех важных элементов сайта.

скорость сайта google page speed

Чем ближе результат к 100 баллам тем лучше :cool:

Нормой считается 80 баллов и выше.
Если у вас больше — отлично.
То есть если ваш результат 90 баллов, то дергаться и пытаться любыми способами сделать 100 — не слишком благодарное занятие.

Так что если у вас 80 баллов и выше, то не переживайте, а радуйтесь: большинство проектов имеет 40-50 баллов до оптимизации скорости загрузки.

Я лично считаю, что для проектов с большим функционалом даже 70 баллов по Google Page Speed — вполне приемлемо.

Ну а если у вас меньше 70 баллов, а тем более 20-30, то стоит серьезно задуматься об оптимизации скорости сайта под Гугл.

Я начну с самых простых способов и закончу сложными, которые подойдут для самых дотошных владельцев сайтов, которым нужно 100 из 100 :smile:

Включить сжатие

Самый простой способ ускорения загрузки сайта для Гугла — это включить GZIP сжатие. Это специальный механизм архивирования данных «на лету», который поддерживается 99,99% хостеров.

Если ваш хостер не поддерживает его, то меняйте хостера (кого могу рекомендовать).

Включить GZIP сжатие в WordPress можно с помощью плагина кэширования WP Fastest Cache.
В Opencart с помощью плагина NitroPack

Если не хотите ставить плагины, то можете модифицировать данные прямо в файле .htaccess, который лежит в корневой папке сайта (как попасть туда по FTP).

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

Проверить GZIP сжатие можно тут https://checkgzipcompression.com/

Должно быть так:

сжатие gzip включено в google page speed

Сократите время ответа сервера

Зависит от серверов вашего хостера, их загруженности и прожорливости вашего проекта.

Иногда только один этот показатель может свести на нет все ваши усилия по SEO оптимизации проекта.

скорость сайта в гугл

Важно проверить этот параметр скорости сайта по Google Page Speed в разное время дня или ночи — вполне возможно в данный момент сервер хостера просто перегружен запросами.

Если в другие часы будет все в основном хорошо, то на эпизодическую разовую загруженность можно до поры до времени не обращать внимания.

Если этот показатель стабильно плохой, то имеет смысл:

  • поставить модули кэширования (я их рекомендую ставить каждому проекту в любом случае!), чтобы снизить нагрузку на слабый хостинг и время формирования страниц сайта.
  • задуматься о смене хостера на того, у которого максимально быстрый хостинг или просто переходите на VPS-сервер. Этого обычно хватает в большинстве случаев для развивающихся проектов.
  • если есть лишняя копеечка, то закажите услугу CDN сервера вот тут (скидка 20% по промокоду «moytop»). Это даст весьма стабильную и быструю работу сайта.
  • самый сложный путь — это внутренняя оптимизация скриптов сайта (вплоть до полной переделке всего сайта). Это рекомендую делать в последнюю очередь, так как очень непросто и нормального специалиста за вменяемые деньги найти почти невозможно.

Используйте кеш браузера

Тоже несложный способ быстро повысить показатель в Google Page Speed.

Также как и в случае с GZIP сжатием решается через добавление кода в htaccess. Вы можете добавить его вручную или с помощью все тех же плагинов кэширования.

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

А лучше пользуйтесь проверенными плагинами, которые я уже предлагал выше.

Оптимизируйте изображения

Самый выгодный способ оптимизации, который легко может сделать каждый своими руками.

Задача — уменьшить качество картинок на сайте, чтобы они занимали меньше места и быстрее грузились.

Сделать это разумнее всего через сам Гугл Пейдж Спид.
Но придется делать это вручную, то есть придется повозиться!

Я больше года ищу нормальную программу, которая может автоматически ужимать по алгоритму Гугла картинки и сохранять структуру папок.

Увы, такой программы я не нашел. Пересмотрел всякие просмотрщики типа XnView, Infran, программы типа Caesium, FileOptimizer, Imbatch, ImageOptim, сервисы вроде TinyPng и т.п. — автоматизации нет.

Если кто знает такую программу — напишите в комментах.

Основные требования:

  • сжатие по алгоритму Google (чтобы после загрузки готовых картинок они соответствовали требованиям Гугла по скорости загрузки)
  • минимальные потери качества
  • работа с сохранением структуры папок
  • удаление метаданных и т.п. мусора.
  • автоматическое определение входного и выходного формата

Ну а пока программы нет, то придется делать это «ручками».

Сам Google Page Speed внизу дает ссылку на скачивание уже оптимизированных файлов.

скорость загрузки google page speed

Качаем и распаковываем.

А затем долго и муторно меняем файлы через FTP на сайте, заменяя старую версию на новую.

Увы, но качество картинок JPG теряется значительно.
PNG — качество остается весьма хорошее, почти как в оригинале, а размер уменьшается в 2-3 раза. Так что если у вас много PNG файлов, то будет очень большая экономия.

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

Обновление!
Выход есть для сайтов на WordPress — читайте про формат Webp как его использовать на сайте в пару кликов и получить высокую скорость по картинкам.

Сократите CSS + HTML + JS

В данном случае Google Page Speed по аналогии с картинками просит вас выкинуть из файлов верстки, скриптов и кода страниц все лишнее — пробелы, комментарии и т.п.

Чтобы сами файл стали меньше «весить» и быстрее стала скорость загрузки сайта.

При использовании плагинов кэширования — это всё делается автоматически «на лету». Это наиболее удобный способ, так как не меняет ваш код, а создаёт отдельные — минифицированные файлы CSS и HTML, которые и подсовывает Гуглу и все счастливы.

Если минифицировать файлы в каком-то сервисе, то имейте ввиду, что потом какие-то изменения в таких урезанных файлах будет сделать проблематично.

Скачать уменьшенные файлы «от Гугла» можно там же где и картинки — они в одном архиве будут.

А вот перезаливать ими оригинальные файлы — сами решайте, в любом случае сохраните бекап старых файлов.

Оптимизируйте загрузку видимого контента

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

Поэтому я бы постарался тут особенно не заморачиваться и заняться другими факторами скорости сайта в Гугл.

Удалите код JavaScript и CSS

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

Сложный пункт, который требует знаний и практики.

Вы, конечно, можете добавить возле загрузки каждого JS файла тег async или же поставить скрипт от Гугл для extsrc=, но по моим наблюдениям в 90% это или ничего не дает, или ломает сайт!

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

А так как в том же WordPress обычно 9 из 10 скриптов — это внешние плагины, то там вы вряд ли что-то сделаете, так как они грузятся из своих папок и обновляются по 3 раза на неделю.

И ваши сделанные изменения банально затрутся.

Так что тут я могу рекомендовать:

  1. не тратить время на самостоятельный разбор этого хлама и сразу нанять специалиста на бирже фриланса, дешевле всего на Kwork , ну а если проект посложнее, то на других биржах можете поискать.
  2. по возможности просто отключить/удалить уже ненужные или неиспользуемые плагины. Например в своем блоге, когда я писал эту статью, то обнаружил в скриптах плагин, которым не пользуюсь уже несколько лет, просто забыл про него — а он висит и снижает скорость загрузки сайта в Гугл.

Посмотрите, может и вы что-то забыли? Или чем-то не пользуетесь? Тогда отключайте.

Код для htaccess

Как и обещал, вот код, который формируется плагинами кэширования, но который можно добавить самому в файл .htaccess, который находится в корне сайта.

Какой-то из этих двух вариантов наверняка подойдет.

На всякий случай оставляю файл с кодом в формате txt, чтобы символы не затерлись, а то мало ли что может быть.

Нужно взять один из кодов и добавить в самое начало вашего файла .htaccess.

Обновить страницу и отправить на повторную проверку скорости загрузки сайта Google Page Speed.

moytop.com


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Adblock
detector