Оптимизация сайта

Чуть меньше года назад, когда по всему миру начали распространяться локдауны в связи с Covid-19, большинство людей начало запасаться туалетной бумагой и консервами. Но лично я стремился получить нечто другое: реализовать функцию поиска.

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

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

Разбиваем задачу на части. Записываем их в to-do-приложение (я люблю пользоваться Things). И так создаётся творческая вселенная. Каждый день я отстраняюсь всемирного коллапса общества, который разворачивается за рамками моей жизни, и погружаюсь в исследовательскую работу, один за другим вычёркивая пункты to-do. Covid был масштабным; мой список to-do был приличной длины.

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

Весь процесс работы стал побегом, но побегом с импульсом для роста. Настраиваем идеальный стиль навигации с клавиатуры, сдвигаем момент передачи полезной нагрузки поиска, находим баланс между размером индекса и полезностью поиска. И самое важное сохраняем восхитительную лёгкость кода. Завершаем, превращаем код в крошечный gist на GitHub, делимся им с сообществом. Это похоже на пас мяча другим людям: вперёд, теперь вы можете использовать это на своём веб-сайте. Сверхбыстрый и оптимизированный для клавиатуры клиентский поиск на Hugo.

Он неидеален, но чертовски хорош.

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

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

Паттерн сложился: когда меня в детстве утомляли сложности социальных ситуаций, я обращался к коду, становясь затворником. Эллен Ульман в своей книге Life in Code: A Personal History of Technology пишет: Пока я не стала программистом, я не понимала во всей полноте полезность такой изоляции: тишина, сведение жизни к мысли и форме; например, уход в тёмную комнату для работы над программой, когда отношения с людьми усложняются.

Чтение книг по ассемблеру в средней школе или программирование ПО для BBS в старшей школе ещё не осознавалось мной как спасение. Моё первое осознанное признание целительной силы кода появилось несколько лет назад, когда я рефакторил свой веб-сайт с одной системы управления контентом на другую. Кажется невообразимым, но это правда: меня исцелила CMS.

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

Такое иногда случается со мной; с некоторыми людьми такое происходит часто. Когда я ощущаю тяжесть сходящей на меня депрессии, то часто вспоминаю эпиграф к Зримой тьме Уильяма Стайрона: Ибо ужасное, чего я ужасался, то и постигло меня... Обычно это означает, что я недостаточно отдыхал. Я имею в виду не в течение дней, а, скорее, месяцев или лет. Я постепенно накреняюсь, как корабль, в который через течь поступает вода. Через какое-то время он обязательно потонет. Мой мозг постепенно тонул и я ощущал, что ему как спасение нужны были серверы. Оказалось, что серверы это одно из безопасных мест для меня.

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

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

Мы верим, что вы выслушали привычную лекцию вашего системного администратора. Обычно она сводится к следующим трём пунктам:

1: Уважайте конфиденциальность других людей.

2: Думайте, прежде чем нажимать на клавиши.

3: С большой силой приходит большая ответственность.

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

Частично этим и вызвана привлекательность систем: движение сквозь этот хаос, со всей его извращённой поэзией grep, vi, git, apache и *.ini*, при помощи молниеносных движений пальцев по клавиатуре, изумляет. Ты ощущаешь себя алхимиком. Да и являешься им. Ты вводишь загадочные слова, почти абракадабру, в построчный текстовый интерфейс, и вот готово простое приложение, доступ к которому мгновенно появляется у огромного количества людей по всему свету.

Любимые люди часто испытывали смущение или даже подозрительность, случайно узнав, что я хорошо владею bash (разновидность терминальной оболочки для ввода команд). Как будто я скрывал от них какую-то неприятную тайну. Однажды, войдя мир текста, я несколькими быстрыми нажатиями клавиш помог сыну-подростку друга установить моды для Minecraft. По его взгляду я понял, что мгновенно стал для него кем-то вроде рок-звезды. Благодаря двум сотням нажатий появился мостик между двумя поколениями.

Я нахожу умиротворение в тёмном хаосе этого мира. Код и серверы являются для меня домом, и это чувство сложно объяснить тем, для кого они домом не стали.

Поэтому в моём накренённом, слегка депрессивном состоянии я занялся переносом веб-сайтов со старого на новый сервер. Мои задачи были записаны в моём надёжном списке to-do. Адреса URL старых сайтов знаменовали уникальные эпохи моей жизни, через объективы которых я когда-то видел себя.

Мои старые веб-сайты это призраки. Никто не будет их просматривать или атаковать их. Я перенёс их, потому что ощущал ответственность за них, чувствовал, что они имеют право продолжить жизнь в битах.

Основная часть работы с серверами была связана с тем, чтобы сделать сложные сайты менее сложными. То есть превратить динамическое в статическое. Вырвать эти сайты из их PHP-ядер, вернуть их обратно к спокойным HTML и CSS, сделать так, чтобы на их обслуживание требовалось мало времени и они были готовы к будущему. Забавно, что даже нечто простое вроде базы данных MYSQL требует обрезки и подкормки, подобно растениям. Что кажущийся безобидным PHP-скрипт становится спустя десяток лет устаревшим из-за эволюции ментальных моделей языков. Но если взять страницу на HTML из ранних 90-х, то она отрендерится почти на любом устройстве с экраном.

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

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

В конце 1990-х у нас практически не было выбора, каждому приходилось быть владельцем, уборщиком и системным инженером своей домашней страницы. Сегодня можно спихнуть эту ответственность на третьих лиц. Tumblr, Ghost, Facebook, Blogger, Wordpress возникло множество платформ, на которых можно сосредоточиться исключительно на контенте, взамен этого понизив свой уровень контроля.

Можно поднять уровень ответственности слишком высоко. Вероятно, это случилось со мной. Сколько бы усилий ты не вложил в систему, эффект от этого не может превысить некой величины. Но меня это не волнует.

Эта работа, построчное решение проблем, иногда становится именно тем, что заставляет меня вставать с кровати. Вам знакомо это чувство? Не хочу выбираться из-под одеяла? Каждое утро последнего года для всего человечества, наверное, самым большим желанием было остаться в постели, настолько разбалансированным оказался этот мир. Но потом под этим одеялом я начинаю думать Ага! Я знаю, как решить проблему X сервера, или как разобраться со странным поведением Y. Я знаю, как исправить этот код поиска. И благодаря этому я могу встать и стать человеком (или хотя бы частично человеком), войти в этот мир строк, где тебя никто не осудит. В нём только ты и механика систем; систем, которые становятся всё более красивыми, чем больше времени ты на них тратишь. Для меня такая ответственность это терапия.

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

Здравствуйте. Меня зовут Ник, я фронтенд разработчик (жидкие аплодисменты). Кроме того, что я пишу код, я преподаю в Школе программистов hh.ru.

Записи наших лекций от 2018-2019 учебного года можно посмотреть на youtube

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

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

Лонгридом можно пользоваться как справочником, чтобы не читать за один присест. Вот список тем, которые мы затронем:

1. Зачем думать о производительности
2. FMP, TTI + подробнее в докладе
3. Critical render path, DOM, CSSOM, RenderTree
4. Шаги по улучшению производительности первой загрузки + подробнее в докладе

Для удобства восприятия я решил разделить статью на две части. Вторая часть будет о таких операциях, как layout, repaint, composite и их оптимизации.

Зачем вообще думать о производительности? Мотивационная часть

0.1 секунда это тот gap, который позволяет пользователю осознать, что именно его клик мышки, удар по клавиатуре побудил эти изменения в приложении\интерфейсе.
Кажется, у всех было то неловкое чувство, когда ты сочиняешь письмо\код\любой другой текст, а интерфейс "за тобой не успевает". Ты уже пишешь второе слово, а на экране всё еще песочные часы (если мы про windows) и еле-еле набирается первое. Аналогично и с кликами на кнопки. Я хочу, чтобы интерфейс мне подсказывал, мол, "окей, я тебя услышал, ща все будет".
За примером далеко ходить не нужно. Я пользуюсь веб-версией одного российского почтовика (не будем называть имен) и когда выделяю письма для их удаления, то бывают большие задержки. И я не понимаю: то ли я не попал по кнопке", то ли сайт тормознутый. И обычно верно второе.
Почему 0.1 секунда? Дело в том, что мы замечаем и успеваем обработать даже куда более ограниченные по времени изменения и наш мозг находится "в контексте".
В качестве яркого примера посмотрите клип 30 seconds to mars hurricane. Там есть вставки на кадр-два с текстом не 9:30. Глаз успевает не только осознать вставку, но и частично определить контент.

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

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

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

10 секунд если погуглить, на всякую аналитику вроде "среднее время пользователя на сайте" мы увидем число: 30 секунд. Сайт загружающийся 5 секунд убивает 1/6 времени пользователя. 10 секунд треть.

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

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

Большие компании даже хорошую аналитику для таких целей имеют:

• Walmart: 1 секунда ускорения + 2% конверсии
• Amazon: 0,1 секунды увеличивает выручку на 1%
• Что-то аналогичное есть у Яндекса (киньте в комментариях ссылку, я потерял)

И последний мотивационный пост в статье от википедии:

Однако достаточно вводной, пора двигаться дальше.

Два извечных вопроса

Давайте запустим lighthouse на hh.ru. Выглядит всё очень не очень (запуск на mobile, на desktop все сильно лучше):

Появляется два традиционных вопроса:

1. Кто в этом виноват?
2. Что с этим делать?

Хотя первый вопрос я бы заменил на "Как это расшифровать".
Сразу спойлер: картинки "как круто стало в конце не будет. Как сделать лучше мы знаем. Но есть определенные ограничения.

Давайте разбираться

В первом приближении у нас есть 3 потенциальных сценария:

1. Отрисовка страницы (с html от сервера)
2. Работа загруженной страницы (клики пользователя и т.д.)
3. SPA переходы между страницами без перезагрузки

У пользователя существует два этапа при отрисовке страницы, когда он может частично взаимодействовать с сайтом. И полноценно: FMP (First Meaningful Paint) и TTI (Time to interactive), когда ресурсы загружены, а скрипты проинициализированы:

Если судить о значении для пользователя: FMP == текст, есть верстка и пользователь может начать потреблять контент (конечно, если вы не инстаграмм). TTI == сайт готов к работе. Скрипты загружены, проинициализированны, ресурсы загружены.

Подробнее о расчетах FMP\TTI и как мониторить эту информацию на своем сайте, снимая данные с реальных людей, я рассказывал на РИТ++. В этом же докладе я говорил и про эксперименты, которые мы проводили по ускорению и замедлению скорости работы сайта.

Наиболее важный показатель для нас FMP. Соискатели открывают поиск, затем накликивают "открыть в новой вкладке" большое количество вакансий, а затем читают и принимают решение об отклике. C некоторыми оговорками (нюансы рендера браузера) FMP можно воспринимать как одну из основных метрик, которая описывает Critical render path. Critical render path это набор действий и ресурсов, которые браузер должен совершить, загрузить и обработать, чтобы пользователь получил свой первый результат, пригодный для работы. То есть это минимальный набор html, css и блокирующие скрипты (если так еще кто-то делает), без которых сайт не отобразится пользователю.

Critical render path или что браузер делает для того, чтобы пользователь увидел тот самый текст?

TL&DR;

1. Сделать запрос (DNS resolve, TCP поход и т.п.);
2. Получить HTML-документ;
3. Провести парсинг HTML на предмет включенных ресурсов;
4. Построить DOM tree (document object model);
5. Отправить запросы критических ресурсов. CSS, блокирующий JS (параллельно с предыдущим пунктом);
6. Получить весь CSS-код (также запускаем запросы на JS-файлы);
7. Построить CSSOM tree;
8. Выполнить весь полученный JS-код. Здесь могут вызываться layout, если из js кода происходит форсирование reflow;
9. Перестроить DOM tree (при необходимости);
10. Построить Render tree;
11. Отрисовать страницу (layout paint Composite).

Теперь пройдемся по пунктам отдельно:

Подробно:

Request

Формируем запрос, резолвим DNS, IP, TCP поход, передача запроса и т.п. Байтики бегают по сокетам, сервер получил запрос.

Response

Бекенды зашумели вентиляторами, обработали запрос, записали обратно данные в сокет и нам пришел ответ. Например, вот такой:

Мы получили байты, сформировали из нее строку, основываясь на данных text/html, и после пометки нашего запрос как "navigate" (кому интересно это можно посмотреть в ServiceWorker) браузер должен сформировать из этого html DOM.

Сказано, сделано:

Обработка DOM

DOM

Мы получаем строку или поток данных. На этом этапе браузер парсит и превращает полученную строку в объект:

Это только каркас. Сейчас браузер ничего не знает про стили и про то, каким образом всё это рендерить.

Загрузка блокирующих ресурсов

Браузер будет последовательно обрабатывать полученный html и каждый ресурс. CSS, JS может быть загружен как синхронно, блокируя дальнейшую обработку DOM, так и асинхронно (для css это способ с preload + сменой rel после загрузки на stylesheet). Поэтому каждый раз, когда браузер будет встречать блокирующую загрузку стилей или JS, он будет формировать запрос за этим ресурсом.
Для каждого такого ресурса повторяем путь с запросом, ответом, парсингом ответа. Здесь появляются ограничения, например, количество одновременных запросов на домен. Предположим, что все блокирующие запросы были описаны внутри тега head, браузер сделал запросы, получил нужные для рендера стили. После формирования DOM переходим к следующему этапу:

CSSOM

Предположим, что помимо meta и title был тег style (либо link). На данном этапе браузер берет DOM, берет CSS, собирает соответствия, и на выходе мы получаем объектную модель для CSS. Выглядит это примерно так:

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

CSSOM важен, так как его понимание позволяет браузеру сформировать RenderTree.

RenderTree

Последний шаг на этапе от формирования деревьев к рендеру.

На этом этапе мы формируем дерево, которое будет рендериться. В нашем примере левая часть дерева, которая включает head, рендериться не будет. Так что эту часть можно опустить:

То есть, именно это дерево мы и отрендерим. Почему его? Если мы зайдем в DevTools там отображается DOM". Дело в том, что, хоть в DevTools и присутствуют все DOM элементы, все расчеты и вычисленные свойства уже основаны на RenderTree.

Проверить крайне легко:

Здесь мы выделили кнопку во вкладке Elements. Мы получили всю "вычисленную" информацию. Её размеры, положение, стили, наследование стилей и т.д.
Когда мы получили RenderTree, наша следующая задача выполнить Layout Paint Composite нашего приложения. После этих трех этапов пользователь и увидит наш сайт.
Layout Paint Composite могут быть болью не только во время первого рендера, но и при работе пользователя с сайтом. Поэтому мы разберем их во второй части статьи.

Что можно сделать, чтобы улучшить метрики FMP и TTI?

TL&DR;

1) Работа с ресурсами:

1.1) Разнести блокирующие ресурсы по страницам. Как js, так и css. Хранить реиспользуемый между страницами код либо в отдельных бандлах, либо в отдельных небольших модулях.

1.2) Грузить то, что пользователю нужно в начале работы со страницей (очень спорный момент!)

1.3) Вынести third-party скрипты

1.4) Грузить картинки лениво

2) HTTP2.0 / HTTP3.0:

2.1) мультиплексинг

2.2) сжатие заголовков

2.3) Server push

3) Brotli

4) Кэш, ETag + Service worker

Подробно:

Работа с ресурсами

Разносим блокирующие ресурсы. JS

Основной болью являются 2 вещи: блокирующие ресурсы и размер этих ресурсов.
Самый главный совет для больших сайтов это разнести блокирующие стили, ресурсы по страницам. Реиспользумый код выносить в отдельные бандлы или модули. Для этого можно воспользоваться условным loadable-components или react-imported-component для реакта и похожими решениями для vue и т.д. Если наши компоненты импортируют стили, то мы сможем также и разбить стили на отдельные страницы.
На выходе мы получаем:

1. бандлы с реиспользуемыми JS модулями
2. страничные бандлы.

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

Изначальная расстановка:

Стратегия 1: делаем зависимость модуль страницы, которые используют модуль

Так, чтобы загрузить главную страницу (index.html), нам нужно будет загрузить 2 бандла: Common.JS + applicant+index.JS, а для страницы /applicant нужно загрузить все 4 бандла. На больших сайтах таких модулей может быть очень много. В этом случае нам помогает решить эту проблему использование HTTP2.0.

Итого:
+: Данные распределены между страницами, мы грузим всегда только необходимое
+: Модули легко кэшируются, после релиза не обязательно обновлять все бандлы у пользователя
-: Много сетевых издержек для получения отдельных ресурсов. Фиксим с помощью мультиплексирования HTTP2.0.

Стратегия 2: реиспользуемые модули хранятся отдельно:

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

+: Во время релизов большая часть модулей останется в кэше у пользователя
-: Еще больший рост сетевых издержек, если у пользователя нет HTTP2.0
-: Кэши могут не работать, так как файлы будут меньше 1 Кб. Здесь нас может спасти Service worker. О нем будет ниже.

Эта стратегия имеет право на жизнь, так как минусы решаемы.

Стратегия 3: Иметь большой бандл реиспользуемого кода:

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

Я бы рекомендовал либо не использовать этот вариант вообще, либо использовать его для небольших сайтов.

Анти-Стратегия 1: Каждая страница хранит весь список зависимостей, выносим только common:

В данном случае мы получаем большой оверхед. При переходе с одного ресурса на другой пользователь закачивает себе модули, которые уже у него были несколько раз. Например, пользователь заходит на главную и скачивает 2 бандла: Common.JS и Index.JS затем авторизуется и попадает на страницу соискателя. Итого, код для Dropdown.JS и Graph.JS будет скачан дважды.

Пожалуйста, не делайте так :)

Итого

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

Оффтоп. Почему 30 Кб JS это больнее, чем 30 Кб картинки

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

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

Итого, на обработку JS кода мы тратим больше времени, чем на ту же картинку.

Разносим блокирующие ресурсы. CSS

Данное улучшение напрямую влияет на FMP, если у вас не асинхронный CSS.
Если вы используете react\vue\angular, то для стилей стоит сделать то же, что и в предыдущем пункте. Как правило, в том же react-коде мы имеем импорты вида:

import './styles.css'

Это значит, что во время бандлинга JS-кода мы можем разделить и CSS, воспользовавшись одной из стратегий выше. Это поможет вебпаку или другому бандлеру получить аналогичные common.css, applicant-page.css и applicant+employer.css.
Если разбить используемый CSS не получается, можно посмотреть в сторону used-styles и статью на эту тему: "optimising css delivery". kashey спасибо за клевые инструменты :)

Это поможет ускорить загрузку, например в случае с hh.ru почти на секунду по эстимейтам lighthouse:

Грузим то, что увидит пользователь, а не всю страницу.

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

Идея данной оптимизации в том, чтобы управлять загрузкой ваших ресурсов. В начале загрузить блокирующим способом тот CSS, который жизненно необходим для открытия страницы. Весь CSS, который относится к всплывающим элементам, popup-ам, которые спрятаны под JS кодом можно будет грузить асинхронно, например, добавив rel=stylesheet уже из JS кода, либо воспользовавшись prefetch с onload колбеком.

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

Выносим third-party скрипты

У нас в hh их много. Очень много!
Например? здесь в ТОП-10 самых тяжелых скриптов 7 third-party.

Что мы можем с этим сделать?

1. Убедиться, что все ресурсы грузятся асинхронно и не влияют на FMP.
2. Для рекламы и прочих вещей (излишней аналитики, popup-ов поддержки) снизить их влияние на основной "полезный" код. Это можно сделать, начав их инициализировать из нашего кода по requestIdleCallback. Эта функция запланирует вызов колбека с низшим приоритетом, когда наш браузер будет простаивать.

Такой подход позволяет нам экономить на FMP, хотя в TTI мы по-прежнему будем наблюдать проблемы. Это также поможет нам отложить работу прожорливых third-part скриптов.

Грузим картинки лениво

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

1. Картинки попадающие на первый экран, грузим как обычно
2. Оставшимся картинкам проставляем специальные атрибуты, чтобы изображение грузилось только по мере того, как пользователь проскроллит к нему
3. Используем любую библиотеку\велосипед для ленивой загрузки картинок. Вот здесь достаточно хорошо описан подход.

HTTP2.0

Многие из пунктов HTTP2.0 могут не сэкономить заметного количества времени, но разобрать их стоит.

HTTP2.0 Мультиплексинг

В случае если сайт загружает большое количество ресурсов, HTTP2.0 с мультиплексингом может сильно помочь.
Предположим, у нас есть 6 блокирующих ресурсов на домене, которые нужно скачать, чтобы отобразить сайт. Это могут быть стили или блокирующий JS. Считаем, что пользователь уже загрузил HTML:

Для отображения контента браузер будет производить параллельные запросы к каждому ресурсу:

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

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

Именно поэтому совет нужен бандлинг и отдавать пользователю один бандл с нужным ему на этой странице CSS \ JS картинками работает.

Что такое мультиплексирование?

Мультиплексирование позволяет нам грузить ресурсы внутри одного HTTP запроса:

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

HTTP2.0 Сжатие заголовков

До http2.0 сжатия заголовков не существовало. В HTTP2.0 был анонсирован HPACK, которые отвечает за сжатие. Здесь можно почитать подробнее.

Иногда заголовки могут занимать значительный объем запроса. О том, как работает сжатие заголовков HPACK вкратце:

Используется два словаря:

1. Статический для базовых заголовков
2. Динамический для кастомных

Для префиксного кодирования используется Huffman coding. На практике эта экономия выходит не сильно высокой и малозаметной.

HTTP2.0 Server push

В базовом варианте server push реализовать несложно. Проще всего сделать такую штуку для статических сайтов. Идея простая: вместе с запросом html страницы, наш веб-сервер заранее знает, что пользователю нужно отдать такой-то css, такую-то картинку и такой-то JS.

Реализуется достаточно просто (nginx):

location = /index.html {    http2_push /style.css;    http2_push /bundle.JS;    http2_push /image.jpg;  }

Проверить, что все работает несложно:

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

Сжатие данных

Наиболее популярными решениями сейчас являются gzip и brotli. Вот сайт, где есть хорошее сравнение степени сжатия двух алгоритмов:

Примерно полтора года назад мы в hh.ru перешли с gzip на бротли. Размер нашего основного бандла уменьшился с 736 КБ до 657. Выиграли почти 12%.

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

Но в любом случае Brotli ваш бро! На сайтах среднего размера он позволяет сэкономить секунду-полторы загрузки на слабых 3G сетях, что сильно улучшает как пользовательские ощущения, так и метрики в том же lighthouse.

КЭШ

Примечание: описанный здесь способ не поможет вам получить дополнительные баллы у lighthouse, но поможет при работе с реальными пользователями. Этот способ положительно сказывается как на FMP, так и на TTI.
Сам кэш можно включить либо с помощью заголовков у статики, либо с помощью Service Worker.
Если мы говорим о заголовках, для этого служит 3 основных параметра:

1. last-modified или expires
2. ETag
3. Cache-control

Первые два (last-modified и expires) работают по дате, второй ETag это ключ, который используется при запросе и если ключи совпадают, сервер ответит 304 кодом. Если не совпадут, то сервер отправит нужный ресурс. Включается на Nginx очень просто:

location ~* ^.+\.(js|css)$ {            ...    etag on;}

Disk cache проверяется очень просто через dev tools:

Cache-control это стратегия того, как мы будем кэшировать информацию. Мы можем или отключить его вовсе, установив cache-control: no-cache, что может быть полезным для html запросов, которые часто меняются. Либо мы можем указать очень большой max-age, чтобы данные хранились как можно дольше. Для нашей статики, мы устанавливаем вот такой Cache-control:

cache-control: max-age=315360000, public

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

У нас есть "три способа" запуска нашего приложения: cold\warm и hot run. Идеально, если мы будем запускать приложение в режиме hot run, потому что на этом этапе мы не тратим время на компиляцию нашего года. Его достаточно только десериализовать.

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

Мы на самом деле можем зафорсить hot run, использовав Service Worker. Механизм следующий:

1. Устанавливаем пользователю Service Worker;
2. Service worker подписывается на fetch;
3. Если происходит fetch за статикой, то сохраняем результат в кэш;
4. Добавляем перед отправкой запроса проверку на наличие ресурса в кэше.

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

Минимальный вариант кода для данного случая:

self.addEventListener('fetch', function(event) {        // Кешируем статику, но не картинки    if (event.request.url.indexOf(staticHost) !== -1 && event.request.url.search(/\.(svg|png|jpeg|jpg|gif)/) === -1) {        return event.respondWith(                        // проверяем наличие данных в кеше            caches.match(event.request).then(function(response) {                if (response) {                    return response;                }                                // Если данных в кеше нет, делаем запрос и сохраняем данные в кеш, который наызываем cacheStatic                return fetch(event.request).then(function(response) {                    caches.open(cacheStatic).then(function(cache) {                        cache.add(event.request.url);                    });                    return response;                });            })        );    }});

Итого

Мы рассмотрели наш Critical render path с точки зрения клиента (не углубляясь в такие вещи, как резолв DNS, handshake, запросы в БД и т.п.). Определили те шаги, которые делает браузер, чтобы сформировать первую страницу для пользователя. Поверхностно посмотрели на сложные способы оптимизации (разделения контента и т.д.)/ И разобрали более простые способы оптимизации: бандлинг, кэш, сжатие, транспорт.

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

Небольшое уточнение: здесь рассмотрены не все способы оптимизации, их заметно больше и появляются новые. Например, в chrome 85 появится свойство content-visibility, которое позволит сократить время на рендеринг за счет отложенных вычислений.

За четыре месяца занятий были прочитаны 54 лекции на двух потоках бекэнд и фронтенд, проведены несколько крутых практикумов с live-codingом. Проверены сотни заданий, на все вопросы получены две сотни ответов. Тут пришел 2020 год и сразу после того как мы сняли с елок гирлянды, всем нам самим пришлось нарядиться в маски и надеть перчатки. А теперь по порядку:



Десятая Школа Программистов hh.ru стала особенной. Юбилей, огромное количество планов, неиссякаемый поток учеников, неугасающая мотивация наших преподавателей и организаторов. Мы приложили максимум усилий, чтобы этот выпуск стал образцовым.

Десятая Школа Программистов hh.ru стала особенной. Юбилей, огромное количество планов, неиссякаемый поток учеников, неугасающая мотивация наших преподавателей и организаторов. Мы приложили максимум усилий, чтобы этот выпуск стал образцовым.

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

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

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

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

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

Вот эти темы:

• Сервис по формированию коммерческих предложений для работодателей сервис поддержки наших salesов, который позволит работать эффективнее, а нашим клиентам получать действительно индивидуальные предложения;
• Внутренний сервис для разработчиков, позволяющий геймифицировать процесс написания кода и создавать рейтинги разработчиков по различным критериям приложение должно общаться с нашим GitHub-аккаунтом и показывать данные о тех разработчиках, которые работают быстрее, выше и сильнее;
• Сервис для оценки качества поисковой выдачи. Наверняка вы слышали /что в интернете кто-то не прав:)/, как кто-то жалуется на то, что в результатах поиска в интернете нашлась какая-то нерелевантная информация. Так вот, у нас на сайте hh.ru тоже так бывает. Чтобы это исправить, нужен сервис, который будет позволять оценивать, насколько поиск был успешным и насколько результаты соответствуют запросу;
• Внутренний сервис для тимлидов и разработчиков по оценке навыков мы, как и многие технологические компании, поощряем развитие сотрудников и для рекомендаций и помощи тимлидам используем систему оценки навыков. Её MVP был реализован через google forms, но функциональности очень не хватало, поэтому решили сделать свою кастомную систему;
• Сервис для тегирования вакансий. Сейчас в нашем приложении для вакансии и резюме можно указать ключевые навыки, которые являются приоритетными метками для поиска и сравнения. Их нужно проставлять вручную и не всегда это делают правильно. Цель проекта автоматически вычислять теги на основании других полей вакансии.

Согласитесь, отличные проекты? Тянет на отдельное веб-приложение или полноценную новую фичу уже существующего приложения. Кстати, если бы у вас была возможность предложить какую-то тему или идею для проекта в Школе программистов, то что бы это могло быть?

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

Сервис опроса компетенций тимлида

Это полноценное веб-приложение, которое работает независимо от нашего основного hh.ru.

На фронтенде использовались:

• react
• react final form
• redux
• material-ui-kit для ускорения прототипирования интерфейса

На бекенде:

• nuts-and-bolts (NaB) наш собственный web-фреймворк на java
• jersey
• hibernate
• PostgreSQL

Все части приложения завернуты в Docker.

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

Сервис рейтинга разработчиков

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

На фронтенде использовались:

• react
• redux
• final-form
• date-fns
• less как препроцессор для стилей

На бекенде:

• nuts-and-bolts (NaB)
• jersey
• hibernate
• PostgreSQL

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

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

Сервис по формированию коммерческих предложений для работодателей

Это приложение реализовывалось как отдельный сервис внутри нашей экосистемы микросервисов, относящихся к hh.ru

На фронтенде использовались:

• react
• react final form
• redux
• material-ui-kit для ускорения прототипирования интерфейса

На бекенде:

• nuts-and-bolts (NaB)
• jersey
• hibernate
• kafka как технология для передачи событий от систем бизнес-аналитики и веб-приложения к новому сервису
• PostgreSQL

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

Сервис для улучшения качества поисковой выдачи

На фронтенде использовались:

• react
• redux
• less, как препроцессор для стилей

На бекенде:

• nuts-and-bolts (NaB)
• jersey
• hibernate
• PostgreSQL

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

Лучшей же оценкой самого проекта стало пожелание продакт-менеджера поиска поскорей выкатывать сервис в продакшен.

Сервис для тегирования вакансий

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

На фронтенде для реализации админки использовались:

• react
• redux
• less

На бекенде для сбора и анализа данных:

• nuts-and-bolts (NaB)
• jersey
• hibernate
• PostgreSQL
• Apache Lucene
• Яндекс.Танк для нагрузочного тестирования

Основным челленджем стало погружение в ML, изучение метрик TF-IDF, PMI и их производных. На финальном демо команда поделилась тем, что основными трудностями при реализации алгоритма стали: отсутствие достаточного времени для анализа данных, отсутствие метрик качества, чтобы сравнивать алгоритмы и очень большая вариативность в параметрах модели.

Мы уверены, что идеи и их реализации получились достойными нашей юбилейной Школы. А 22 выпускника станут отличными программистами да чего скромничать, они уже стали. 11 из них мы позвали работать к нам, а остальным предоставим рекомендации и приложили усилия, чтобы ребята попали в хорошую компанию!

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

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

Обучение полностью бесплатное.

Алгоритм поступления проще, чем сортировка пузырьком:

1. заполни анкету на сайте

2. выполни тестовое задание

3. пройди online-собеседование с нашими сотрудниками

Мы ждем тебя в нашей Школе!


Хорошего вам дня и вспоминая Мольера, подведем итог: Как приятно знать, что ты что-то узнал!

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

Как работают CDN

Сети доставки контента (content delivery network) работают по двум основным сценариям:

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

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

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

Преимущества технологии:

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

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

Принцип работы CDN

CDN для коммерческих сайтов

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

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

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

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

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

Вред CDN для сайта

А может ли CDN вредить сайту? Запросто, и тому много примеров.

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

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

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


Серверное оборудование

Какие проблемы CDN не решают

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

• неоптимизированные изображения;
• тяжелый и лишний код;
• неправильное подключение JS и CSS;
• ошибки в настройке базы данных;
• недостаточная мощность сервера.

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

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

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

CDN для кого?

В мире построено немало станций content delivery network. Они располагаются на всех континентах, в различных регионах, странах и районах. Услуги сетей CDN пользуются спросом со стороны кого?

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

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

При продвижении позиций сайта выйти в ТОП недостаточно. Чтобы увеличить число посетителей необходимо делать страницы релеватными, улучшить дизайн сайта, проработать кликабельность (CTR).В этой статье поговорим про кликабельность.

Почему так важен CTR

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

Эмодзи в Title

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

Эмодзи в Description

Эмодзи в Description эффектен в виде нескольких подряд размещенных звезд перед текстовой частью у пользователей возникает ассоциация с рейтингом. Чтобы символы правильно отображались, нужно, чтобы они отвечали стандарту кодировки UTF-8, поскольку в ином формате эмодзи могут быть не видны пользователю на экране.

FAQ в выдаче Google

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

Чтобы она отображалась в системе, страница должна соответствовать требованиям:

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

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

Для создания структурированных сведений можно воспользоваться сервисом Page Rich Snippet Generator, в форме которого нужно вписать вопросы и ответы. После введения данных, с правой стороны окна автоматически генерируется код, который нужно внедрить на сайт.

Изменения регистра в названии сайта

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

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



Изменения станут наглядны после их модерации. Основанием для отклонения заявки модераторами могут быть несоблюдения регламента проведения процедуры:

• размещение подряд более пяти букв верхнего регистра;
• корректировка отображения названия портала на интернациональном домене;
• не соблюдение правил русского языка при установке заглавных букв в общеприменяемых аббревиатурах.

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

Фавикон

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

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

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

Быстрые ссылки

Автоматически сформированный роботом поисковой системы блок ссылок перенаправляет пользователя на наиболее посещаемые разделы сайта.

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

Рейтинг, телефон и адрес

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



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

Заключение

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