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

В одному з попередніх дописів ми розглянули, що відбувається, коли HTML-документ потрапляє до бравзера. Серед цих етапів — парсинг і рендеринг. Якщо коротко, то парсинг це перетворення текстового представлення HTML на DOM, а рендеринг — це процес перетворення цієї структури на зображення у вікні переглядача.

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

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

Чому так? Бравзер припускає, що скрипт може змінити структуру документа. Наприклад, вставити щось через document.write() чи переписати DOM через innerHTML. Щоправда, нині деякі бравзери вдаються до speculative parsing, продовжуючи "паралельний" парсинг, готуючись до найгіршого, але сподіваючись на краще.

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

Запобігти цьому можна, використовуючи defer скрипти, які завантажуються в паралелі з парсингом, але виконують лише після завершення парсингу і, що найважливіше — після повної побудови початкового DOM.

Стилі ж блокують суто рендеринг. Чим більше у вас підключено різних стилів, чим більшою буде затримка, бо кожен з них бравзер оброблятиме окремо. Це потрібно для того, щоб перед рендером у бравзера вже був готовий CSSOM. З нього він будує Render Tree — і тільки тоді малює сторінку.

Якщо стилів багато — бравзер має завантажити їх усі, обробити й оновити CSSOM. Поки цього не станеться — рендер не почнеться. Завантаження відбувається в паралелі, але рендер не почнеться, доки не буде оброблено всі підключені стилі.

Також, якщо ви використовуєте @import, ви додаєте ще одну затримку до цього процесу, бо такі імпорти обробляються відкладено.

Тут в нагоді стане використання так званого critical path, коли найнеобхідніші стилі, які потрібні для побудови першого відображення, яке дозволяє користувачу вже взаємодіяти зі сторінкою, "вшивають" в сам HTML, тобто додають прямо в head.

І як вишенька на торті — шрифти. Так, шрифти теж блокують рендер, але у свій спосіб — якщо ваш шрифт вантажиться довго, то ви побачите саму сторінку, а от текст на ній не побачите. Це називається FOIT — Flash of Invisible Text.

Зарадити цьому можна в кілька способів. Можна використати font-display: swap, тоді текст відобразиться системним шрифтом, поки ваш красивий ще вантажиться.

Можна зробити передзавантаження шрифту через <link rel="preload" .../> в head (але без фанатизму). Це не позбавить цієї проблеми повністю, але дозволить суттєво знизити час очікування.

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

Найнепопулярніший, але найнадійніший спосіб же — не використовувати зовнішні шрифти. Але кому то цікаво в 2025 році?

🔗 Web Dev: First Contentful Paint
🔗 Web Dev: Render Blocking CSS
🔗 MDN: Optimizing JavaScript downloads

Та й таке. Щось з того практикуєте, чи покладаєтесь на хорошу погоду і стабільний інтернет користувача? Зізнавайтесь.

***
Якщо вам сподобався цей допис, то разом із вогником або серденьком до цього допису додати ще й кілька гривень донату на Mavic для 184 навчального центру. А якщо не сподобався, я це і так зрозумію. Дякую всім і цьом вам у лобіка.
https://send.monobank.ua/jar/AeXQ6YRf2X
5375411202918178

***
@babichdev

Товариство, початок публічної співбесіди React Native Junior уже за пʼять хвилин, не проґавте!

https://youtube.com/live/alIvA6pZ-nM

Я зазвичай не надаю фідбеків як таких на співбесіди на ютубі, для того є зазвичай експерти. Але чому б не спробувати?

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

Почну я з сильних сторін, які мені впали в око, і які варто виокремити:

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

Дуже чітка структура відповідей. Мені дуже сподобалось, що Вадим чітко пояснював свої думки, структуровано, не стрибаючи зі сторони в сторони, навіть попри те, що іноді уходив сторону. Але і це він робив теж послідовно. Тому ще раз і ще раз — вислухали запитання, подизхали носом, обдумали, а тоді відповідаєте, чітко побудувавши відповідь. Вам не обовʼязково відповідати багато. Вам треба відповідати чітко.

Відкритість та прийняття власних прогалин. Це один з дуже важливих критеріїв, які вирізняють (бодай для мене) класного фахівця від посереднього. Вадим ясно усвідомлює межі своїх знань і не намагався вигадувати відповіді, натомість прямо кажучи — "не знаю, але погуглю". Навчіться й ви визнавати, якщо чогось не знаєте. А ще краще — при цьому попросіть інтервʼюєра пояснити вам правильну відповідь. Заодно побачите який він вумний на ділі.

Звичайно ж, не обійдусь і без зауважень:

Відсутність уточнень у складних задачах — кілька разів Вадим одразу "влітав" у рішення, не поставивши жодного уточнюючого питання. Це може створити враження поспішності або поверхового підходу. Або й підставити вас, бо без уточнень ви можете завести відповідь в глухий кут.

Перевантаженість відповідей деталями — часто переходив у надмірне заглиблення в питання, що ускладнює фокус інтервʼюєра й демонструє слабке управління розповіддю. Моя особиста порада — завжди відповідайте на поставлене питання, давайте трохи глибини, але на керованому вами рівні. Тобто так, щоб інтервʼюєр поставив вам уточнююче запитання, на яке ви точно відповісте. Ви просто можете договоритися до речей, знання про які у вас можуть бути не дуже впевнені, а от я, наприклад, цим обовʼязково скористаюсь. Усе, що ви скажете, може і буде використано проти вас ;)

Темп і стиль комунікації — говорив надто швидко, без пауз. Я розумію, що це особливість характеру Вадима, але усе ж це може дещо заважати сприйняттю цілісної відповіді. А ще, відповідаючи неспішно, ви матимете нагоду краще обдумувати відповідь та наступні репліки. Проста штука, але багатьом стане в нагоді. Це не значить, що треба тягнути, як зажована касета, але неспішну відповідь усе ж легше сприймати на слух та аналізувати.

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

Тож дякую Вадиму за участь в співбесіді і глядачам за перегляди! А хто ще не подивився — не гайте часу і мерщій вмикайте собі запис етеру, хай і на тлі.

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

@babichdev

#думки_вголос
З кожним роком стає усе важче боротися з "гімно мале"-mentality. Ну тобто коли ти весь такий поважний і вкритий мохом дивишся на умовних 25-річних синьйорів і бухтиш собі під носа "ну який ти в сраку синйьор, ти ж жизні не видів, де там того синьйора взяти".

Проте накладати власний досвід на чужий — часто справа невдячна. Бо це я в 25 і на мідла не стягував, адже почав в 24. А якщо людина почала кар'єру в дев'ятнадцять років, і при цьому сумлінно працювала, в не тільки тасочки закривала, то чому вона не може здобути за цей час необхідний досвід? Може. І здобуде.

Так, це буде не такий багатий і насичений досвід, як у мене, до прикладу, але і я не два роки в розробці вже. Це лише питання часу.

І взагалі, чому мати дітей в 22 можна, а бути синьйором в 25 не можна? Отож.

Головне при цьому бути не "паперовим" синьйорами, і розуміти, що це не лише личка, в й відповідальність.

Гарних вихідних!

@babichdev

Жарт безсовісно спертий у @dobermanko

#css_in_action
Ну що, поцентруємо трошки div? У мене тут вчора в Threads попросили, то як я можу відмовити? А то все архітектури, гуд інаф коде. Одним словом, донт пуш зе хорсес, треба й ділом зайнятись. Тож…

ЦЕНТРУЄМО ГОРИЗОНТАЛЬНО
Margin

.el { 
  margin: 0 auto;
  width: ...;
}

Працює, коли елемент має обмежену ширину. Не працює для інлайнових елементів.

Для інлайнових блоків

.parent { text-align: center; }
.el { display: inline-block; }

Класичний спосіб для вирівнювання inline або inline-block елементів. Батьківський text-align впливає лише на інлайн-контент.

Flexbox

.parent {
  display: flex;
  justify-content: center;
}

Найстабільніший спосіб для X-центрування. Важливо памʼятати, що align-items за замовченням stretch, тому вертикаль може "роздувати".

Grid

.parent {
  display: grid;
  justify-items: center;
}

Просто, сучасно, стильно, молодіжно.

Absolute + transform

.el {
  position: absolute;
  left: 50%;
  // або
  inset-inline: 50%;
  transform: translateX(-50%);
}

100% надійність. Потрібен position: absolute|fixed. Підтримка inset-inline чудова у всіх сучасних бравзерах (навіть Safari).

justify-self

.el { justify-self: center }

Працює у Grid. Не працює в Flex (бо цим керує сам контейнер). Працює поза grid в блочних контекстах, але тільки в Chrome та Edge. Firefox і Safari цю поведінку ігнорують, сподіваюсь, тимчасово.

ЦЕНТРУЄМО ВЕРТИКАЛЬНО
Flexbox

.parent {
  display: flex;
  align-items: center;
  height: ...;
}

Працює за умови flex-direction: row. Важливо памʼятати, що потрібна висота контейнера, інакше нічого не відцентрується.

Grid

.parent {
  display: grid;
  align-items: center;
}

Просто, сучасно, стильно, молодіжно.

Absolute + transform

.el {
  position: absolute;
  top: 50%;
  // або
  inset-block: 50%;
  transform: translateY(-50%);
}

Це ж було вже.

align-self

.el { align-self: center; }

Працює поки лише всередині flex та grid. Всередині flex це вертикально, якщо flex-direction: row, якщо це column, то вирівнювання буде по горизонталі. Очікується підтримка в блочних контекстах.

Table-cell

.parent {
  display: table-cell;
  vertical-align: middle;
}

Дідівський спосіб, не позбавлений недоліків. Багатьох недоліків.

ЦЕНТРУЄМО ЦЕНТРАЛЬНО
Flexbox

.parent {
  display: flex;
  align-items: center;
  justify-content: center;
  height: ...;
}

Один із найнадійніших способів. Потрібна висота в контейнера.

Grid

.parent {
  display: grid;
  place-items: center;
}

Найменше коду. Повна підтримка. Але потрібен grid.

Absolute + transform

.el {
  position: absolute;
  top: 50%;
  left: 50%;
  // або
  inset: 50%;
  transform: translate(-50%, -50%);
}

Найнадійніший варіант з абсолютним позиціонуванням. inset — скорочений запис для top/right/bottom/left усіх разом. Боже, як я мріяв колись про цю властивість…

place-self

.el { place-self: center; }

Працює тільки всередині grid. Поза ним — частково підтримується в Chromium, але не в Safari чи Firefox.

---
Ну от якось так можна відцентрувати div в липні місяці 2025 року. Можливо ви знаєте ще якийсь чудернацький спосіб, то обовʼязково розкажіть про нього в коментарях. До речі, приєднуйтесь до чату, як іще будемо ділитися глупими мемами про джаваскрипт?

MDN: CSS Box Alignment Module Level 3

@babichdev

#про_співбесіди
Сир, сирок і race condition
Ви шукаєте "сирок", а бачите "сир". Ні, це не випадок в "Сільпо", а цілком собі питання на технічному інтервʼю.

Я практично повністю відмовився від запитань в дусі "Що таке Х?" на співбесідах, як комерційних, так і публічних. Натомість перейшов до так званих "ситуаційних" завдань, коли я просто описую якусь ситуацію, в рамках якої можна проговорити кілька різних аспектів — і технічних, і не тільки.

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

Отже, питання:

У вас є табличка з пошуком, і якщо в пошуку спочатку набрати "сир", а потім швиденько дописати "-ок", то таблиця усе одно відображатиме список і сирів і сирків. Чому так може бути?

Відповіді, звичайно, я отримую доволі різноманітні, проте серед найчастіших є одна умовно невірна, і одна — вірна.

Умовно невірна — це щось там з кешуванням даних, те, як ми обробляємо запити, додаємо дані в стейт менеджменті і так далі. Чому вона для мене умовно невірна? Бо заскладна. Вона містить забагато припущень, про які зазвичай попередньо мова не йде, і може призвести до каскаду нових запитань, до яких ви можете бути не готові.

А умовно правильна — дуже проста і очевидна, бо в питанні йде мова про race condition при запитах. Це доволі поширена ситуація, особливо якщо запити відбуваються в умовах нестабільного або повільного зʼєднання.

Схема проста: запит на “сир” пішов першим, але довго обробляється. Тим часом користувач встиг дописати “-ок”, і запит на “сирок” пішов другим — але відповів швидше. У результаті інтерфейс спочатку показує правильний список, а потім перезаписується старішою, але пізнішою відповіддю. Особливо легко це проґавити, якщо показується лише один індикатор завантаження.

Рішення саме цієї задачі надзвичайно просте — необхідно скасовувати попередні запити при відправці нових. Зазвичай для цього використовується AbortController.

А для заохочення автора писати цікаві дописи зазвичай використовуються вподобайки

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

До речі, дехто з вас може згадати і про debounce, але конкретно в цій задачі він теж недоречний. В самій ситуації, яку я використовував на співбесідах, він, до речі, фігурує, але за дещо інших умов.

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

Запамʼятайте — прості рішення простіше обґрунтовувати, а ускладнити їх завжди можна встигнути. А от якщо ви відразу зайдете зі складного, то, швидше за все, просто закопаєтесь на місці.

Тож, якщо ваш колега знову "пакращить" відповідь на інтервʼю — покажіть йому цей кейс ;)

До речі, чи були у вас випадки на співбесідах, коли ви на просте питання давали занадто кучеряву й складну відповідь? Діліться смачненькими фейлами!

@babichdev

#нове_відео
Хто такі синьйори?

Цей подкаст чекав на свій зірковий час ще із січня, і ось нарешті ви маєте змогу послухати, як ми з Нікітою Галкіним розбираємо тему, що давно потребувала відвертої розмови. Що таке синьйорність? У чому вона проявляється? Як не сплутати її з фреймворковою експертизою? І що взагалі чекає після?

Ходіть дивитися і приємного перегляду!

Хто такий Senior Software Developer? | Подкаст з Нікітою Галкіним

І не забудьте поширити це відео серед усіх родичів і знайомих.

Зловив ) Дякую!

#про_співбесіди
У мене вчора трошки пригоріло від одного допису в Threads. Якщо коротко: історія про співбесіду, де кандидат класно відповідає на питання, розповідає кейси, і взагалі повний метч. Але аж тут, при завершенні тімлід раптом питає: "А що більше, 5² чи 2⁵?' Кандидат розгубився, просить калькулятор. І висновок мене вбив: "Це не про математику. Це про базову уважність, реакцію, спокій під тиском."

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

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

У мене величезне прохання до усіх, хто проводить співбесіди — ніколи, за жодних обставин, не ставте такі питання, якщо вони ніяким чином не повʼязані з темою інтервʼю. Ваші питання повинні нести цінність для вас, а відповіді на них мають розкривати потенціал кандидата саме в робочих обставинах.

Завжди питайте себе — "Що я хочу дізнатися у відповідь на це питання?". Дуже чітко окреслюйте цю мету. Якщо це "дізнатися, як кандидат думає", то оце "думає" має бути в конкретному робочому контексті, а не абстрактне "в загальному". А ще частіше питайте себе "Як я особисто відповім на це питання, і як цю мою відповідь можна буде тлумачити?".

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

Підсумовуючи, залишу просто дуже влучну цитату з коментарів: "В гуглі всі знають, чому люки круглі, але чомусь досі пишуть код з null exception".

Все, ніби випустив пару. Не будьте душні, одним словом.

@babichdev

Товариство, хто хоче стати зіркою наступної співбесіди на ютубі? Яка, до речі, відбудеться наступної пʼятниці, 1 серпня.

Заповнюйте анкету і хапайте нагоду попозоритись показати свої знання в прямому етері!

https://forms.gle/T8SKFTpuCbY1vK8E6

Чекаю на ваші заявки до вечора неділі. Всім гарного вечора пʼятниці!

#партнерський_допис
Товариство, а ви чули? ШІ стукає в наші таски! І як він змінить роботу фронтенд-розробників у найближчі роки — говоримо на панельній дискусії appflame talks!

📅 31 липня, 18:00–20:00, онлайн
Спікери з appflame, WIX, Softsich. Модератор — щиро ваш Бабіч.
Ця подія — і для розробників і тімлідів, які хочуть розуміти, куди рухається індустрія.

Поділимося практичними кейсами та інструментами, що варто використовувати вже сьогодні!

🔗 Реєстрація: http://bit.ly/4lszyfW

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

Одним зі способів подолати цю проблему є фіксування розмірів елементів зображень, наприклад, задаючи в HTML width та height. Однак, якщо у вас адаптивний дизайн, і картинки мають динамічні розміри, цей підхід просто не спрацює.

І тоді людство згадало про так чудову річ, як пропорції, і почало "резервувати" місце під зображення, поки сам файл вантажиться. Найнадійнішим способом тривалий час був так званий padding-top hack — коли за допомогою внутрішнього відступу, абсолютного позиціонування і такоїто матері вдавалось таки забезпечити сталі пропорції. Але якою ціною?

<div class="box">
  <img class="fixed-ratio">
</div>

<style>
.box {
  position: relative;
  width: 100%;
  padding-top: 56.25%; /* 9 / 16 = 0.5625 → 56.25% */
  overflow: hidden;
}

.fixed-ratio {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
}
</style>

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

Як і будь-який хак, цей підхід має свої плюси і мінуси. Мінусів зазвичай більше. Я не буду заглиблюватися в них, але таку конструкцію дуже легко вивести з ладу: тут тобі і overflow: hidden, і неявна висота, і абсолютне позиціонування.

Хто не поставить серденько — втратить доступ до каналу через 3… 2… 1…

Однак давно вже можна забути про спадщину часів IE, та користуватися нормальними підходами в CSS, а в нашому випадку властивістю aspect-ratio, яка робить рівно одну річ — задає елементу потрібні пропорції, до того ж в очевидний спосіб.

.fixed-ratio {
  aspect-ratio: 16 / 9;
}

Можна задати й по старому, одним значенням, якщо вам дуже подобається знущатися над колегами:

.fixed-ratio {
  aspect-ratio: 1.77777778;
}

А, що ще важливо — очевидно, що aspect-ratio працює для усіх блочних елементів, не лише для зображень.

Частиною Baseline ця властивість є з вересня 2021 року, а це означає, що ви можете спокійно використовувати її у ваших продакшн-проєктах. Якщо ви досі не пишете під IE, звичайно.

Для себе я цей підхід відкрив приблизно у той же час, але використовував доволі обережно, зазвичай у пет-проєктах, але зараз підтримка сучасних CSS-фіч пришвидшилась, тож уже немає сенсу триматись за хаки

🌐 MDN: aspect-ratio

А ви як, слідкуєте, аби ваші сторінки не цибали вверх-вниз, як дикі гібони, чи покладаєтесь на волю богів та швидкий інтернет у юзера?

@babichdev

Товариство, хочу вам нагадати, що триває збір на Mavic для 184 навчального центру.

І ще хочу нагадати, що Росія — кончена країна кончених людей. Якщо, звичайно, вам не вистачає її власних нагадувань.

Дякую за кожну гривню.

***
На Mavic для 184 навчального центру

🎯 Ціль: 80 000 ₴

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178