Продуктивність css селектор - веб-розробка - блог корисних статей про розробку і розкручування

Продуктивність css селектор - веб-розробка - блог корисних статей про розробку і розкручування
Сьогодні, за часів готових рішень, бібліотек, фреймворків, препроцесорів і безлічі інших, безсумнівно корисних в умілих руках, інструментів, для великого числа розробників механізми технологій залишаються чорним ящиком. Я не буду занудою і не скажу, що кожен повинен зрозуміти технологію зсередини, оскільки індустрія також вимагає низькокваліфікованих робітників рук, зокрема «нарізувачів макетів». Я так само не буду грати в Капітана Очевидність - зрозуміло, що це принципово важливо, якщо ви плануєте стати професіоналом. Робіть ваш вибір самі.

Як обробляється CSS
Стиль елемента застосовується при його створенні
Ми сприймаємо сторінку як єдину «картинку», з оформленням і контентом. Але браузери обробляють документи поступово, потоком. Як тільки браузер починає отримувати документ з сервера, він починає його обробляти, не чекаючи повного завантаження. Кожен вузол обробляється і промальовується у вікні браузера після отримання. Розглянемо простий документ.

Потім браузер зустрічає елемент div з id = "content". І знову, в цей момент він вважає елемент порожнім. Браузер обчислює стилі і елемент промальовується на екрані. Браузер потім визначає, чи потрібно перемалювати body - наприклад, чи став він ширше або довше (зміна геометричних розмірів - найбільш частий ефект впливу нащадка на батька)?

Процес триває до досягнення кінця документа.

CSS селектори читаються справа наліво

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

Якщо у вас є, скажімо, правило div # content p . тоді для кожного елемента, в момент його обробки браузером, спочатку буде перевірятися, чи є елемент параграфом. Якщо він є таким, тоді браузер піде вгору по DOM дереву і перевірить, чи є div з id = "content". Якщо умова вірна, тоді браузер продовжить пошук body.

Такий принцип роботи обраний не випадково. Браузер визначає чи варто застосовувати стильове правило до елементу на момент промальовування значно швидше. Чим менше вузлів потрібно обійти, тим швидше обробляється правило.

Хороші і погані селектори
Погляньте на рекомендації Google Page Speed. Вони виділили чотири, на їх погляд, найбільш повільних селектора:

Слід дати деякі пояснення до використання вищевказаного. Як бачимо, ці хлопці нам кажуть, що використаних складових селекторів - зло, що сповільнює ваш інтерфейс, отже треба використовувати тільки прості селектори (наприклад, елементу, ID, класу, атрибута і т.д.). Однак ці правила не повинні бути прямим керівництвом до дії, інакше можна дійти до абсурду і повернутися за часів

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

Кажуть, універсальний селектор можна використовувати, тому що він дуже повільний. Нісенітниця собача! Він повільний тільки в складі контекстного селектора, наприклад #content p *. Сам по собі не гірше селектора елемента, класу або id.

замість висновку
А взагалі кажучи, так чи важливо на практиці дотримуватися цих, далеко не очевидним, правилам? Навіщо тоді вся решта армія селектор, якщо тру-селектори можна перелічити на пальцях однієї руки? Як я вже згадував, в усьому повинен бути баланс, заснований на здоровому глузді. Чому б не заощадити пару-трійку сотень мілісекунд, якщо це нічого не коштує! Однак буде божевіллям витрачати на це годинник розробки і тестування.
У той же час, помічали ви коли-небудь на сторінках з новомодними приклеюють шапками і колонками гальма? Це результат великої часу, який необхідний на перемальовування при скролінгу сторінки.