Этапы Оптимизации И Развития Клиента

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

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

Эта статья о том, как создавать быстрые веб-сайты.



Этапы оптимизации и развития клиента



Как оценить эффективность сайта?

Чтобы получить хоть какую-то формализованную и достоверную оценку, я использовал всего два сервиса: это плагин для FireBug «YSlow» и сайт webo.in (Я уверен, что подобных сервисов гораздо больше).

Оценка качества доставки контента от сервера к клиенту, которая дается YМедленный – это сводный показатель, простой и понятный: «Рейтинг А» – все хорошо, «Рейтинг F» – все плохо.

Эта оценка формируется из 13 других подпараметров, еще более простых, описанных на английском языке на сайте.

разработчик.

yahoo.com Результат услуги webo.in - это две оценки, основанные на анализе того, следуют ли разработчики советам владельца сервиса и объема представленной на сайте информации и списка рекомендаций по дальнейшей оптимизации.

Плюс на сайте большое количество статей на эту тему.

Чтобы получить полную картину, я бы рекомендовал использовать оба метода оценки.

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



Как пользователь понимает, какой сайт быстрее, а какой медленнее?

Мы посещаем сайты за информацией, и чем раньше мы получим ее в читаемом виде, тем выше будет наше мнение о сайте.

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



Методология

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

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

Для разработки серверов было разработано более одного подхода, метода или шаблона: возьмем, к примеру, MVC .

Разработка клиента — это: HTML — структура ( С структура), CSS — внешний вид ( п возмущение), JavaScript — поведение ( Б поведение).

Всего было 6 частей: Модель, Представление, Контроллер, Структура, Презентация, Поведение, две из которых одинаковые: серверное Представление — это клиентская Структура.



М => С => [В == С] => П => Б

Я считаю, что необходимо рассматривать все 5 частей техпроцесса как единое целое.

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

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

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



Разделение труда

Для реализации такой схемы можно выделить следующие специализации: — М => С — проектировщик баз данных, разработчик системных модулей — С => [В == С] — Разработка CMS, автоматизация работы с шаблонами — [В == С] => П — планировка и дизайн — [В == С] => Б => П — JavaScript (тут я не знаю, как назвать специализацию) Это примерно 3 человека (админов, дизайнеров, менеджеров и директоров я не считаю =)
Так,

ЭШаг 1: Доставка информации и регистрация

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

Способы ускорить получение информации Уменьшение количества HTTP-запросов , Сжатие HTML и CSS , Размещение компонентов статических страниц на нескольких доменах , Уменьшение количества DOM-элементов , Размещение CSS в HEAD страницы.

, Настройка HTTP-заголовков ( Срок действия истекает , ETag , Set-Cookie ), Уменьшение количества DNS-запросов Как можно испортить первое впечатление о сайте? Загрузка и/или использование JavaScript в процессе загрузки , Использование iframe на странице Я расположил пункты в порядке убывания важности.

Все пункты предельно ясны.

Хочу остановиться лишь на одном моменте (о сжатии и кэшировании напишу ниже)



Разместите CSS в HEAD страницы: на странице должен быть только один внешний CSS-файл.

Несоблюдение этого требования приведет к задержке отображения страницы, поскольку файлы CSS загружаются последовательно + каждый HTTP-запрос занимает дополнительное время.

Важность этого требования измеряется временем ответа сервера и скоростью доступа клиента в Интернет. Требование, по сути, сводится к объединению всех CSS-файлов в один.

Возможны два варианта реализации: ручной и автоматический.

Ручной метод можно использовать только в простых проектах или в проектах со страницами одного типа.

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

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

Идея ( но не реализация!!! ) для автоматического решения вы можете использовать Здесь .

Суть идеи в синтаксисе запроса: для двух файлов /styles/a.css И /styles/b.css можно сгенерировать один запрос формы /styles/a.css;b.css .

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

При таком подходе вы можете физически разделить правила CSS на общие (обязательные на всех страницах) и частные (обязательные только на «нестандартных» страницах), а при необходимости объединить их.

Результатом первого этапа является доставленный и отформатированный HTML. Нет JavaScript (на этапе доставки основного контента он только мешает).

Время от начала до завершения загрузки такой страницы с включенным и отключенным JS фактически будет одинаковым.

Это будет выигрыш в скорости загрузки! Если выполнить требование «Уменьшение количества DOM-элементов» более-менее близко к идеалу, то побочным эффектом может стать возможность реализовать мобильную версию сайта и версию для печати с одним и тем же HTML-кодом.

Остается только реализовать наборы правил CSS для media="handheld" и media="print".



ЭШаг 2. Кэширование файлов дизайна, сжатие HTML, CSS и JS.

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

Этот этап должен проходить параллельно с первым.

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

Основной домен проекта (www.site.org)

 server {
   listen 80;
   server_name  www.site.org  site.org;
   gzip on;
   gzip_min_length 1000;
   gzip_proxied expired no-cache no-store private auth;
   gzip_types text/plain application/xml;
   location / {
     proxy_pass  http://backend ;
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   }
   location /favicon.ico {
     expires max;
     root /home/project/img/;
   }
   location /s.gif { 
     expires max;
     root /home/project/img/;
   }
 }
Вот все запросы www.сайт.com перенаправлено далее в Apache ( http://backend определяется директивой вверх по течению .

Исключением являются только favicon.ico и прозрачный s.gif: они расположены в том же каталоге, что и все остальные изображения интерфейса, и доступны браузеру как www.site.com/favicon.ico И www.site.com/s.gif .

Данное исключение для s.gif сделано только для уменьшения размера html-кода.

Ответы Apache с типом контента «text/html», «text/plain», «application/xml» сжимаются на лету.

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

Все HTML-страницы считаются динамическими, поэтому они не кэшируются.



Домен для изображений интерфейса (img.site.net)

 server {
   listen 80; 
   server_name img.site.net;
   expires max;
   add_header Cache-Control public;
   location / {
     root /home/project/img/;
   }
   location ~ ^/\d+\.

\d+\/.

* { root /home/project/img/; rewrite (\d+\.

\d+)/(.

*) /$2 break; } }

Все изображения интерфейса кэшируются навсегда.

Пример: img.nnow.ru/interface/is.png Для сброса кэша браузера введено следующее правило: если HTTP-запрос начинается с «slash number dot Number slash», то изображения следует брать из корня.

Пример: img.nnow.ru/2.0/interface/is.png Это очень полезно, когда нам нужно добавить еще один значок внутри изображения CSS-спрайта.



Домен для файлов CSS и JS (static.site.net)

 server {
   listen 80; 
   server_name static.site.net;
   expires max;
   gzip_static on;
   location / {
     return 404;
   }
   location /jas/ {
     # javascript-and-stylesheets
     proxy_set_header Host $host;
     if (!-f $request_filename) {
       break;
       proxy_pass  http://backend ;
     }
     root /home/project/static/;
   }
 }
Выше был описан принцип работы серверных механизмов сборки CSS и JS. Единственное, что стоит отметить, это директива gzip_static .

Эта директива поставляется с модулем ngx_http_gzip_static_module .

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

gz».

По умолчанию модуль не собирается; нужно включить его сборку при настройке с параметром --with-http_gzip_static_module .

Сборщик файлов дополнительно должен уметь записывать файлы вида /jas/a.css;b.css.gz .

Файлы CSS и JS кэшируются навсегда.

Сброс кеша можно выполнить, добавив к имени файла «версию файла»: /jas/ver2.0.css;a.css;b.css

Внимание! Мы реализовали конструктор таким образом, что файлы a.css и b.css включаются в конечный результат функцией PHP во время сборки.

включать , то есть на самом деле являются исполняемыми PHP-файлами.

Это дает возможность избавиться CSS-хаки или из анализа User-Agent браузера в JS: При обращении /jas/ver2.0.css;Firefox3.css;a.css;b.css Firefox3.css сохраняет имя и версию браузера в переменной PHP, и последующие части составного файла результатов могут читать эту переменную и создавать разное содержимое для разных браузеров.

Например: " s.img.nnow.ru/jas/ver ,1.0.js;Firefox3.js;habr,index.js" и " s.img.nnow.ru/jas/ver ,1.1.js;IE6.js;habr,index.js" Точно так же «версия образа интерфейса» для img.nnow.ru/3.0/interface/logo_ni.gif (соответствующая переменная задается в файле версии CSS).



ЭНажмите 3: жизнь после загрузки страницы.

Цель этого этапа — привязать события мыши к различным элементам DOM и реализовать другие веб-два-ноль навороты, т.е.

оживить страницу.

Говорят, что иногда «унция наглядности важнее килограмма вещества» — это как раз про JS. Ведь JavaScript можно использовать для реализации механизмов, упрощающих действия пользователя; вы можете сделать множество различных визуальных эффектов, подчеркивающих дизайн, удобство и полезность сайта (да и собственно всю работу, которую разработчики проделали на предыдущих этапах).

К этому моменту у нас должна быть разработанная HTML-страница со всеми ссылками и формами.

обязан работать без JavaScript. Серверные интерфейсы для Ajax-запросов должны быть готовы; Структура страницы должна быть такой, чтобы для схожих кусков HTML не обязательно было реализовывать похожие, но не идентичные куски JS-кода.

Скорее всего, следует создавать шаблоны страниц, показывающие, как будет выглядеть страница после какого-то действия пользователя.

По сути, должен быть эффективный обмен информацией между всеми разработчиками.

Я не знаю, как организовать такой диалог в команде, состоящей из десятков человек; но для команды из трех-четырех человек это вполне возможно (хотя и сложно).

Чтобы не снижать скорость доставки и оформления контента, JS-файлы (лучше всего, конечно, один JS-файл ) необходимо включить перед закрытием тега body. Жизнь начинается после загрузки HTML-кода :

Задача сводится к выполнению следующих действий:
  1. найти элементы DOM, требующие «оживления» (далее — компоненты);
  2. определить, что это за компонент;
  3. убедитесь, что включен необходимый код JavaScipt;
  4. следить за порядком подключения файлов;
  5. не разрешать несколько загрузок одного и того же файла.

Если вы дочитали до этого места ;) то вам лучше продолжить чтение на странице Модульность в JavaScript, динамическая загрузка В сети www.jsx.ru .

Вот откуда я позаимствовал этот алгоритм.

Я бы не стал афишировать свое решение, потому что.

по сути, в процессе выполнения задачи был проведен эксперимент, конечный результат которого не ясен на 100% (пока вроде все работает нормально "=" Расскажу о пунктах 3 и 4. Поиск необходимых элементов DOM должен дать нам список названий компонентов JS. Имена компонентов должны однозначно совпадать с именами файлов на сервере, содержащих их код. Также нам может потребоваться загрузить некоторые дополнительные правила CSS для найденных компонентов для некоторых визуальных эффектов, которые не нужны на первом этапе загрузки контента и дизайна.

Список названий компонентов можно объединить в один запрос к серверу.

В результате после загрузки контента файлы типа " static.site.net/jas/имякомпонента1.css;имякомпонента2.css " И " static.site.net/jas/имякомпонента1.js;имякомпонента2.js ".

У этого подхода есть два недостатка: (1) через некоторое время в папке /jas/ может сгенерироваться много файлов, что теоретически может сократить время доступа к ним на сервере; (2) иногда на странице может быть много компонентов, настолько много, что длина имени запрашиваемого объединяемого файла превышает возможности файловой системы (например, 255 символов для Ext3) - в этом случае вы потребуется разбить один запрос на несколько последовательных.



YSlow: Оценка производительности: A (100)

Сначала я так хотел назвать статью, но потом она переросла в нечто большее, чем просто «оценка работоспособности сайта».

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

Невозможность добиться отличного рейтинга производительности не дает нам повода пренебрегать клиентской оптимизацией.

Ведь шаг влево или шаг вправо от оптимального пути может означать немедленное выполнение:

Главная страница моего блога на liveinternet.ru: Оценка исполнения: F (30) Главная страница Хабра: Performance Grade F(38) Главная страница моего блога на Я.

ру: Оценка исполнения: F (42) Сообщение в официальном блоге Google: Оценка производительности: F (56) Главная страница моего блога в ЖЖ: Оценка исполнения: D (66)

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

Спасибо за внимание.

Теги: #оптимизация #скорость загрузки #Nginx #HTML #JavaScript #CSS #оптимизация клиента

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.