Google PageSpeed ​​Insights доставляет вам проблемы? Узнайте, как их удалить

1. Органическое Позиционирование имеет только глаза на PageSpeed ​​Insights
2. Как работает анализ производительности PageSpeed ​​Insights?
3. 10 правил анализа производительности с первого взгляда
4. Google PageSpeed ​​Insights: разрешение правил производительности
5. Удалить блокировщики JavaScript и CSS из рендеринга
6. Укажите кеш браузера
7. Избегайте перенаправлений на целевые страницы
8. Включить сжатие
9. Сократить HTML, CSS и JavaScript
10. Оптимизировать изображения
11. Приоритет видимого контента
12. Сократить время отклика сервера
13. выводы

Среднее время чтения: 15 минут (4700 слов).
Если у вас нет времени сейчас, вы можете перейти прямо к выводы статьи ,

Лучший хостинг WordPress со скидкой 20%!

Органическое Позиционирование имеет только глаза на PageSpeed ​​Insights

Глаза широко открыты с PageSpeed, чтобы улучшить ваш SEO

Одна из самых разочаровывающих областей технического SEO - это Отчеты Google PageSpeed ​​Insights , По двум причинам: (1) с одной стороны, он только идентифицирует проблемы, с которыми столкнулся, но часто без четкого решения, рекомендации или руководства о том, как его найти и решить; и (2) потому что это имеет решающее значение для органического позиционирования каждой конкретной веб-страницы и веб-сайта в целом.

PageSpeed ​​Insights не уникален. У нас есть много других диагностических инструментов (таких как Pingdom , GTmetrix или WebPagetest ) которые даже предлагают лучшие и более полные метрики для оценки эффективности наших веб-страниц. Однако их оценки не так важны: в настоящий момент наш веб-сайт может получить отличную оценку по всем этим инструментам, но Google будет обращать внимание только на анализ своего инструмента .

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

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

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

Как работает анализ производительности PageSpeed ​​Insights?

Машины PageSpeed ​​Insights в полном разгаре

В этой статье мы сосредоточимся на анализе, который проводит PageSpeed ​​Insights для измерения производительности веб-сайта , общего для мобильных сред и настольных компьютеров.

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

Анализ PageSpeed ​​Insights основан на проверке и соблюдении в общей сложности десяти правил . Чтобы измерить степень соответствия этим правилам, в отчете PageSpeed ​​используется цветовой код, подобный семафорам:

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

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

И, наконец, обратите внимание на важный аспект при оценке эффективности нашего веб-сайта: различные исполнения инструмента анализа могут (на самом деле, как правило) давать разные оценки в диапазоне до 6-8 баллов.

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

10 правил анализа производительности с первого взгляда

Изображение, которое мы всегда хотели бы получить с помощью PageSpeed ​​Insights, будет следующим:

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

• Удалить JavaScript и блокировать CSS . Наиболее важной частью веб-страницы является ее верхняя часть («над сгибом»), которая появляется на экране, как только страница загружается и первое, что видит пользователь. Поэтому крайне важно, чтобы браузер показал это как можно скорее, и нет ресурса, который задерживал бы его визуализацию.
• Укажите кеш браузера . Как правило, веб-страница меняется не очень часто, поэтому повторный доступ пользователя к одной и той же странице будет загружать одни и те же ресурсы снова и снова. Благодаря кешу браузер сохраняет копии этих ресурсов, поэтому их не нужно загружать постоянно.
• Избегайте перенаправлений на целевые страницы . Перенаправление преобразует один веб-адрес в другой, что может увеличить время соединения с сервером и начать загрузку страницы.
• Включить сжатие . Современные серверы и браузеры поддерживают и распознают понимание gzip, что может значительно уменьшить размер ресурсов и, следовательно, время загрузки веб-страницы.
• Минимизировать CSS . Обычно таблицы стилей CSS организованы так, чтобы облегчить чтение людьми: кровотечение, пустые строки, комментарии и т. Д. Однако вся эта дополнительная информация и структура ничего не вносят в стили веб-страницы, хотя и увеличивают размер файла, а также время его загрузки и обработки браузером.
• Сократить HTML По той же причине, что и листы CSS, файлы HTML обычно содержат дополнительную информацию, облегчающую чтение людьми, но не нужную для их интерпретации и визуализации браузерами.
• Сократите JavaScript . То же самое, что и для листов CSS и HTML-кодов, но относится к файлам JavaScript, используемым на веб-странице.
• Оптимизировать изображения Безусловно, изображения являются ресурсом, который потребляет больше пропускной способности и больше времени загрузки. Мы должны убедиться, что размеры и размеры изображений настолько малы, насколько это возможно, без ущерба для их качества при окончательной визуализации.
• Приоритеты видимого контента . Он заключается в том, что вся или большая часть информации, отображаемой в верхней видимой части страницы («выше сгиба»), доступна как можно скорее, чтобы ее можно было просматривать в браузере, хотя остальная часть страницы продолжай заряжаться.
• Уменьшите время отклика сервера . Фактор меньшего контроля, который мы можем иметь, измеряет, как долго хост-сервер отвечает на запросы веб-страницы или другого ресурса из браузера.

С 20% СКИДКОЙ!

Google PageSpeed ​​Insights: разрешение правил производительности

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

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

Удалить блокировщики JavaScript и CSS из рендеринга

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

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

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

Стили CSS определяют, как будут отображаться элементы страницы (например, цвета, шрифты, структура страницы, элементы порядка и т. Д.), А код JavaScript может влиять на то, как и что будет отображаться.

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

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

• Как сайт разработан при использовании JavaScript-кодов и стилей CSS (т.е. в зависимости от используемой темы).
• Установленные плагины или надстройки, поскольку они могут добавлять коды JavaScript или стили CSS в дизайн веб-страниц.

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

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

Для веб-сайтов WordPress возможным решением было бы использование плагина, объединяющего файлы JavaScript и листы CSS (например, Autoptimize ), так что из нескольких блокирующих файлов мы перейдем только к одному.

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

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

Укажите кеш браузера

Кэш для хранения веб-ресурсов

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

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

Это время можно настроить на хост-сервере, изменив системный файл с именем «.htaccess» . Обычно хостинг-провайдеры разрешают доступ к этому файлу и изменяют его, поэтому мы можем сделать это сами (и, если это не разрешено, обратиться в их службу технической поддержки).

ОЧЕНЬ ОСТОРОЖНО !!! Ошибка в этом файле может заблокировать или сбить веб-сайт, поэтому у нас всегда есть резервная копия на случай, если мы сделаем ошибку и сможем быстро ее восстановить.

Чтобы установить минимальное время кэширования браузера на неделю , просто добавьте следующие строки в «.htaccess» (убедитесь, что вы скопировали его в точности так, как оно есть):

<IfModule mod_expires.c> ExpiresActive On ExpiresDefault "доступ плюс 1 неделя" </ IfModule>

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

<IfModule mod_expires.c> ExpiresActive On ExpiresByType image / jpg "доступ 1 год" ExpiresByType image / jpeg "доступ 1 год" ExpiresByType image / gif "доступ 1 год" ExpiresByType image / png "доступ 1 год" ExpiresByType image / x-icon «Доступ 1 год» ExpiresByType text / css «Доступ 1 месяц» ExpiresByType text / x-javascript »Доступ 1 месяц« ExpiresDefault »Доступ плюс 1 неделя» </ IfModule>

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

В дополнение к времени кэширования сервер также может информировать браузер о последней модификации ресурса . Таким образом, даже если ресурс истек в кеше, браузер может проверить, был ли он изменен на сервере и, если нет, его не нужно загружать снова. Для этого просто добавьте следующую строку в «.htaccess»:

FileETag MTime Размер

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

Это происходит, например, с файлом «analytics.js», необходимым для возможности использовать статистические отчеты Google Analytics, у которых время кеширования на исходном сервере составляет всего два часа. С помощью небольшой «хитрости», здесь вы можете увидеть, как мне удалось преодолеть ограничение по времени кеш браузера скрипта analytics.js ,

Избегайте перенаправлений на целевые страницы

При перенаправлении вы загружаете другую страницу

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

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

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

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

Большинство современных серверов и браузеров поддерживают тип сжатия данных в формате «gzip» или, в противном случае, «дефлятирование», так что вся связь между ними (HTML, JavaScript, CSS, изображения, файлы и т. Д.) .) делается со сжатыми данными в одном из этих форматов.

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

На серверах Apache настроить сервер для этого так же просто, как скопировать следующий фрагмент кода для формата GZIP:

<IfModule mod_gzip.c> mod_gzip_on Да mod_gzip_dechunk Да файл mod_gzip_item_include. (Html? | Txt | css | js | php | pl) $ mod_gzip_item_include обработчик ^ cgi-скрипт . * mod_gzip_item_exclude mime ^ image /.* mod_gzip_item_exclude rspheader ^ Кодировка содержимого:. * gzip. * </ IfModule>

Или следующий фрагмент кода для формата DEFLATE:

<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE текст / текстовый текст / html текст / обычный текст / xml текст / текст css / приложение javascript / приложение javascript / приложение x-javascript / приложение xml / xhtml + приложение xml / приложение rss + xml / x -httpd-php application / x-httpd-fastphp image / svg + xml </ IfModule>

Обратите внимание, что в обоих случаях вы должны указать, какой тип ресурсов будет сжат в номенклатуре " MIME ». Я поставил наиболее обычную конфигурацию, но если вы хотите включить другие ресурсы, вы можете проверить свой тип MIME в Руководство по серверу Apache ,

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

Сократить HTML, CSS и JavaScript

Файлы ресурсов, которые мы можем минимизировать

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

Веб-страницы генерируются из кода файлов трех типов: файлы с кодом HTML, файлы с кодом JavaScript и таблицы стилей CSS. Эти три файла определяют, какой контент отображается и как , текстовый или графический, включая изображения.

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

• Включает в себя комментарии, чтобы объяснить, дифференцировать или отделить части кода.
• Он имеет отступы и пробелы, чтобы структурировать его в соответствии с его функциональностью.
• Включите один или несколько разрывов строк, чтобы отделить инструкции друг от друга.

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

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

У нас есть три способа минимизации этих файлов:

1. Используя минимизированные файлы, предоставленные PageSpeed , копируйте их на наш сервер вместо нашего. Этот параметр обычно действителен для файлов JavaScript и стилей CSS, но не для HTML-кода, сгенерированного менеджером контента.
2. Используя себя инструмент минимизации с каждым файлом, повторяя его, когда мы изменяем один из них.
3. Использование плагина или надстройки, которая делает это автоматически при загрузке одного из файлов кода. Лично я предпочитаю этот вариант.

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

Оптимизировать изображения

Удивительный результат, насколько это правило нарушено. Не только из-за простоты и скорости, с которой это может быть решено, но также и потому, что сама PageSpeed ​​Insights предоставляет файл с оптимизированными изображениями, поэтому в конце концов, единственное, что нам нужно сделать, это загрузить его и поместить эти изображения на наш сервер. (хотя это не было бы идеальным решением).

Идеальное решение будет включать следующие шаги:

1. Отрегулируйте размеры изображений в соответствии с размерами места, где они будут отображаться. То есть какое изображение и место имеют одинаковую ширину и высоту. Любое изображение, которое больше, чем его место просмотра, будет пустой тратой для загрузки.
2. Сжатие изображений с низкой потерей качества («сжатие с потерями») вместо потери качества («сжатие без потерь»). Большинство пользователей вряд ли оценят разницу между ними, но размер файла заметно уменьшится.
3. Если вам нужно предоставить изображения высокого качества (например, профессиональные сайты с фотографиями), используйте сжатые изображения для карусели или сэмплера фотографий со ссылкой для загрузки каждой фотографии в высоком качестве.

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

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

Приоритет видимого контента

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

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

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

Но в дополнение к удалению JavaScript и блокированию CSS, мы должны организовать контент сайта следующим образом:

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

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

В этом случае решение будет состоять в том, чтобы извлечь код CSS, используемый содержимым сверху, и ввести его непосредственно внутри («CSS ​​inline») страницы. Есть плагины ( Autoptimize что мы обсуждали) и инструменты это может помочь идентифицировать и извлечь CSS из верхней части страницы, но я рекомендую его только тем, кто обладает достаточными знаниями CSS, поскольку могут возникать конфликты и зависимости, которые должны решаться по одному.

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

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

Быстрый хостинг-сервер для вашего сайта

Это правило определяет, сколько времени требуется нашему хост-серверу для ответа на запрос. Google устанавливает в качестве подходящего значения время отклика менее 200 миллисекунд (2 десятых секунды, время, за которое Усэйн Болт проходит 2 метра 😉).

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

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

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

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

В случае WebEmpresa, вы должны указать код "coupon20", чтобы принять вашу скидку:

выводы

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

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

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

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

С учетом этих соображений наша стратегия оптимизации производительности веб-сайта будет включать следующие шаги:

1. Наймите надежный , качественный хостинг-сервер и быструю и эффективную техническую поддержку. То есть, нет бесплатного жилья или смехотворно низких цен.
2. Создайте веб-сайт или выберите тему WordPress, которая правильно расставляет приоритеты в видимом контенте, удаляет JavaScript и блокирует CSS . Так как решить его задним числом с уже созданным веб-сайтом, это может быть очень сложно или нежизнеспособно.
3. Сократите количество плагинов или надстроек в менеджере контента, поскольку они, как правило, включают файлы JavaScript и стили CSS, которые могут вызывать инциденты в связанных правилах.
4. Обязательно соблюдайте правила, которые не требуют дополнительных технических знаний , и включайте их в нашу хорошую практику обслуживания веб-сайтов.

Проблемы отчета Google PageSpeed ​​Insights иногда требуют анализа и выполнения множества тестов, пока они не будут решены. Какой стратегии вы придерживаетесь, чтобы решить их? Используете ли вы какой-либо другой диагностический инструмент для выявления причин проблем? Что?

изображения: Freepik , IconFinder , собственная разработка.

Был ли пост полезным? Помоги мне улучшить и забить это!

[Пока вы проголосовали 20, со средним баллом 4,5]

Другие SEO сообщения о кольцах, которые могут вас заинтересовать

Похожие

Комментарии