загрузка dom что это
Страница: DOMContentLoaded, load, beforeunload, unload
У жизненного цикла HTML-страницы есть три важных события:
Каждое из этих событий может быть полезно:
Давайте рассмотрим эти события подробнее.
DOMContentLoaded
Но он не дожидается, пока загрузится изображение. Поэтому alert покажет нулевой размер.
На первый взгляд событие DOMContentLoaded очень простое. DOM-дерево готово – получаем событие. Хотя тут есть несколько особенностей.
DOMContentLoaded и скрипты
Когда браузер обрабатывает HTML-документ и встречает тег
В примере выше мы сначала увидим «Библиотека загружена…», а затем «DOM готов!» (все скрипты выполнены).
Есть два исключения из этого правила:
DOMContentLoaded и стили
Внешние таблицы стилей не затрагивают DOM, поэтому DOMContentLoaded их не ждёт.
Но здесь есть подводный камень. Если после стилей у нас есть скрипт, то этот скрипт должен дождаться, пока загрузятся стили:
Причина в том, что скрипту может понадобиться получить координаты или другие свойства элементов, зависящих от стилей, как в примере выше. Естественно, он должен дождаться, пока стили загрузятся.
Так как DOMContentLoaded дожидается скриптов, то теперь он так же дожидается и стилей перед ними.
Встроенное в браузер автозаполнение
Например, если на странице есть форма логина и пароля и браузер запомнил значения, то при наступлении DOMContentLoaded он попытается заполнить их (если получил разрешение от пользователя).
window.onload
Событие load на объекте window наступает, когда загрузилась вся страница, включая стили, картинки и другие ресурсы.
В примере ниже правильно показаны размеры картинки, потому что window.onload дожидается всех изображений:
window.onunload
Обычно здесь отсылают статистику.
Предположим, мы собрали данные о том, как используется страница: клики, прокрутка, просмотры областей страницы и так далее.
Естественно, событие unload – это тот момент, когда пользователь нас покидает и мы хотим сохранить эти данные.
Его можно использовать вот так:
К тому моменту, как sendBeacon завершится, браузер наверняка уже покинет страницу, так что возможности обработать ответ сервера не будет (для статистики он обычно пустой).
Для таких запросов с закрывающейся страницей есть специальный флаг keepalive в методе fetch для общих сетевых запросов. Вы можете найти больше информации в главе Fetch API.
window.onbeforeunload
Если посетитель собирается уйти со страницы или закрыть окно, обработчик beforeunload попросит дополнительное подтверждение.
Если мы отменим это событие, то браузер спросит посетителя, уверен ли он.
Вы можете попробовать это, запустив следующий код и затем перезагрузив страницу:
По историческим причинам возврат непустой строки так же считается отменой события. Когда-то браузеры использовали её в качестве сообщения, но, как указывает современная спецификация, они не должны этого делать.
Поведение было изменено, потому что некоторые веб-разработчики злоупотребляли этим обработчиком события, показывая вводящие в заблуждение и надоедливые сообщения. Так что, прямо сейчас старые браузеры всё ещё могут показывать строку как сообщение, но в остальных – нет возможности настроить показ сообщения пользователям.
readyState
Что произойдёт, если мы установим обработчик DOMContentLoaded после того, как документ загрузился?
Естественно, он никогда не запустится.
Есть случаи, когда мы не уверены, готов документ или нет. Мы бы хотели, чтобы наша функция исполнилась, когда DOM загрузился, будь то сейчас или позже.
Свойство document.readyState показывает нам текущее состояние загрузки.
Есть три возможных значения:
Так что мы можем проверить document.readyState и, либо установить обработчик, либо, если документ готов, выполнить код сразу же.
Событие readystatechange – альтернативный вариант отслеживания состояния загрузки документа, который появился очень давно. На сегодняшний день он используется редко.
Для полноты картины давайте посмотрим на весь поток событий:
Рабочий пример есть в песочнице.
Цифры в квадратных скобках обозначают примерное время события. События, отмеченные одинаковой цифрой, произойдут примерно в одно и то же время (± несколько миллисекунд).
Как быстрее DOM построить: парсинг, async, defer и preload
На сегодняшний день, джентльменский набор по ускорению сайта включает в себя всё от минификации и оптимизации файлов до кеширования, CDN, разделения кода и так называемого tree shaking. Но даже если вы не знакомы с этой терминологией, значительного ускорения можно добиться и парой ключевых слов с продуманной структурой кода.
По кирпичикам
HTML описывает структуру страницы. Для того, чтобы браузер смог извлечь из HTML хоть какую то пользу, его надо конвертировать в понятный браузерам формат — Document Object Model или попросту DOM. У браузера есть специальная функция парсер, позволяющая конвертировать из одного формата в другой. HTML парсер конвертирует HTML в DOM.
Связи различных элементов в HTML определяются вложенностью тегов. В DOM, эти же связи образуют древовидную структуру данных. У каждого тега HTML в DOM есть своя вершина (вершина DOM).
Шаг за шагом браузер строит DOM. Как только первые строки кода становятся доступными, браузер начинает парсить HTML, добавляя вершины в дерево.
У DOM две роли: объектная репрезентация HTML документа и в то же время DOM служит интерфейсом, связывая страницу с внешним миром, например с JavaScript. Если, например, вызвать document.getElementById() то функция вернёт вершину DOM. Для манипуляции с вершиной и тем как её видит пользователь у вершины есть множество функций.
CSS стили на странице отображаются в модель CSSOM — CSS Object Model. Очень похож на DOM, но для CSS, а не HTML. В отличии от DOM, CSSOM нельзя построить пошагово, т.к. стили в CSS могут переопределять друг друга. Браузеру приходится значительно потрудится чтобы применить CSS к DOM.
История тега <script>
Раньше, чтобы запустить скрипт, нужно было приостановить парсинг и продолжить его только после выполнения скрипта JavaScript’ом.
Скрипты также могут отправлять запросы в DOM и если это происходит во время постройки DOM, результат может оказаться непредсказуемым.
document.write() — функция-наследие, которая может сломать страницу самым неожиданным образом, поэтому лучше её не использовать, даже если браузеры будут её поддерживать. По этим причинам в браузерах были разработаны хитрые методы обхода проблем с производительностью, вызванных блокированием скриптов, о них чуть ниже.
А что с CSS?
JavaScript приостанавливает парсинг HTML, т.к. скрипты могут менять страницу. CSS не может изменить страницу, поэтому причин останавливать процесс парсинга у него нет, так?
Из-за этого CSS может блокировать парсинг в зависимости от порядка подключения скриптов и стилей на странице. Если внешние таблицы стилей находятся до скриптов, то создание DOM и CSSOM может мешать друг другу. Когда парсер доходит до скрипта, постройка DOM не может продолжаться до тех пор, пока JavaScript не выполнит скрипт, а JavaScript в свою очередь не может быть запущен, пока CSS не скачается, распарится и CSSOM станет доступным.
Ещё один момент, о котором не стоит забывать. Даже если CSS не будет блокировать постройку DOM, он блокирует процесс рендеринга. Браузер ничего не покажет пока у него не будет готовых DOM и CSSOM. Это потому, что зачастую страницы без CSS непригодны для использования. Если браузер покажет кривую страницу без CSS, а потом через мгновение полную стилизованную страницу, то у пользователя возникнет когнитивный диссонанс.
У этого явления есть название — Проблеск Неоформленного Содержания, сокращённо ПнОС [Flash of Unstyled Content или FOUC]
Во избежание таких проблем нужно как можно быстрее предоставить CSS. Помните золотое правило «стили сверху, скрипты снизу»? Теперь вы в курсе почему это важно!
Назад в будущее. Спекулятивный парсинг
Приостанавливание парсера при каждой встрече со скриптом будет означать задержку в обработке остальных данных, подгружаемых в HTML.
Раньше, если взять несколько скриптов и изображений, подгрузив их, например, так:
Процесс парсинга выглядел бы как показано ниже:
Такое поведение изменилось в 2008 годах, когда IE представил так называемый «опережающий загрузчик» [the lookahead downloader]. С помощью него файлы подгружались в фоновом режиме прямо во время выполнения скриптов. Вскоре этот метод переняли и Firefox, Chrome с Safari, используя его под разными названиями, равно как и большинство современных браузеров. У Chrome с Safari это «предварительный анализ» [the preload scanner], а у Firefox — спекулятивный парсер. Идея вот в чём, с учётом того, что постройка DOM во время выполнения скриптов весьма рискованна, можно всё ещё парсить HTML чтобы посмотреть какие ресурсы должны быть подгружены. Затем обнаруженные файлы добавляются в очередь на загрузку и скачиваются параллельно в фоновом режиме. И к моменту завершения скрипта, необходимые файлы могут быть уже готовы к использованию.
Таким образом с применением такого метода, процесс парсинга выше, выглядел бы так:
Такой процесс называется «спекулятивным», иногда «рискованным», потому что HTML всё ещё может меняться во время выполнения скрипта (напомню про document.write ), что может привести к работе проделанной впустую. Но несмотря что такой сценарий возможен, он крайне редок, именно поэтому спекулятивный парсинг даёт огромный прирост производительности.
В то время как другие браузеры загружают таким способом только привязанные файлы, парсер Firefox ещё и продолжает строить DOM во время выполнения скриптов. Плюс этого в том что если спекуляция прошла, то часть работы в постройке DOM уже будет проделана. А вот в случае неудачной спекуляции работы будет затрачено больше.
(Пред)загрузка
При использовании такой техники загрузки можно значительно повысить скорость загрузки и никаких специальных навыков для этого не понадобится. Но если вы веб разработчик, то знание механизма спекулятивного парсинга поможет использовать его по максимуму.
Различные браузеры предзагружают различные типы ресурсов. Все основные браузеры обязательно предзагружают следующие:
Количество файлов, которые могут быть загружены параллельно, ограничено и варьируется от браузера к браузеру. Это ещё зависит от множество факторов, таких как скачиваются ли файлы из одного сервера или из разных, используется протокол HTTP/1.1 или HTTP/2. Чтобы отрендерить страницу как можно быстрее, браузеры используют сложные алгоритмы и скачивают ресурсы с разными приоритетами, зависящие от типа ресурса, местоположения на странице и состояния самого процесса рендеринга.
При спекулятивном парсинге, браузер не запускает inline JavaScript блоки. Это означает, что если подгружать файлы в скриптах, то они наверняка окажутся последними в очереди на загрузку.
Поэтому это очень важно упростить задачу браузера при загрузке важных ресурсов. Можно, например, вставить их в HTML теги или перенести скрипт загрузки в inline и как можно выше в коде страницы. Хотя иногда требуется наоборот, загрузить файлы как можно позже, т.к. они не столь важные. В таком случае, чтобы спрятать ресурс от спекулятивного парсера, его можно подключить как можно позже на странице через JavaScript. Чтобы узнать больше о том как оптимизировать страницу для спекулятивного парсера, можно пройти по ссылке MDN руководства [на русском].
defer и async
Но скрипты выполняющиеся последовательно остаются проблемой. И не все скрипты действительно важны для пользователя, такие как скприпты аналитики, например. Идеи? Можно загружать их асинхронно.
Атрибуты defer и async были придуманы специально для этого, чтобы дать возможность разработчикам указать какие скрипты можно загружать асинхронно.
Оба этих атрибута подскажут браузеру, что он может продолжить парсить HTML и в тоже время загрузить эти скрипты в фоне. При таком раскладе, скрипты не будут блокировать постройку DOM и рендеринг, в результате чего, пользователь увидит страницу ещё до того, как все скрипты загрузятся.
Разница между defer и async в том, что они начинают выполнять скрипты в разный момент времени.
Где бы они не были указаны, скрипты с async загружаются с низким приоритетом, зачастую после всех остальных скриптов, без блокирования постройки DOM. Но если скрипт с async загрузится быстрее, то его выполнение может заблокировать постройку DOM и все остальные скрипты, которым только предстоит загрузиться.
Замечание: атрибуты async и defer работают только для внешних скриптов. Без параметра src они будут проигнорированы.
preload
async и defer прекрасно подходят если вы не паритесь о некоторых скриптах, но что делать с ресурсами на странице, которые важны для пользователя? Спекулятивные парсеры полезны, но подходят только для горстки типов ресурсов и действуют по своей заложенной логике. В целом, нужно загружать CSS в первую очередь, потому что он блокирует рендеринг, последовательные скрипты должны всегда иметь приоритет выше чем асинхронные, видимые изображения должны быть доступны скорее и есть ещё шрифты, видео, SVG… короче говоря, всё сложно.
Как автор, вам лучше знать какие именно ресурсы важны для рендеринга страницы. Некоторые из них часто погребенны в CSS или скриптах и браузеру придётся пройти сквозь дебри пока он хотя бы до них доберётся. Для таких важных ресурсов теперь можно использовать <link rel=»preload»> чтобы подсказать браузеру загрузить файл как можно скорее.
Все что требуется написать это:
Список того, что можно загрузить весьма велик и атрибут as скажет браузеру, какой именно контент он загружает. Возможные значения этого отрибута:
Шрифты, пожалуй, самый важный элемент для загрузки, который спрятан в CSS. Шрифты необходимы для рендеринга текста на странице, но они не будут загружены пока браузер не удостоверится что именно они будут использованы. А эта проверка происходит только после парсинга и применения CSS и когда стили уже применены к вершинам DOM. Это происходит достаточно поздно в процессе загрузки страницы и как правило приводит к неоправданной задержке рендеринга текста. Этого можно избежать, использовав атрибут preload при загрузке шрифтов. Одна деталь на которую стоит обратить внимание при предзагрузке шрифтов, это то, что нужно устанавливать атрибут crossorigin, даже если шрифт находится на том же домене.
В данное время возможности предзагрузки ограничены и браузеры только начинают применять этот метод, но за прогрессом можно следить тут.
Заключение
Браузеры это сложные существа, которые эволюционируют с 90-х. Мы разобрали некоторые причуды из прошлого равно как и новейшие стандарты в веб разработке. Эти рекомендации помогут сделать сайты приятнее для пользователя.
Если вы хотите узнать больше о работе браузеров, то ниже пара статей, которые могут быть вам интересны:
4 отчета Яндекс.Метрики, о которых все знают, но которыми не все пользуются
Разберем по порядку некоторые отчеты Яндекс.Метрики и возможные последствия игнорирования возможностей, о которых все знают, но мало кто пользуется.
Отчет «Мониторинг – Время загрузки страниц»
Часто сайт грузится долго. Даже если вам, владельцу сайта, кажется, что быстро. А посетители уходят, не дождавшись загрузки.
Когда основная угроза – потеря потенциального клиента, не стоит полагаться на субъективное мнение. Нужно всего лишь открыть актуальный отчет и посмотреть на действительность в цифрах.
Отчет «Мониторинг – Время загрузки страниц» позволяет по каждой странице сайта увидеть такие важные параметры, как время до отрисовки (сколько времени пользователь видел пустой экран), время ответа сервера, время загрузки страницы.
Такой отчет дает данные с точностью до миллисекунды. Но настолько точный показатель нужен не всегда. Ведь очевидно, что чем быстрее грузится сайт, тем лучше – потенциальный пользователь быстрее увидит необходимый контент.
Время до загрузки DOM – это время от начала перехода на страницу до полной загрузки страницы со всеми ее компонентами: изображениями, CSS, скриптами и многим другим. Часть таких компонентов пользователь видит, некоторые из них являются служебными, и обычный юзер «пощупать» их не может. Наиболее оптимальная скорость загрузки сайта составляет 1–2 секунды. Увеличение этого времени прямо пропорционально проценту отказа, иными словами, вероятности ухода пользователя с сайта до его полной загрузки. Пороговым значением для высокого процента отказов является время в 15 секунд. Все, что грузится дольше – малоэффективный программный продукт.
Значимую роль, как базовая составляющая отчета, играет и время, потраченное на отработку запросов к DNS в процессе загрузки страницы. Данный показатель отмечен в отчете как «DNS». Кстати, значения с нулевым временем не учитываются по умолчанию.
Качественно сделанный сайт загружается быстро, не заставляя посетителя ждать. Постоянный контроль этого отчета и внесение изменений в работу сайта сделает ваш ресурс и, как следствие, вас более дружелюбными по отношению к потенциальным посетителям.
Отчет «Мониторинг – Результаты проверки»
Продолжает начатую выше историю отчет «Время загрузки страниц».
Если сайт не загружается дольше 10 секунд и эта ситуация повторяется из раза в раз, приравнивая «сейчас» к вечности, проблема может быть в низкой эффективности работы веб-сервера, который принимает запросы пользователей при клике на страницы вашего сайта и выдает им информацию в виде отрисованных страниц в браузере. Ждать загрузки вечно никто не будет, а вам, возможно, стоит задуматься о смене сервера.
В рассматриваемом отчете наиболее частый код ответа сервера «No response received after 10 s». Это означает, что от веб-сервера не получено ответа в течение 10 секунд. Одной из причин этого может быть перегруз сервера и, как следствие, его неспособность быстро обработать запрос. «Internal Server Error» и вовсе может говорить о сбое в работе программного обеспечения сайта. Появление подобных кодов ответа в отчете еще раз сигнализирует о низкой скорости загрузки анализируемого ресурса.
Отчет «Технологии – Браузеры»
Кто-то любит «Яндекс», кто-то пользуется исключительно «Google Chrome». На вкус и цвет, как известно, все карандаши разные. Многие владельцы сайтов любят мерить аудиторию сайта по себе. «Я вот, например, пользуюсь/не пользуюсь Яндексом/Хромом/Мозиллой и т.д.», – слышим мы почти от каждого клиента.
Выводы стоит делать не по своей субъективной оценке, а на основе информации из отчетов. Чаще всего, субъективное мнение далеко от реальности.
Именно поэтому категорией отчетов «Технологии – Браузеры» не стоит пренебрегать. Ведь в разных браузерах (и их версиях) сайт может выглядеть и загружаться совершенно по-разному.
Часто некорректное отображение сайта влияет на число обращений и показатели вовлеченности:
Как видите, в некоторых браузерах показатели вовлеченности заметно проигрывают. Почему? Откройте, протестируйте, посмотрите Вебвизор, что именно не так. В нашей практике был случай: в нескольких браузерах сайт клиента не вмещал на экране кнопку «Оставить заявку» в каталоге. Пользователи уходили с сайта, так и не находя возможности сделать заказ из каталога. А наш клиент ежедневно терял долю возможных обращений. Диагностировать ошибку, допущенную разработчиками сайта, помог именно отчет по браузерам.
Отчет «Технологии – Устройства»
Около 60% пользователей ищут нужную информацию в интернете через мобильные гаджеты – смартфон или планшет. Оперативно узнать, с каких именно устройств посетители заходят на страницы сайта, позволяет отчет «Технологии – Устройства». Благодаря ему можно вовремя диагностировать и устранить проблему некорректного отображения или функционирования сайта с мобильных устройств. Например, если показатель отказов с мобильных и планшетов выше, чем с десктопа – с мобильной версией вашего сайта явно что-то не так, стоит протестировать, что заставляет пользователей уходить со страницы? Ведь чем эффективнее сайт будет работать с каждого типа устройств, тем выше будет отдача.
Все рассмотренные выше отчеты не только можно, но и нужно комбинировать, фильтровать признаки для рассмотрения более узких разрезов пользовательского поведения. Скорость загрузки сайта с мобильных устройств, работа сайта в разных браузерах и на разных устройствах – это, конечно, уже момент «дошлифовки». Для начала необходимо проверить и периодически контролировать показатели базовых отчетов.
Яндекс постоянно предлагает новые фичи для удобства пользователей и рекламодателей. Не стоит пренебрегать возможностями, который придумали для вас, особенно если это касается контроля технического состояния работы интернет-ресурса. Ни одна самая крутая рекламная кампания не спасет сайт, загрузки которого не дождаться.
Как скорость загрузки сайта влияет на эффективность его продвижения
Ещё в апреле 2010 г. Компания Google объявила, что фактором ранжирования теперь считается и время загрузки страниц веб-сайта.
Спустя два года и «Яндекс» официально признал, что учитывает этот показатель, в систему веб-аналитики «Яндекс.Метрика» были добавлены и инструменты по анализу.
ПС стараются не пускать в топ «нерасторопные» сайты в интересах пользователя, который не хочет (и не должен) ждать.
За последние 5 лет средний размер веб-страниц вырос втрое, а за последний год – в полтора раза. Характерное время ожидания составляет 4 секунды. Если за это время сайт загружается у 90 % пользователей, вы счастливый владелец быстрого интернет-ресурса.
Основное время при загрузке страниц сайта уходит на клиентскую часть. Серверные затраты малы, 50 — 500 мс. Среднему пользователю всё равно, сколько страница будет создаваться на сервере, если работать с ней можно уже через полсекунды. В этом случае фокус смещается на клиентскую, а не серверную оптимизацию.
Под скоростью загрузки страницы понимают совокупность параметров:
DOM – это объектная модель документа (Document Object Model), структура, используемая браузером для представления данных. Проще говоря, это время от начала перехода на страницу до полной загрузки страницы со всеми её компонентами (тексты, таблицы, изображения, CSS, скрипты и т. п.). Значение субъективно воспринимается посетителем как «качество» или «скорость» страницы.
Оценить эти показатели можно в стандартном отчёте «Яндекс.Метрики» – «Время загрузки страниц»
Время до отрисовки и время до загрузки DOM в отчёте «Яндекс.Метрики»
«Время до отрисовки» характеризует хостинговую составляющую и скорость обработки DNS-запроса.
«Время до загрузки DOM» — качество веб-проекта: совместимость сайта с браузерами, скорость работы сайта на стороне браузера, размер загружаемых объектов, объём и качество кода. Если сайт собран на «студийной» CMS сайт не тестировался на полную совместимость с наиболее распространёнными браузерами, не удивляйтесь, если он начнет «прорисовываться» некорректно и с задержками.
Чтобы определить недостаточно оптимизированные с точки зрения скорости загрузки страницы сайта, нужно в фильтре колонки «Время до загрузки DOM» установить условие «Показать страницы с временем загрузки более 4 секунд».
Скорость загрузки страниц сайта. Определение «самых задумчивых» страниц сайта в отчёте «Яндекс.Метрики».
Аналогичный функционал заложен и в сервисе Google PageSpeed Insights для разработчиков.
Google PageSpeed Insights
Существует ряд независимых от ПС сервисов, измеряющих скорость загрузки:
Мы рекомендуем для анализа скорости загрузки сайта и дальнейшей оптимизации использовать встроенные в системы веб-аналитики «Яндекс» и Google-отчёты.
Конечно, стоит прислушаться и к мнению «сторонних экспертов», но прежде всего интернет-проект должен понравиться ПС. Внешние же сервисы просто необходимы для сравнения «скорострельности» вашего сайта с сайтами конкурентов в топе. Не имея доступа к счётчикам «Яндекс.Метрика» и Google Analytics, получить эту важную информацию можно только «на стороне». Нужно помнить, что методика сбора данных сторонними сервисами может существенно отличаться, результатом будут некорректные выводы и рекомендации для разработчиков по оптимизации скорости загрузки.
Итак, аудит проведён, запаздывающие документы выявлены. Что дальше: как увеличить скорость загрузки сайта?
Приступаем к выполнению чётко регламентированного алгоритма действий, который включает следующие этапы:
Минимизация кода происходит за счёт удаления избыточных пробелов, табуляций, переносов строк, комментариев, дублирующегося кода. Минимизация применима к коду HTML, CSS и JS и, в зависимости от размера и содержимого кода, достигает результатов, близких к gzip-сжатию – уменьшать файлы до 20–30 % от исходного размера. При использовании ещё и gzip-сжатия предварительная минимизация увеличивает степень сжатия в среднем на 3–5 %. Используя gzip-сжатие, важно убедиться в том, что процедура отключена для изображений и других двоичных файлов. Поскольку эти файлы уже сжаты, а их размер существенно превышает размеры типичных текстовых файлов, применение gzip-сжатия не принесёт никакого выигрыша в клиентском быстродействии веб-страниц, зато увеличит нагрузку на сервер.
- 1. Оптимизация изображений
За счёт использования подходящих графических форматов и сжатия без потерь суммарный объём страницы уменьшается до 50 % и более. Изображения, полученные с фотоаппаратов или сохраненные в некоторых графических редакторах, содержат массу дополнительной информации (метаданные, избыточная цветовая палитра и пр.). Существует несколько графических форматов, поддерживаемых современными браузерами: PNG-8, PNG-24, JPEG, GIF. Каждый из них позволяет получить значительный выигрыш в размере. Вот наглядный пример, где видна проведённая оптимизация графики средствами Adobe Photoshop без потери качества, позволившая в 4,5 раза сократить исходный объём файла с 904 до 203 кБайт:
Результаты оптимизации графики для web
Для полноцветных изображений с богатой цветовой палитрой (фотографий, сложных градиентов и т. п.) следует использовать формат JPEG высокого качества. Помните, JPEG – это формат сжатия с потерями, и чем выше степень сжатия, тем большее число артефактов появится на итоговом изображении.
В случае, когда для верстки требуются полупрозрачные изображения, используется формат PNG-24, поддерживающий альфа-каналы.
Для изображений с ограниченной палитрой применяем PNG-8. Этот формат, как и GIF, позволяет использовать прозрачность, но в большинстве случаев превосходит GIF. Достигается это за счёт более совершенной методики сжатия, которая охватывает и горизонтальные, и вертикальные повторения, а также адекватно работает с градиентами.
Единственным кросс-браузерным форматом, который отображает анимацию в изображениях, является GIF. Хотя уже в ближайшем будущем ему составит конкуренцию развивающийся APNG.
Устранение избыточного кода
Для уменьшения размера кода применяются способы вёрстки, требующие минимум тегов HTML и правил CSS. Так, семантическая вёрстка с применением независимых блоков предпочтительна по отношению к вёрстке вложенными таблицами с использованием тегов. Избыточного кода в CSS можно также избежать, приняв стандарт отображения типовых элементов на веб-страницах, таких как заголовки, параграфы, списки, ссылки и т. д. Один раз определив стиль оформления ссылки и параграфа, больше не придётся описывать для каждого нового блока.
- Устранение встроенного в разметку кода
Суммарный объём кода можно также сократить за счёт устранения встроенного на веб-странице CSS и JS- кода. Множество атрибутов style=”” в HTML-тегах можно заменить за счёт использования классов единственным, общим для всех элементом – селектором, а множество javascript-обработчиков (например, обработчиков onclick=””, onmouseover=”” и др.) – одним единственным обработчиком. Изменить вёрстку и JavaScript (логику) в подобных ситуациях, как правило, не сложно.
Нередко на веб-страницах присутствует некоторое количество неиспользуемого кода, находящегося как непосредственно в HTML-документе, так и во внешних файлах. Время загрузки этих страниц увеличивается на время загрузки неиспользуемых внешних файлов из сети или из кэша браузера и на время, необходимое для разбора всех элементов DOM-дерева и CSS-правил, которые могут быть к ним применены. В случаях, когда размер веб-страницы и файлов ресурсов измеряется в сотнях килобайт, задержка становится существенной. Если в файлах CSS и JS, подключаемых на веб-странице, объем кода относится исключительно к другим страницам, его перераспределяют по нескольким файлам, подключая их на страницах по необходимости.
Старайтесь отказаться от использования фреймов. При невозможности совсем отказаться от них, минимизируйте количество. Среди минусов фреймов: избыточные запросы к серверу, блокирование события onload, а также затруднения при поисковой индексации и сохранении адресов и состояний веб-страниц. Использование фреймов, как правило, оправдано только тогда, когда требуется безопасно вставить блок стороннего содержимого, например рекламный. Можно избежать применения фреймов благодаря разумному использованию серверных скриптов и техник AJAX.
Уменьшить количество запросов к серверу можно за счёт минимизации количества вызовов CSS-файлов. Оптимальное количество таких вызовов – не более двух на страницу. Не подключайте на каждой веб-странице все использующиеся на сайте CSS-файлы. Пусть тот код, который нужен на ограниченном числе страниц, вызывается только на них.
На странице часто подключается несколько файлов JavaScript. Уменьшив их количество, можно увеличить итоговую скорость загрузки страниц. Код JS объединяется в одном файле, загруженном и кэшированном единожды. Это решение сработает, если кода JavaScript на сайте немного (до 100 килобайт в сжатом виде). В ситуации, когда сайт представляет собой сложное веб-приложение и объем кода превышает 100–150 килобайт в сжатом виде, у объединения всего кода в одном файле будет отрицательная сторона: при запросе первой страницы пользователь будет загружать часть кода, которую мог бы не загружать вовсе.
Популярные решения для того, чтобы повысить скорость загрузки сайта на самых распространенных движках, в том числе на базе CMS WordPress – системы управления сайтами, на которой работает каждый 3–4 сайт в мире:
Направление кэширования востребовано среди разработчиков плагинов для WordPress. Достаточно ввести запрос «Cache» в разделе «Плагины» —> «Добавить новый», и вашему вниманию предстанет выдача из 3323 виджетов. Есть из чего выбрать!
Следующий момент – это адаптивная вёрстка сайта. Сегодня во всех нишах растёт доля пользователей с мобильных устройств. Ни в коем случае нельзя пренебрегать этой частью аудитории. Сайт должен быть удобен, понятен и решать задачи пользователя не только на декстопах. По нашей статистике, сегодня 70–75 % сайтов, приходящих в работу по SEO-продвижению, не имеет адаптивной версии. В оставшейся части «передовых» проектов мобильная версия есть, но её эффективность и конверсионность оставляет желать лучшего с точки зрения «заточенности» на выполнение бизнес-задач клиента и позитивного опыта взаимодействия посетителя с площадкой.
Если сайт не адаптирован к мобильным устройствам, то успех SEO-продвижения сомнителен!
Обращаясь в агентство по продвижению сайтов, поинтересуйтесь, как будут работать с сайтом в плане улучшения скорости работы, доступности и удобства для мобильных устройств. Сразу при специалистах пройдите Google PageSpeed Insights Test, распечатайте полученные результаты теста скорости загрузки и перечень рекомендуемых Google улучшений. Это станет отправной точкой в процессе работы подрядчика, а вы сможете пару раз в месяц отслеживать, выполняются ли выданные поисковиком рекомендации и стал ли сайт больше нравиться Google в плане технической грамотности и скорости работы.
В заключении хочется еще раз подчеркнуть, что низкая скорость загрузки страниц сайта – это один из мощных факторов, отрицательно влияющих на ранжирование сайта в поисковой выдаче. Длительное время загрузки замедляет процесс сканирования и индексирования и снижать конкурентоспособность сайта в десктопном и в мобильном поиске, тем самым увеличивая бюджет на SEO и снижая эффективность продвижения.