👨‍💻#WebPerf - про терміни (1)👨‍💻

Коли ми говоримо про #перформанс (або швидкодію), бажано розуміти, "а про що конкретно ми о це розмовляємо". Бо видів швидкодії може бути щонайменше два:

➡️ Швидкодія завантаження. Простими словами, як довго ваш користувач бачить білий екран або екран без корисного контенту.

➡️ Швидкодія рантайму. Це коли сайт вже завантажився, ми щось натискаємо, а інтерфейс починає пропускати кадри ("лагати"), або взагалі перестає відповідати на дії користувача.

І І то і то є швидкодія. Але незважаючи на це та на те, що вони між собою частково пов'язані - причини проблем, а найголовніше шляхи до вирішення будуть, у своїй більшості, відрізнятися.

@reactbeginners

👨‍💻#WebPerf - користь швидкодії завантаження (2)👨‍💻

❓Якщо користь швидкодії рантайму досить очевидна (ніхто не буде користуватися застосунком який зависає), то зі швидкодією завантаження все не так очевидно. Здавалося б, що немає особливої різниці скільки ваш сайт/застосунок завантажується. Дві, три, чотири секунди - яка різниця? Але насправді це не так.

😅 Як виявилось, існує кореляція між часом завантаженням та відсотком людей, які залишають ваш сайт не дочекавшись завантаження. Що, в свою чергу, впливає на продажі або на покази реклами.

👉 Іншими словами - швидкодія завантаження напряму впливає на ваш дохід або дохід вашого клієнта. Наприклад Trainline, зменшивши час очікування усього на 300мс збільшив прибуток на 8_000_000 фунтів стерлінгів на рік.

Але перед тим, як переходити до оптимізацій завантаження, спочатку потрібно розібратися з тим, як це завантаження взагалі відбувається.

@reactbeginners

🎉А ми на DOU🎉

😎 Телеграм не дуже підходить для розлогих текстів, тому про наші пригоди з другою версією курсу я написав невеличку статтю на DOU. Кому цікаво як ми готувались до другої версії курсів і побачити трохи фотографій - прошу до читання. Пишуть що це займе аж дві хвилини 😂

👉 А якщо коротко - то я більш-менш (десь на 80%) задоволений тим що вийшло. Дуже підгадили рашисти з відключенням світла, але прогрес нашої групи був наочний. Можливо трохи постраждала якість відео записів але довелось жертвувати.

✍️ З висновків - підхід з окремою групою був правильний, але групу взяли завелику. Наступна буде, нажаль, меншою. Вибачайте :(

❤️ Дякую всім хто прийняв участь, дивився наші відео, писав коментарі та ставив лайки. Ви молодці, ви круті, і я вірю що всі ви знайдете свою роботу мрії.

Бережіть себе і скоро побачимось.

П.С. Скоріше за все я і сам в найближчий час відправлюсь на трьох тижневе навчання.

👨‍💻#WebPerf - як браузер вантажить ресурс (3)👨‍💻

Для того, щоб завантажити будь-який ресурс (HTML, CSS, JS, тощо) потрібно зробити наступні кроки

➡️ Знайти сервер

Коли ви пишете в браузерному рядку https://drag13.io , браузер ніц не знає що це за адреса і куди звертатися. Для того щоб це дізнатися, він робить запит до сервісу доменних імен для отримання IP адреси вашого серверу (я тебе по айпі знайду!!!)

➡️ Встановити з ним зв'язок

Після того як браузер дізнався адресу серверу, з ним треба вийти на зв'язок (можливо сервера там давно й немає немає) і, якщо у нас з'єднання захищене (https), то ще й помінятися сертифікатами

➡️ Запитати в нього ресурс і почати отримувати відповідь

Якщо сервер живий і відповідає, браузер надсилає йому запит за конкретним ресурсом (наприклад index.html) і очікує на передачу даних. Сервер, в свою чергу, шукає в себе ресурс і віддає його (або не віддає) і ще робить купу інших речей (наприклад логує)

➡️ Обробити ресурс

Дані, які ми отримуємо з сервера є "сирими" і часто стиснутими. Тому браузеру потрібно їх розпакувати та перетворити на щось корисне. Так HTML перетворюється на спеціальну структуру в пам'яті - DOM, CSS на СSSOM, JS - перетворюється з літер на код який зрозумілий браузеру. Важливо, що "ціна" обробки а також можливість оброблення під час завантаження залежить від виду ресурсу.


➡️ "Виконати" ресурс

І тільки тепер ми можемо "виконати" ресурс - відмалювати HTML, накласти стилі, виконати JS.

От такий шлях потрібно пройти кожному ресурсу який вантажить наш браузер для того що б ви побачили корисний контент. І як ви вже розумієте, на кожному етапі з цих етапів щось може піти не так...

@reactbeginners

Схема завантаження абстрактного ресурсу

@reactbeginners

Живий приклад того, як перші два кроки займають 600мс.

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

👨‍💻 #WebPerf - що ж може піти не так (4)👨‍💻

➡️ Знайти сервер

Коли браузер шукає сервер, перше що він робить це шукає його у себе. Якщо ви вже відвідували цей сайт - проблем не буде, відповідь буде майже миттєва. Якщо ж в кеші адреса не знайдеться, браузер піде на DNS сервер. Якщо і там нічого не буде - запит піде далі до наступного DNS серверу, аж поки не дійде до кореневих серверів. Як ви розумієте - на це потрібен час

Рішення: розмістити DNS записи на спеціалізованих серверах. Наприклад заплатити Cloudflare які обіцяють відповідь на DNS запит за 11ms замість 60-150ms. І так є ті хто платять за ці 50ms різниці.

➡️ Встановити з ним зв'язок

Після того як ми знайшли адресу бажаного серверу - настав час "знайомитись". Ця процедура називається handshake і передбачає певну кількість запитів-відповідей. Проблема тут полягає в тому, що якщо сервер живе десь у Болівії, а ви у Києві, то на це може піти значно більше часу, ніж ви очікували через банальну фізику процесів.

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

➡️ Запитати в нього ресурс і почати отримувати відповідь

Тут найбільшою проблемою є завантаженість (ну і також відстань). Якщо ваш сервер виконує певну роботу (CPU limit), або відправляє велику кількість відповідей (Network limit), або написаний через вухо бобра і синхронно логує запити до відправки даних - потрібно розвантажувати сервер.

Рішення - масштабування, кешування або знову таки CDN. Все аби розвантажити вас сервер. Тут, до-речі, економія може йти на 500+ ms на кожен ресурс, що досить суттєво

➡️ Обробити ресурс

Кожен ресурс має свою "ціну" за обробку. Для когось ця ціна маленька (наприклад HTML), а для когось досить велика - як раз наш улюблений JS. Саме тому, бюджетні мобільні телефони дуже довго відмальовують сайти з великою кількістю JavaScript. Вони його швидко отримують, а "прожувати" їх слабенький CPU не може.

Ще одна проблема полягає в тому, що не всі ресурси можна парсити під час завантаження. HTML, наприклад, можна, а от JS ми змушені чекати до самого кінця (вгадайте чому)

Рішення - зменшувати обсяг ресурсів. Викидати зайві ліби, "трясти дерева", зменшувати розмір зображень і таке інше.

➡️ "Виконати" ресурс

Якщо ви покладете на початку документу код накшталт while(true){}, то всі ваші попередні оптимізації виявляться просто непотрібними - потік виконання буде заблокований і контент ви не побачити ніколи. Це саме стосується і інших ресурсів.

Тому єдине рішення тут - писати адекватний код і використовувати ресурси розумно.

Отже ми з вами розібрали спрощену теорію завантаження окремого ресурсу. Але є маленький нюанс - в реальному житті м майже ніколи не завантажуємо лише один ресурс

😅Давайте розбавимо перформанс React-ом!😅

😎 Вчора я обіцяв невеличкий сюрприз, тож виконую обіцянку: ми підготували для вас 15 хвилинне відео-огляд Storybook - універсальний та корисний інструмент для документації та тестування UI компонентів.

👉 Він популярний, часто використовується на проектах та кросфреймворкний (яке жахливе слово), тому раджу навіть початківцям.

Приємного перегляду та бережіть себе!

💰Ми допомогли ССО💰

💰 Ваші кошти та трохи моїх, загалом 5_000 гривень, поїхали на авто для ось цих хлопців.

🧑‍🦰 Волонтера, яка їм допомагає, моя родина знає особисто. Лариса допомагає військовим з 2014 року і, можливо, ви навіть бачили її відео де вона з подругою, під час поїздки, потрапляє під обстріл на машині і при цьому співають.

🚗 Зараз вони їздять (особисто!) на нуль майже кожен тиждень і я маю сказати, що таку мужність та силу духу має далеко не кожний, тож допомога їм це однозначно добра і дуже корисна справа!

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

Магазин на React - код рев'ю: 24 січня о 19:00

😎 Ми таки обрали проект для код рев'ю. Ним став невеличкий магазин з Redux та Apollo написаний в якості тестового завдання. Добро від власника коду вже отримано, тож сподіваюся що цього разу буде без "нюансів".

🧑‍💻 Код ми обирали за критерієм складності (щоб була помірна) та типових помилок (щоб було всім корисно). Тож якщо ваш проект не попав на ефір то, можливо, саме через брак помилок 😉

👉 А сам ефір відбудеться вже у вівторок, 24 січня о 19:00 годині, тож усіх запрошую.

Бережіть себе і скоро побачимося.

Прямий ефір сьогодні ввечері о 19:00

❗️Наш прямий ефір, під час якого ми, разом з Сергієм, будемо робити код рев'ю наживо почнеться менше ніж за 5 годин

👩‍🏫 Будемо говорити про структуру проекту, роботу з даними, та типові проблеми які можуть виникнути в будь-якому проекті. А ще там є GraphQL!

Приходьте, буде цікаво!

В голосуванні можна обирати кілька опцій!

🤫Змінні оточення та секретні секрети на прикладі React за 10 хвилин🤫

🕺Підготував для вас невеличке, до 10и хвилин, відео про те, навіщо потрібні змінні оточення, як їх використовувати та як НЕ зберігати секретні дані в коді.

👉 Якщо ще не стикалися з цим - дуже раджу подивитись, в майбутньому однозначно стане в нагоді. Якщо дивитись немає часу - просто запам'ятайте, що секретні дані зберігати в коді не можна.

Бережіть себе і скоро побачимось!

Аналітика від DOU та корисні ресурси

🥊 DOU опублікував аналітику про найми джунів і вона не дуже втішна, бо конкуренція лише росте.

👉 Тому не можу не порадити канал з вакансіями для початківців (які і нам дуже допомогли) - Don't Panic Junior IT Jobs

😊 Там є різні вакансії, в тому числі для фронтів + всілякі корисні матеріали саме для джунів. Зайдіть, подивіться, можливо стане в нагоді. Нажаль зараз треба пробувати все

❗️А ще - вчіть англійську. Це суттєво підвищує ваші шанси знайти роботу. Наразі, ITVDN пропонує безкоштовний онлайн курс англійської для IT. Англійська дуже важлива, вона відкриває вам величезний ринок.

Бережіть себе і скоро побачимось!

Новий ефір та розіграш цікавого подарунку

😅 Ну що, обіцяв то ж треба робити. Оголошую дату нового ефіру про #швидкодію завантаження на прикладі #React застосунку, який відбудеться в суботу, 11 лютого о 14:00. Поговоримо про те як міряти, що міряти та поексперементуємо на тестовій апці.

❗️ Окрім цього я також хочу розіграти один цікавий подарунок - книгу про історію незалежності України яку мені подарували за виступ на конференції в 2022 році. Ця книга для мене цінна тим, що вона є символом втілення мрій незважаючи ні на що. Тож я віддаю її з відчуттям гордості (і зовсім трошки з сумом 😁)

❗️Для того щоб прийняти участь у розіграші потрібно зробити ТРИ РЕЧІ:

👉 перерахувати на 4731185629296887 суму кратну 100грн (кожні 100 грн - один шанс)
👉 написати мені в особисті ім'я та суму
👉 прийти на ефір 11.02.23

❓А гроші підуть на обладнання для Покровського госпіталю у прифронтовій зоні. Перші 5000 я вже відправив, бо чекати немає часу, але їм потрібні ще і, нажаль, багато.

Бережіть себе і скоро побачимось.

👨‍💻 #WebPerf - Як міряти швидкодію завантаження? (5)👨‍💻

👉 Якщо потрібно оцінити загальну картину "на око":

1. Відкриваємо анонімне вікно
2. Відкриваємо бажану сторінку та відкриваємо Chrome Developer Tools
4. Переходимо на вкладку LightHouse
5. Обираємо лише Performance чекбкос
6. Натискаємо Analyze і записуємо рейтинг.
7. Повторюємо все ще два рази і виводимо середнє значення.

➕З плюсів - це швидко та більш-менш зрозуміло - якщо результат 90+ то скоріше за все (але це не точно) у вас все добре, робити нічого не потрібно.

➖З мінусів - це не надійно. Навантаження на проді не стабільне, тому цифри що ви бачите зараз можуть відрізнятися від тих, що бачить ваш замовник, або те, як насправді поводить себе застосунок у ваших користувачів. Ще один мінус - не зовсім зрозуміло що ці віртуальні бали все ж означають. Бо вашого замовника, природно цікавлять не вони, а, наприклад, конверсія.

😎 Але незважаючи на це, такий підхід чудово підходить для самоконтролю під час розробки застосунку. Просто час від часу запускаєте LightHouse і пересвідчуєтесь що все в нормі. Якщо несподівано оцінка дуже впала - дивимось історію комітів. До-речі, раджу зберігати результати LighHouse звіту щоб мати змогу порівнювати як результати так і причини.

А от якщо вам потрібно більш грунтовний підхід, починається абсолютна інша історія...

П.С. Ми збираємо на гроші для Покровського госпіталю. Буду дуже вдячний за кожну гривню!

👨‍💻 #WebPerf - Все не так страшно(6)👨‍💻

❓Пам'ятаєте ефір з Сергієм Бабічем про верстку? Готуючись до наступного ефіру мені стало цікаво, а що зі швидкодією того мікросайту який створив Сергій.

😎 Я його стягнув, встановив parcel щоб не мучатися зі збіркою, вилив на Azure, щоб не дивитись локально і запустив LightHouse.

😉 Результат мене не здивував - 93, 93, 97. Все ж таки сайт повністю статичний, маленький та Сергій ще й трохи оптимізував деякі моменти (хоча бідкався що нєєє)

❓І тут мені стало цікаво - чи можна його значно покращити за лише одну принципову зміну

Через деякий час виявилось, що за одну зміну я можу стрибнути одразу до 99.

Як гадаєте - за рахунок чого? Пишіть ваші варіанти в коментарях!

Тут сайт,а тут код.

П.С. Ми продовжуємо збирати кошти на госпіталь, завтра буде додатковий приємний анонс.

🧐 А чому я так багато пишу про швидкодію?🧐

😀 Звичайно, тому ще мені це подобається, але існує й інша причина чому, на мою думку, ця тема може бути корисна вам

❗️Річ у тім, що робота зі швидкодією, дуже добре прокачує розуміння того, як працює браузер і як працює мережа. А це ті знання які необхідні фронтенд розробнику будь-якого рівня і які можуть стати вам у нагоді як під час розробки, так і під час співбесіди.

👉 Тож, якщо у вас є трохи часу - приділіть вашу увагу цій темі і вона не один раз стане вам у нагоді.

А тепер відповіді на вчорашні пости:

1. Єдина зміна - Critical CSS, тобто вбудова CSS, який необхідний для відображення сторінки, в саму сторінку. Важливо пам'ятати що це не панацея і може зробити навіть гірше, якщо розмір вбудованого CSS буде великим.

2. Переведення проекту з чистого HTML на React (без оптимізацій) знизило performance score з 94.3 до 87 на моїй машині. Але якщо брати дані з pagespeed.web.dev, то картина цікавіша: деградація з 85 до 61 на мобільному і 98 на 82 на десктопі. Така ціна React-у. У матеріалі для вимірювання була помилка. Коректні цифри будуть пізніше

Бережіть себе, новини про розіграш трохи пізніше.