Повышаем производительность и скорость загрузки сайта простыми способами

⁃ почему важно думать о скорости загрузки
⁃ разбираемся что такое time to interactive
⁃ изучаем основные этапы загрузки сайта
⁃ влияние скорости загрузки на прибыль
⁃ оценка first contentful paint при помощи инструмента lighhouse
⁃ практика
Повышаем производительность и скорость загрузки сайта простыми способами
Урок посвящён в первую очередь параметру First Contentful Paint.
Исходные файлы, используемые в уроке находятся в репозитории github.com/stu...
Практическая часть с 9:50
Используемые в ролике статьи и ресурсы:
httparchive.or...
httparchive.or...
/ the-cost-of-javascript...
/ a-pinterest-progressiv...
hnpwa.com
developers.goo...
sandbox.imgix....
developer.mozi...
developer.mozi...
Для запуска статических файлов использовался сервер simplehttp2server:
github.com/Goo...

[@kovaldn]

Друзья, как вам ролик Ивана? Будем приглашать ещё на LoftBlog?

[@Artiomkane]

На скорости х2 отлично 👌

[@stylenova1]

Хочу продолжения!!!!

[@dlaik]

да, отличный контент

[@kuzmit4a]

Да обязательно приглашайте )

[@verba1690]

слишком много слов паразитов, аж слух режет

[@seoonlyRU]

лукас от СЕООНЛИ - вебмастера и сеошника-братишки

[@loading.express]

Классный ролик! Спасибо.

[@DozusCook]

Как зовут парня ИВан полное имя ? Как с ним связаться ?

[@777Vasya77]

Очень годный контент! Спасибо!

[@alekseivlasov2467]

хорошо спасибо, теперь увидеть быть лайфхак по теме WordPress, желательно с drag & drop плагинами( Unyson, Elementor, Visual Composer и тд) , а не стандартной темой.

[@seintero]

Вот, поддерживаю! На мой взгляд адекватных мер опимизации визуальных генераторов контента wp - нет. Только кеш. На практике для особо упёртых клиентов приходилось ПОЛНОСТЬЮ перевёрстывать страницы, выкидывая блоки и эл-ты шаблона, заменять пресловутый революшен слайдер. Хотелось бы услышать чьё-то экспертное мнение

[@kuzmit4a]

Ещё пожалуйста видео по оптимизации, очень понравилось.

[@SeoquickUa]

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

[@valeevadward]

Очень здорово! Спасибо!

[@GambitVil]

Да, очень годные рецепты!

[@schmit2611]

Как открыть эту сучью КОНСОЛЬ?! Почему множество этапов не объясняется, а просто делается и не комментируется доходчиво. Урок Обалденный! Но блин, у меня горит от такого! Подскажите. как. включить. консоль. лайтхайус?

[@iamname8758]

Гугл в помощь

[@ЕфимЗуев-н4я]

Очень круто!)

[@clickabelno]

Лайк за интересный полезный контент

[@aftereffects-7483]

спасибки за видосик! а как тоже самое сделать с магазином на OPENCART? но там скрипты тормозят(((

[@demimurych1]

Общее: *установка LightHouse* непонятно зачем ставить отдельно LightHouse если он есть всегда сейчас в любом Google Chrome браузере. Даже если предположить, что в каждом браузере на свете он был выпилен из Dev Tools, метрики FMP FCP и прочие являются частью стандарта W3С www.w3.org/TR/navigation-timing/, и все современные браузеры поддерживают это api которое дает все эти цифры без LightHouse. Фактически Lighthouse сейчас, это оболочка вокруг Performance api. *советы LightHouse* Те советы, которые пишутся под заголовком Возможности, например используйте Nextgen форматы изображений, это советы которые остались с эпохи PageSpeed. Соответственно они не имеют вообще никакого прямого влияния на метрики. О чем гугл написал сереньким шрифтом "Эти рекомендации могут помочь вам ускорить загрузку страницы. Они не влияют на показатель производительности напрямую." Некоторую практическую пользу имеют сообщения из области Диагностика. Но они для человека который не занимается этой темой, чаще всего не имеют никакого практического значения. *Time to first byte* ttfb не имеет никакого серьезного влияния на метрики LightHouse, и является официально deprecated. По причине того, что эта метрика может равняться минимальному значению на любом проекте при условии что системный администратор или программист понимают чем они занимаются. А именно, нет никакой необходимости в ожидании когда весь проект софрмируется кодом, чтобы что то отправить в поток. То есть обозначить TTFB равным времени пинга. Когда до программистов LightHouse это дошло, хотя им говорилось это ни раз с самого начала, ttfb был переведен в рамки метрик не имеющих никакого влияния на LightHouse НО даже тогда, когда ttfb имел прямое влияние на оценки, это влияние было на уровне 5%. Иными словами, если ваш первый байт был в рамках 5 секунд можно было вообще ничего не делать с этой метрикой. *TTI Time to interactive* 4:25 эта анимация не имеет почти ничего общего с тем что оценивает TTI. Да, изначальная мысль этой характеристики была именно в этом, но компьютер не умеет оценивать это так как оценивает человек. Потому у этой характеристики есть строгие параметры: если после отметки о FMP возникающее событие будет обработано не позднее чем за 50мс, то это время и есть TTI. И это время ну вообще не то что показано на гифке. TTI может быть отмечен когда в области отображения вообще не будет ничего вменяемого. *TTI и блокировка* На TTI никакой разблокировки основного потока не происходит. Вообще никакой блокировки потока не происходит - откуда это взято докладчиком мне интересно узнать. Event Loop той машины которая отвечает за работу JS в браузере никаким особенным образом не блокируется ни до TTI ни после. Возможно докладчик имеет ввиду, что у него после события TTI сайт становится вменяемо отзывчивым, но это не значит что TTI тому причина или что-то что может это характеризовать. TTI измеряет только то что я сказал выше. Это значит что перед ним типичный сайт который сначала пытается загрузить все и запустить все что бы сайт начал работать. Естественно в этом случае TTI совпадет с моментом когда вся эта куча разрешиться бременем. НО это не значит что TTI возникает всегда в этом время. *FMP First Meaningful Paint* 6:35 действительно является самой важной метрикой, по причине того, что все прочие метрики напрямую зависят от решения проблем этой. В большинстве случаев решив проблему FMP никаких других телодвижений делать уже не нужно, так как это автоматически уменьшает значения других метрик. Повторюсь, я на любом проекте могу продемонстрировать TTI в зеленой зоне и это не даст почти никакого положительного влияния для проекта в целом. 13:00 характеристики сети не имели никакого значимого влияние на FCP. Я понимаю что интуитивно каждому видится это именно так, но проблемы интуиции в том, что она опирается на ваш же опыт, которые не имеет ничего общего с тем какие задачи решает LightHouse.

[@demimurych1]

*Аналитика в шапке* 15:05 Имеет критическое значение только в одном случае, если вы формируете правила работы Tag менеджера и аналитики через инрфейс. Если вы используете API которое предоставляет аналитика, то наличие Аналитики в шапке не окажет влияния более чем на полтора бала в минус. Другое дело что при использовании аналитики через их API наличие ее в шапке тем более бессмысленно. Правильно говорить, что если у Вас нет возможности разобраться в этом API и при этом потери в точности в пределах 10% для Вас не критичны, то можно смело перенести активацию аналитики к закрывающему тегу body. *Опять байки про TTFB* 17:55 Да пришел запрос, да сервер подумал. Но с чего вы взяли что кто то обязан ждать отработки всего кода проекта чтобы вернуть первый байт? Первый байт может быть послан сразу же как только произошло рукопожатие. Даже еще интерпретатор вашего уютного php не запустился а уже можно получить TTFB. Именно поэтому TTFB не имеет НИКАКОГО практического ВЛИЯНИЯ на метрики LightHouse *PWA Progressive Web App* 16:05 Несмотря на всю ту чушь которую несет маркетинг гугла, PWA это обычный сайт, который отличается только наличием файла manifest.json. ВСЕ. До появления слова PWA и возможности прилепить иконку на рабочий стол, сайты могли делать ВСЕ что делает сейчас PWA. От управляемого кеширования посредством сервайс воркеров, до работы в автономном режиме. Не говоря уже о том, что установка иконки в телефон лаунчером уже была задолго до PWA кажется в 2 Iphone. *Дальше* Дальше смотреть смысла никакого нет, потому что докладчик не понимает смысла того что делает так и по причине того что по сути он решает вопрос запуском сторонних программ. Как итог, нужно было просто рассказать про то как их запускать, а не грузить людей ненужной информацией тем более той, в которой сам пока плаваешь. *Для сравнения* Тот шаблон что в видео, человеком который понимает что он делает "оптимизируется" в ручную ( без использования сторонних утилит) до 90+ баллов за 10 минут.

[@ЧайСлимоном-ж7к]

Спасибо за комментарий. Попробую ответить. > непонятно зачем ставить отдельно LightHouse если он есть всегда сейчас в любом Google Chrome браузере. Как отдельная утилита он гораздо удобнее и точнее. Также это возможность всегда использовать последнюю версию. > не имеют вообще никакого прямого влияния на метрики тут не соглашусь. Длительность загрузки изображений вполне себе влияет. Особенно если изображение блокирует основной поток документа. > ttfb не имеет никакого серьезного влияния на метрики LightHouse он так или иначе косвенно связан с другими метриками. Ну и на пользовательский опыт влияет безусловно. > TTI Time to interactive соглашусь, что программная оценка TTI довольно сильно плавает и зачастую может выбиваться из реальности > Вообще никакой блокировки потока не происходит тут не соглашусь. Блокировка основного потока - это основа основ. developer.mozilla.org/en-US/docs/Glossary/Main_thread web.dev/mainthread-work-breakdown/ > Повторюсь, я на любом проекте могу продемонстрировать TTI в зеленой зоне и это не даст почти никакого положительного влияния для проекта в целом. да, и не только так, в целом множество метрик можно подогнать под зеленую зону. Оценки до сих пор не идеальны, даже с web vitals. Хотя с web vitals конечно стало посложнее.

[@demimurych1]

​@@ЧайСлимоном-ж7к *Длительность загрузки изображений* >> _не имеют вообще никакого прямого влияния на метрики_ > _тут не соглашусь. Длительность загрузки изображений вполне себе влияет. Особенно если изображение блокирует основной поток документа_ Скажу иными словами, возможно так моя мысль будет понятнее В настоящий момент, даже изображения, размер которых измеряется мегабатйми никак прямо не повлияют на метрики. Они могут повлиять косвенно, на равне с любыми другими причинами. Иными словами, если вы путем оптимизации изображения, изменил его обьем и это положительно сказалось на вашгих метриках, то виноват в этом не процесс вашей оптимизации, и не то что вы изображение сделали меньше, а соврешенно иная причина, которая была компенсирована вашими дейтвиями. Одну из причин Вы назвали сами - синхронная и асинхронная обработка изображений. Так в этом виновато не само изображение, а то что человек который готовил верстку страницы некомпетентен, и не владеет современными средствами работы с разметкой, где добавление простого decoding="async" решают проблему чуть более чем полностью. Конечно в этом есть и доля передергивания, которую я допускаю намеренно чтобы переломать людям из неверное восприятие этих метрик. Например, если то же изображение своим обьемом будет в дестяки мегабайт, то сам факт его декодирования и рендеринга, косвенным образом за счет потребеления сумасшедших обьемов памяти и процессорного времени, естественно будет причиной плохой производительности. Но опять же подчеркну, если мы это делали сознательно - то есть нам надо было именно такое изображение влепить в поток. Но не само изображение в этом виновато. Обратный пример, мы своим javaScript кодом, заблокировали рендер и нагрузили процессор по все его ядра. Вот тут вот - вина целиком и полностью на JavaScript со всех точек зрения. *он так или иначе косвенно связан с другими метриками* >> _ttfb не имеет никакого серьезного влияния на метрики LightHouse_ > _он так или иначе косвенно связан с другими метриками. Ну и на пользовательский опыт влияет безусловно_ Не несите чуши. Время первого байта никак не связано ни с какими метриками. Почему? Потому что время отправки и фиксации тестом первого байта вообще не связано с сайтом как таковым, а связано с тем насколько компетентен системный администратор, который конфигурировал сервисы железки. И слава яйцам бегимота, это наконце дошло и до людей продавливающих спецификацию. Говоря иными словами, я вам на любой машине почти в любых условиях сделаю ttfb равной пингу. Из чего следует, что опираться на эту метрику бессмысленно, по причине того что она не отражает реальной картины. То что Вы привыкли думать про первый байт как про нечто, что связанно с реальной работой, оптья же подчеркиваю, связано со сложившимися паттернами конфигурирования серверов. Когда отправка первего байта просиходит после работы интерпретатора или еще бог знает чего. Но при этом никто не запрещает мне сделать так, чтобы я отправил первый байт сразу после пакета CON *Блокировка основного потока - это основа основ* >> _Вообще никакой блокировки потока не происходит_ > _тут не соглашусь. Блокировка основного потока - это основа основ_ Мой ответ был исключительно в рамках TTI, а не о Main Thread вообще. Это мне кажется достаточно очевидным, в рамках того, о чем я писал в комментариях. Рассуждать о подобных вещах и не знать как устроен цикл обработки событий в современном JS было бы невозможно. *в целом множество метрик можно подогнать под зеленую зону* >> _Повторюсь, я на любом проекте могу продемонстрировать TTI в зеленой зоне и это не даст почти никакого положительного влияния для проекта в целом_ > _да, и не только так, в целом множество метрик можно подогнать под зеленую зону._ Я пытался сказать, что в случая ttfb tti опираться на их замеры ни в коем случае нельзя, потому как манипулировать значением этих временных меток можно соврешенно не влияя на производительность. При этом есть объективные вещи, например DomContentLoaded или window.load уменьшение которых *любыми средствами* приведет к реальному изменению восприятия рендера проекта. Если я, искутсвенным путем, сделаю так, что оба эти события возникнут намного раньше чем при работе того же проекта без моих манипуляций, я в любом случае создам у пользователя ощущение того, что что-то очень быстро произошло. Даже если на экарне будет каша. И от этого в любом случае будет польза. В отличии от метрик ttfb с tti которыми можно эффективно манипулировать без каких либо реальных полсдествий для проекта. И как я уже заметил, слава великому ктулху, это удалось донести до тех кто отвечает за стандарт и за эти метрики в Google, потому как их либо исключают либо меняют их значимость на общую интегрированную оценку

[@simongreyse4171]

Видео начинается с 20:00

[@prostorcrimea]

Спасибо за ролик и за то, что поделились знаниями! Подскажите, пожалуйста, не будет ли ругаться на данные модификации валидатор HTML?

[@НиколайГрубляк-х9п]

AWESOME!!!

[@nurtaza_daniyal]

Почему то при критическом CSS оценка ниже на pagespeed но выше только performance на lighthouse что делать

[@СветланаЗабродина-х8е]

Больше информации по ускорению сайтов на OpenCart здесь neoseo.ru/google-page-speed-opencart, также можно получить и консультацию.

[@igorkroshkin9354]

я про CDN не понял... ГДЕ и КАК ЭТО подключать? Сколько стоит?

[@ЧайСлимоном-ж7к]

Я так понимаю вопрос про imgix.com CDN для изображений. У неё стоимость 3 доллара в месяц за 1000 загруженных картинок + 8 центов за 1гб трафика. Это также не единственная CDN - другие альтернативные можно поискать при помощи запроса вроде "image cdn". CDN использовалась лишь для упрощения демонстрации работы с изображениями. Есть и другие варианты, например можно сделать несколько разных размеров изображения и использовать тег developer.mozilla.org/ru/docs/Web/HTML/Element/picture medium.com/front-end-weekly/html-picture-tag-in-practice-png-and-webp-formats-5a3fc51b5998 Или при работе с background-image воспользоваться media queries stackoverflow.com/a/16961944/1038433

[@igorkroshkin9354]

@@ЧайСлимоном-ж7к так может быть И НУЖНО БЫЛО показать, как ЭТО сделать? А не рекламировать непонятно что? Я никого не осуждаю, меня просто бесит недосказанность

[@ЧайСлимоном-ж7к]

@@igorkroshkin9354 не думаю что одна из крупнейших CDN для изображений, которую используют такие компании как reddit, coursera, kickstarter - нуждается в моей рекламе)) В ролике я просто продемонстрировал, как можно решить вопрос с изображениями при помощи такого рода CDN. Т.е. задачи именно заставить вас проходить регистрацию на imgix у меня не было. Разумеется существуют и другие способы, но к сожалению у меня не было достаточно времени чтобы разобрать всё за один раз. Приму вашу критику к сведению.

[@ivanegorov6065]

@@igorkroshkin9354 Мне кажется, что про тег более чем емко написано на MDN. Ну а подключение разных картинок медиазапросами так вообще фундаментальная вещь. А вот про CDN я не знал.

[@Zyamilon]

На скорости 1,5 норм смотреть.

[@odincivilizationvi3083]

9 минут бесполезной инфы, нужно тебе выпустить ролик как повысить производительность и скорость выпускаемой тобой информации

[@iGotton]

+

[@advokats086]

ВСЕ ЭТИ CMS -- ЭТО ДЛЯ СЛАБАКОВ... НАДО РУЧКАМИ ПИСАТЬ САЙТ.. И БУДЕТ ВАМ СЧАСТЬЕ... НЕТ ЖЕ БОЛЬШИНСТВО WORDPRESS УСТАНОВИТ И ДУМАЮТ, ЧТО УСЕ...