Loading
828b9d9da2aa

Оптимизация сайта — рекомендации сервиса Google PageSpeed Insights

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

Сокращение время ответа сервера
Хорошее время отклика сервера по рекомендации google — значение ниже 200ms.
Сжатие графики
jpegoptim — оптимизатор JPEG/jFIF файлов.
optipng — оптимизатор PNG. Эта программа также преобразует другие форматы (BMP, GIF, PNM и TIFF) в оптимизированный PNG, и выполняет проверку целостности и исправлений.
gifsicle — работает с изображениями GIF
Установка:

Пример: оптимизировать графику в соответствующем каталоге можно так:

Кадрирование изображения из командной строки:

Механизмы кеширования
Если у вас на странице 10 файлов изображения, 5 js файлов и пара стилей css, то при обращении к странице каждый раз будет генерироваться 17 дополнительных GET запросов. Это плохо. Часть этих файлов браузер вполне может кэшировать и брать из локального кэша.
Кроме того совершенно не обязательно нагружать этими запросами Apache — тут поможет nginx работающий в качестве кеширующего сервера.
Определимся сразу, что подразумевают под механизмами кеширования? Оно возможно на нескольких уровнях.
Предположим, в коде CMS мы формируем страницу используя php. Как мы можем ускорить процесс выполнения кода и загрузки страницы?
За ускорение процесса выполнения php кода отвечают различные php акселераторы. Далее готовая страница может уходить к пользователю в браузер. И вот тут появляется возможность собственно кеширования.
Во-первых кешировать можно средствами CMS — например взять сформированную страницу, поместить в кеш и при следующем запросе пользователя отдавать готовую страницу из кеша, не обращаясь к движку. Однако разрабатывая подобный механизм в CMS следует учитывать что с точки зрения владельца сайта, содержимое может меняться даже при 2-х абсолютно одинаковых запросах — например на странице может каждый раз при обращении выводиться новый рекламный модуль )))) Это в первую очередь относится к кешированию средствами Joomla и WP.
Во-вторых кешировать данные можно на уровене прокси сервера — эта возможность предполагает что часть контента, получаемая клиентом при каждом обращении к странице — не меняется, и этот контент можно отдавать пользователю напрямую, не обращаясь к Apache — это например кеширование на уровене nginx, если он установлен у вас как кеширующий сервер. Таким образом можно кешировать различную графику, ява-скрипты и файлы CSS
В-третьих кеширование может срабатываеть на стороне пользователя — браузер может брать часть контента из локального кеша, например ту же графику или CSS файлы.
Прежде всего рассмотрим второй и третий случаи. Каким образом мы можем влиять на кеширование средствами прокси и на локальный кеш клиента?

Путь первый
Установка HTTP заголовков Expires с указанием даты.
При этом по истечении установленной даты кеш будет считаться устаревшим, время должно быть указано по Гринвичу (GMT)
Для эффективного исопльзования следует учесть, что время между кешем и сервером должно быть синхронизировано.
Формат использования:

При запросе это значение передаётся клиентом в специальном заголовке запроса: If-Modified-Since. Обработчик запроса может проверить, изменился ли объект, и если нет — вернуть ответ с пустым телом и кодом ответа 304 Not Modified. Само содержимое страницы не передаётся, и браузер будет использовать то содержимое, которое хранится у него в локальном кэше. На многих хостингах обработчиком выступает nginx, т.е. если при первом запросе браузера вы устанавливаете If-Modified-Since то при последующих запросах браузер отправит этот заголовок на сервер, nginx его обработает, убедится что файл не модифицирован и вернет код 304 который который указывает браузеру что файл не менялся и его можно брать из локального кеша. Директивы Cache-Control позволяют задать параметры кеширования еще более гибко, например определять для каких файлов браузеру вообще не нужно обращаться к серверу и их можно брать сразу из локального кеша.
Возможно сделать страницу всегда обновленной прописав в коде:

Или в случае Wirdpress:

Путь второй
Спецификация HTTP/1.1 также предусматривает заголовки ответа Cache-Control.
Значение Cache-Control может принимать значения — полный список смотрите по ссылке:
public помечает запросы, как разрешенные для кеширования как прокси так и локальным клиентом
private позволяет кэшу пользователя хранить ответ, общему кэшу (т.е. прокси) — нет.
no-store указывает кэшу не сохранять копию контента, ни при каких условиях.
no-cache вынуждает кэш отправлять запрос на исходный сервер каждый раз для валидации
must-revalidate сообщает кэшу, что он должен подчиниться любой свежей информации, что вы ему предоставляете о контенте.
max-age=[секунды] описывает максимальный период времени, в течение которого контент остается свежим.
Пример:

Когда присутствуют обе директивы Cache-Control, и Expires — больший приоритет имеет Cache-Control.

Как включить кеш контроль для nginx и apache?
Для Apache: (должны быть установлены соответствующие модули)
Примеры директив для использования в файле .htaccess:

Пример настройки nginx:
Замечание: nginx не обрабатывает файлы htaccess, параметры ниже можно задавать, если вы имеете доступ к конфигу nginx.

Ссылки на тему обработки nginx статического контента:
htaccess to nginx converter
Модуль mod_aclr2 для apache2

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

В ряде случаев некоторые модули используют кеш, даже если он выключен в глобальной конфигурации. Менеджер модулей — Свойства модуля — Дополнительные параметры — Кеширование. В частности так делают некоторые модули virtuemart. В общем случае, если вы хотите использовать встроенное кеширование Joomla, его достаточно включить в глобальной конфигурации — Общие настройки — Система — Настройки Кэша.
Оптимизации CSS и Ява-Скрипт
Для оптимизации CSS и Ява-Скрипт в движках Joomla и WordPress есть соответствующие плагины, работающие по одному принципу — они собирают в кучу все используемые движком css и js файлы, сжимают их и на выходе выдают всего 2 файла, соответственно js и css.
jFinalizer — плагин оптимизации Joomla
Использование:
Установить. Зайти в менеджере плагинов в его настройки. Поставить в списке плагинов первым.
В ряде случаев плагины и шаблон выводят css и js прямо в шаблоне, а не так, как это предусмотрено разработчиками Joomla
Правильный путь добавления этих файлов в шаблон следующий:

Замечу, что плагин оптимизации не сожмет код, добавленные с помощью функции addCustomTag
Также некоторые плагины добавляют скриты и стили в виде «name.css?ver=xxxx» — они тоже не будут сжаты. Придется лезть в код соответствующего плагин и убирать строки вида «?ver=xxxx»
JCH Optimize — еще один плагин оптимизации для Joomla.
Autoptimize — плагин WordPress для сжатия ява-скрипт и css.
Работа с файлами скриптов и стилей в WordPress:
Регистрация скриптов и стилей (обычно в файле functions.php темы)

Добавление скриптов и стилей (обычно в файле functions.php темы)

В файле functions.php вашей темы можно прописать перенос js скриптов в футер:

Вывод на страницы сайта происходит соответственно при вызове wp_head () или wp_footer ().
Подробнее о функция WordPress — codex.wordpress.org
Отдельно следует сказать о возможности асинхронной загрузки ява-скрипт.
Обычная загрузка:

Асинхронная загрузка:

или

Отличия атрибуты async и defer
Скрипт с атрибутом async выполнится при первой же возможности после его полной загрузки, но до загрузки объекта window.
Скрипт с атрибутом defer не нарушит порядок своего выполнения по отношению к остальным скриптам и его выполнение произойдет после полной загрузки и парсинга страницы, но до события DOMContentLoaded объекта document.
Механизм работает не во всех браузерах, также не будет работать, если в файле script.js есть строки document.write.
Альтернатива — подключение скрипта с использованием скрипта для асинхронной загрузки от гугл.

Механизм также не работает если в файле script.js есть строки document.write.

Что еще можно сделать для оптимизации производительности?
1. Использовать плагины собирающие все css в один файл. Аналогично для js.
Зачем это надо?
Для сокращения количества GET запросов к серверу.
2. Перемещение js файлов из хеадера в футер.
Зачем это надо?
Когда вы обращаетесь к страничке, браузер прежде всего получает html контент который генерируется движком. Далее браузер парсит страницу и видит что для корректного отображения надо получить допустим файл gif или css или js…Он отправляет асинхронные GET запросы для получения этих файлов. Соответственно по мере загрузки элементов страницы, браузер отображает ее на экране. Если у вас в хеаде прописан js то перед тем как отображать страницу дальше, браузер дождется завершения загрузки этого файла и при необходимости выполнит код js. Если он не нужны для отображения самой страницы, например в нем различные функции обрабатывающие события от мышки, то имеет смысл убрать загрузку данного файла в футер. Естстсвенно, надо понимать, что если пользователь начнет кликать мышкой в тот момент, когда часть сайта уже загрузилась, а файл с функциями js еще не получен то события обработаны не будут )))
Online сервисы
CSS компрессор: cssdrive.com/index.php/main/csscompressor
Сжатие графики: diggitize.me/imageoptimize
Проверка HTTP заголовков: msurf.ru/tools/headersviewl
Проверка компрессии: heckgzipcompression.com
Проверка кеширования: highloadtools.com/cachecontrol
Проверка текста на уникальность: content-watch.ru/website/
Оценка SEO параметров: pr-cy.ru
Позиция сайта в поисковиках: seolib.ru
Сеочеклист: seochecklist.ru

Дополнительно:
Не помешает установить обработку ошибки 404.
Если вы используете стандартный .htaccess для Joomla и WordPress — там обычно прописано что все обращения передавать на обработку файлу index.php Если вы видите в браузере страницу сгенерированную Apache или nginx — значит в .htaccess у вас это не прописано.
Как реагируют джижки на запрос несуществующей страницы?
В Joomla для этой цели можно использовать Joomla плагин Qlue 404.
В WordPress выводится содержимое файла 404.php в каталоге текущей темы.
В случае c WordPress его стандартного файла .htaccess достаточно
Для Joomla в случае использования плагина Qlue 404 прописывается:

Если вы его не используете — замените /index.php?qlue404=1 на URL страницы, которую хотите использовать при выводе ошибки 404

Источник

0

Автор публикации

не в сети 1 день

admin

36

создание сайтов, seo, smm

Комментарии: 50Публикации: 486Регистрация: 06-11-2011

Отправить ответ

Оставьте первый комментарий!

Войти с помощью: 
  Subscribe  
Notify of
Авторизация
*
*
Войти с помощью: 
Регистрация
*
*
*
Войти с помощью: 
Генерация пароля