Создать быстрый сайт сложно.
Возглавить инициативу по улучшению производительности сайта еще сложнее.
Благодаря многочисленным методам, которые можно использовать для увеличения скорости работы сайта, руководители проектов постоянно сталкиваются с техническими вопросами и вопросами управления проектами. Вы сосредоточены на оптимизации переднего или заднего плана? Что нужно выяснить у вашей команды веб-разработчиков, прежде чем разрабатывать стратегию для повышения производительности сайта? Какие оптимизации должны быть выполнены вручную, а какие — автоматически через сервисы повышения производительности сайта?
Наличие наилучших возможных ответов на эти вопросы абсолютно необходимо для общего успеха любой инициативы по повышению эффективности сайта. Прежде чем выбирать методы, которые увеличат скорость сайта, руководители проектов должны сначала иметь четкое представление о факторах, влияющих на производительность сайта, и проанализировать, как эти факторы влияют на рассматриваемый сайт. Это, в сочетании с пониманием доступных методов оптимизации сайта, поможет руководителям проектов принимать наиболее обоснованные решения о производительности сайта.
Front End против Back End
Существуют скрытые решения, которые ваш внутренний или нанятый разработчик веб-сайта может незаметно для вас создать, что повлияет на то, насколько легко или сложно будет улучшить производительность вашего сайта и оптимизировать его в долгосрочной перспективе. Кроме того, эти «темные» решения могут быть разбиты на две категории: выбор переднего плана и выбор внутреннего уровня.
Выбор внешнего интерфейса (и здесь есть много вариантов выбора!) Влияет на то, как ваш сайт собирается, когда он достигает конечного пользователя браузером, который они используют для посещения вашего сайта.
Внутренний выбор, как правило, более жесткий и негибкий, чем выбор переднего плана. Этот выбор относится к решениям относительно того, как вы размещаете и поддерживаете свой веб-сайт, в дополнение к тем же решениям, которые были сделаны многими различными сторонними поставщиками, которые обычно интегрированы в современный веб-сайт (например, социальные сети и рекламные виджеты).
Вам следует внимательно ознакомиться с четырьмя конкретными метриками, потому что решения и методы, которые вы можете применять из этих метрик, влияют как на внешний, так и на внутренний варианты.
Время до первого байта
На самом деле это сочетание двух отдельных показателей: времени на поиск (у которого есть свое внутреннее время для подключения затрат) и времени для подключения к вашей веб-странице. Это происходит для каждого ресурса, который нужен вашей веб-странице для правильной работы.
Служба, называемая службой доменных имен (DNS), находится на «самом низком» уровне сетевого стека, который обеспечивает современный Интернет, каким мы его знаем. Без DNS устройство не сможет найти ресурсы, необходимые для сборки вашего сайта. Все службы DNS не равны. Каждое устройство (и браузер на устройстве) могут иметь различные политики, которые влияют на то, где оно получает информацию о DNS и как долго оно сохраняет (кэширует) эту информацию.
Разрешение DNS амортизируется по многим запросам ресурсов. Он часто амортизируется в нескольких сеансах браузера и даже в экземплярах браузера (например, Firefox против Chrome или IE).
Другой способ подключения — это время, необходимое для установления HTTP-соединения с внутренними серверами (от вашего и сторонних ресурсов, от которых зависит ваш сайт). Это часто более дорогая операция, чем DNS, потому что она по своей природе более сложна и требует более длинных «путей кода».
Решения бэкэнда влияют на объем работы, выполняемой для удовлетворения запроса после установления соединения. Обслуживание статических ресурсов (например, скриптов, таблиц стилей и изображений) часто выполняется значительно быстрее, чем выполнение кода, который применяет шаблон и заменяет пользовательские ресурсы. Такова жизнь.
Время на титул
Время до заголовка является первым указанием конечному пользователю, что его браузер выполнил поиск DNS, подключенный к основному домену, и что ваш веб-сервер доставил первый ресурс (документ HTML), который определяет веб-страницу.
Время до заголовка записывает, сколько времени прошло с первоначального запроса до обновления строки заголовка в браузере с именем страницы. Многие пользователи могут не заметить это изменение. Тем не менее, это происходит, и это очень важный момент данных.
Достижение этой точки — это только начало очень длинной цепочки действий, которые автоматизируются вашим браузером.
Средний веб-сайт в 2011 году имеет менее 50 ресурсов (изображения, файлы JavaScript, файлы CSS и т. Д.). Браузер проанализирует (проанализирует) документ HTML и создаст мини-компьютерную программу, которую он должен выполнить, чтобы получить все другие ресурсы, которые, по словам вашей веб-страницы, должны присутствовать. К сожалению, в существующих стандартах для Интернета отсутствует понятие о том, что ресурс является необязательным, и его можно игнорировать, если его сложно или дорого получить.
49 других ресурсов будут запрошены и обработаны сразу после обновления заголовка.
Время показа
Это тот момент, когда ваш сайт МОЖЕТ быть пригодным для использования. Проще говоря, это точка, с которой браузер начал рендерить. Render — это модное слово, которое инженеры используют для описания процесса применения всех указанных таблиц стилей и встроенных стилей к тексту, графическим ресурсам и разметке макета HTML.
Время показа стало более сложным, потому что некоторые браузеры (особенно для мобильных устройств) приняли много методов, чтобы «оптимизировать» макет для небольших экранов. Это требует времени, и каждый производитель устройств может применять различные правила и эвристики.
Если на вашем сайте много текста, время для его отображения обычно является той точкой, с которой ваши пользователи могут начать читать страницу.
Если ваш сайт имеет большую графику, время для отображения, как правило, является той точкой, в которой ваши пользователи начинают видеть макет … но для отображения графики может потребоваться время из-за продвинутых приемов обработки изображений, таких как прогрессивная визуализация.
Время интерактивности
Это тот момент, когда ваш сайт полностью интерактивен. Самый простой способ определить разницу между «отображением» и «интерактивом» — это найти веб-сайт, который не позволяет прокручивать его во время загрузки.
Я из Бостона, и здесь мы большие поклонники спорта. Так что спортивная страница местной газеты — хороший пример. Это страницы с высоким содержанием шаблонов — содержание и реклама часто меняются — но общая структура не меняется.
Мой любимый (худший) сайт для этого — Boston Herald (извините, ребята). Это сайт, который часто загружается быстро, когда я нажимаю на последнюю историю о Томе Брэди, и я обычно могу прочитать первые два абзаца, которые «выше сгиба». Тем не менее, я не могу прокрутить вниз. Почему? Поскольку на страницах сайта используются синхронные рекламные объявления, которые загружаются после отображения времени, но до полной интерактивности. Я не могу сказать вам, сколько раз я оказывался «застрявшим» и слегка расстроенным этим поведением.
Управление вашей командой
Чтобы сократить разрыв между отделами доставки и отделами маркетинга и бизнеса, а также ускорить процесс планирования и внедрения, лучше всего найти общий язык.
Если задать следующие 10 вопросов, это поможет определить, какие методы повышения производительности веб-сайта использовать для продвижения вперед:
- У нас включено сжатие?
- Сколько запросов ресурсов мы делаем
- Сколько сторонних активов у нас есть?
- Что будет с нашим сайтом, если сторонний виджет станет недоступным или очень медленным?
- Мы измеряли наши изображения, чтобы уменьшить их размер?
- Мы закодировали наши изображения, чтобы позволить прогрессивную визуализацию
- Предоставляет ли наш хостинг услуги по оптимизации?
- Используем ли мы систему шаблонов бэкэнда? Если да, то нацелены ли мы на мобильные устройства?
- Делаем ли мы какие-либо асинхронные запросы javascript?
- Мы объединили и свернули наши файлы JavaScript?
стратегия
Установить базовый уровень
Прежде чем приступить к процессу повышения производительности и оптимизации, важно установить базовый уровень, чтобы вы могли измерить успех и понять окупаемость инвестиций. Это может показаться ненужным или чрезмерно сложным. Однако без этого вы никогда не сможете ответить на самые простые вопросы, которые ваш босс в конечном итоге задаст вам:
- Насколько быстрее наш сайт?
- Сколько нам стоило добраться сюда?
- Сколько это будет стоить нам, чтобы продолжать двигаться вперед?
Один подход: вы можете развернуть две разные версии сайта на разных доменах. Например, субдомен (например, old.domain.com вполне подойдет) может содержать копию вашего сайта до проведения оптимизации. Чтобы сравнить яблоки с яблоками, вы бы хотели разместить их на эквивалентном оборудовании.
Другой важный и неявный момент установления базовой линии: вы на самом деле измеряете и узнаете об изменениях во времени. Невозможность измерить количество доступных инструментов и служб будет наказано … отсутствием пользователей, которые в конечном итоге покинут ваш сайт из-за его низкой производительности.
Ручная и автоматическая оптимизация
Если у вас есть система шаблонов с высокодинамичным содержимым, вы можете попробовать оптимизировать систему шаблонов. Для этого может потребоваться заключение контрактов специального назначения, но возврат инвестиций будет амортизироваться в тысячи или миллионы раз, когда используется система шаблонов (для каждой запрашиваемой страницы).
Если у вас есть внутренняя команда и / или ресурсы и бюджет, сначала доведите команду до уровня техники. Купите им копию книги Стива Соудера « Высокопроизводительные сайты» . Дайте команде несколько дней, чтобы прочитать книгу и выполнить все упражнения.
Если вы управляете гибким магазином, вы можете сделать тренинг историей из двух или трех пунктов. Принятие будет демонстрировать локальную копию многих образцов, представленных в книге.
Если у вас большой графический сайт, вам нужно найти способ обеспечить графику в наилучшем масштабе и качестве. Доставка графики в полном разрешении и в полном масштабе является убийцей скорости. Если вы фото-сайт, вы решаете эту проблему автоматически как часть процесса загрузки.
Если вы сайт каталога, возможно, вы просто выгружаете изображения с высоким разрешением в базу данных, которая динамически собирается по требованию системы шаблонов. Это потребует планирования некоторых историй разработки для создания автоматизированного процесса, который определяет и создает полуавтоматические задачи для преобразования изображений с минимальным, максимальным и предпочтительным разрешением для проверки того, что база данных не загрязняется изображениями с высоким разрешением на периодической основе.
Откладывать загрузку ресурсов легко, но требуется четкое понимание рабочего процесса сайта.
Например, если у вас есть веб-сайт, на котором разрешен интерактивный чат с представителем службы поддержки, у вас есть встроенная система чата и часто десятки изображений, которые можно использовать для смайликов.
Нет веских причин загружать десятки ресурсов, которые новый пользователь может даже не использовать во время своего первого посещения сайта. Существует множество приемов для выполнения отложенной загрузки.
Извлеките разметку, определяющую ресурсы, в отдельный HTML-файл и единовременно загрузите эту разметку вызовом AJAX и воздействуйте на DOM. Другой вариант — загрузить эти ресурсы в отложенный загруженный скрытый iframe. Независимо от принятой техники, для ее реализации требуется некоторое программирование на JavaScript.
CSS-спрайтинг — это очень мощный метод сокращения ресурсов. Проще говоря, CSS-спрайтинг относится к технике, которая объединяет изображения в большое изображение, которое загружается один раз и используется много раз по-разному.
Каждый раз, когда вы удаляете запрос ресурса на ваши внутренние серверы, это напрямую увеличивает скорость веб-страницы. Это действие улучшает взаимодействие с пользователем и повышает масштабируемость и пропускную способность ваших внутренних систем.
С сторонними активами сложнее всего иметь дело во многих отношениях. Вы хотите, чтобы ваш сайт был современным и был подключен к социальным сетям, но вы полностью контролируете их, когда делаете это. Эти виджеты легко интегрировать в разметку, используя метод, называемый внедрением скрипта. Google уже 10 лет использует эту же технику с «рекламным внедрением».
Если эти инъекционные сценарии загружаются синхронно (и они всегда есть), это может привести к полной ошибке загрузки страницы. Это происходит потому, что каждый скрипт оказывает побочное влияние на глобальное состояние механизма JavaScript для документа HTML, который присоединяется к этим скриптам.
Самый простой способ думать об этом — это то, что HTML-страница на самом деле является программным обеспечением, не отличающимся во многих отношениях от кода C и C ++, который использовался для реализации браузера. Браузер — это программа, которая выполняет другие программы. Современные браузеры изолируют каждую программу, которую они выполняют, чтобы гарантировать, что одна плохая программа не повлияет на производительность другой программы. Однако одним из ключевых аспектов выполнения программы HTML является то, что порядок имеет значение. Поскольку порядок имеет значение, браузер должен дождаться завершения внедрения скрипта, прежде чем выполнять следующий. Браузер может загрузить сценарий, который должен быть выполнен, в фоновом режиме, но он должен подождать, пока предыдущий сценарий полностью загрузится (или не сможет загрузиться), прежде чем двигаться вниз по последовательности.
Выполнение дополнительной работы по ручному (и асинхронному) побочному эффекту может иметь существенные преимущества с точки зрения времени отображения и интерактивности. Тем не менее, это требует специальных навыков программирования и может стать хрупким со временем. Инвестируйте осторожно и с умом.
Один из приемов, который мы используем, — предоставить изображение виджета в виде «скаффолдинга» и динамически внедрить финальный рендеринг асинхронно.
Это техника, которую использует AJAX-ориентированная реклама, использующая iframes и продвинутые приемы упорядочивания CSS для загрузки рекламных объявлений в фоновом режиме и их замены ТОЛЬКО после их успешной загрузки. Все это варианты протокола JSONP ( http : // en . Wikipedia . Org / wiki / JSONP ).
JSONP и связанные с ним методы имеют решающее значение для оптимизации вручную и динамического асинхронного рендеринга. Убедитесь, что ваша команда знакома с этими подходами и применяет их на вашем сайте.
Автоматическая оптимизация
Многие из приведенных выше оптимизаций могут быть выполнены динамически без изменения кода на вашем сайте.
Как это может быть? И почему ты так поступил?
Очевидно, это идеальный сценарий: вам не нужно вручную изменять свой сайт; вам не нужно становиться экспертом в провайдерах DNS и CDN; вам не нужно вручную кодировать свой сайт для работы с конкретным CDN; вам не нужно превращать внешние ресурсы во встроенные данные; вам не нужно объединять изображения в спрайты; и вам не нужно вручную анализировать разрешение изображения и создавать изображения альтернативного размера и разрешения.
Причина, по которой автоматизированная оптимизация может быть предоставлена как услуга, заключается в самой природе HTML-программы. Ресурсы HTML-документа представляют собой последовательные блоки данных программирования (и кода). Ваш браузер должен получить и собрать эти блоки. Кроме того, ваш браузер работает меньше, потребляет меньшую пропускную способность и создает меньше точек отказа, когда 50 ресурсов превращаются в 20 ресурсов для доставки того же «данных + кода», который необходимо проанализировать и выполнить.
Конечно, как всегда, здесь есть компромисс. Компромисс заключается в том, чтобы автоматически применять на вашем сайте самые последние и самые эффективные приемы … и скорость, с которой ваша команда может сделать это вручную для каждой страницы вашего сайта.
Если вы занялись разработкой веб-сайтов на стороне и у вас нет собственной инфраструктуры (backend-серверов), у вас могут быть ограниченные возможности, поскольку служба размещения веб-сайтов может отключить сжатие в общих планах начального уровня. Они делают это, потому что сжатие требует внутренних вычислений, а внутреннее вычисление является общим ресурсом для многих других сайтов, размещенных на той же машине.
Простой вариант здесь — перейти на более дорогой тарифный план. Обратитесь за помощью к вашему хостинг-провайдеру.
Если вы используете полную виртуальную машину или выделенный сервер, сжатие может быть отключено, поскольку по умолчанию оно обычно отключено. У вас может не быть доступа к файлам конфигурации. Опять же, попросите вашего хоста о помощи здесь.
Полезные ресурсы
Методы создания высокоэффективного веб-сайта хорошо известны, и есть много книг и бесплатных инструментов, которые помогут вам понять это:
- Стив Соудерс (инженер по производительности Google, бывший инженер в Yahoo) написал две превосходные книги по оптимизации интерфейса: http://stevesouders.com/
- 20 бесплатных онлайн-инструментов для тестирования скорости сайта http : // sixrevisions . com / tools / free — веб-сайт — скорость — тестирование /
- Инструмент оценки Google PageSpeed - еще один отличный источник: http://code.google.com/speed/page-speed/