Поздрави, скъпи читатели! Днес бих искал да подчертае въпроса за оказване на уеб разработки. Разбира се, тази тема е автор на много статии, но ми се стори, че цялата информация е доста фрагментиран и по еднакъв начин. Най-малкото, за да се събере цялата картина в ума си и да разсъждаваме върху него, аз трябваше да се анализират много информация (най-вече - на англоговорящите). Ето защо реших да се формализират своите познания в една статия, и да споделят резултата с Habra общност. Мисля, че тази информация ще бъде полезна както за начинаещи уеб разработчици и по-опитен, за да опресните знанията си и структура.
Тази тенденция може и трябва да бъде оптимизиран в етап оформление / фронтенд-развитие, тъй като е очевидно, че за маркиране, стилове и скриптове предприемат, за да направи пряко участие. За да направите това, съответните специалисти трябва да знаят някои от тънкостите.
Браузърът на обработка на WEB-страница
Да започнем с това, помислете за последователността на браузъра, когато се появява в документа:
- образувана DOM (Document Object Model) от север от получения HTML-документ.
- Зареден и призната стилове, образувана CSSOM (CSS Модел Object).
- И въз основа на CSSOM на DOM дърво рендиране формира или да направи дърво - набор от оказване на предмети (Webkit използва термина «рендер», или «окаже обект» и Gecko - «рамка»). Render дърво дублира структурата на DOM, но това не се получи невидими елементи (като например - . или елементи със стил дисплей: няма; ). Също така, всеки ред от текста е представена в дървото рендер, като отделен модул за рендиране. Оказване на всеки обект съдържа подобно DOM обект (или текстов блок) и изчислена за този обект стил. Казано по-просто, направи дърво описва визуално представяне на DOM.
- За всеки направи дърво елемент изчислява позиция на страницата - има оформление. Браузърите използват метод поток (поток), като в повечето случаи само един пасаж за настаняване на всички елементи (за маси изискват повече преминавания).
- И накрая, има рисунка на всичко това в браузъра - живопис.
В процеса на взаимодействие на потребителите със страницата и изпълнението на скрипта, той се променя, което изисква повторно изпълнение на някои от посочените по-горе дейности.
Ще се пребоядиса (или restyle) - В случай на промяна на елементите стил, които не засягат неговия размер и позиция на страницата (.. например, фон-цвят граничен цвят видимост), браузърът трябва само да го прави отново, като се вземат предвид новия стил.
Ако промените засягат съдържанието на структурата на документа, позицията на елементи - настъпва конвекторна (или relayout). Причините за тези промени обикновено са:
- Манипулирането DOM (добавяне, изтриване, модификация, пренареждане на елементи);
- Смяна на съдържание, включително текст в полетата на формуляра;
- Изчислителните или промяна на CSS имоти;
- Добавяне, изтриване стилове;
- Манипулации с атрибута «клас»;
- Манипулирането на прозореца на браузъра - преоразмеряване, превъртане;
- Активиране на псевдо-класовете (напр. Hover).
Оптимизация от браузъра
Браузъри възможно локализират пребоядисване и преформатиране в клетките, насочени от промяната. Например, промяна на размера или фиксирана абсолютно разположен елемент засегне само елемент и неговите потомци, а промяната на позицията на статиката - ще доведе до преформатиране на всички елементи, които го следват.
Въпреки това, както е описано по-горе, позоваването на свойствата на елементите ще доведе принудително конвекторна. Това означава, че ако ние сме в горния блок на код, ще добавят призив към елемент собственост, това ще доведе до допълнително преформатиране:
В резултат на това, ние получаваме 2 преформатиране вместо един. Поради това, позоваване на свойствата на елементите, като е възможно да бъдат групирани на едно място, за да се оптимизира производителността (вж. По-подробен пример за JSBin).
Но на практика, има ситуации, когато не се принуждават да правим без преформатиране. Да предположим, че имаме задача на елемента, който искате да се прилага една и съща собственост (вземе «марж-наляво") за пръв път без анимация (набор до 100 пиксела), а след това - чрез анимиран преход към стойността на 50px. Можете да видите веднага примера JSBin. но аз ще го нарисува тук.
За да започнете да zavedom преход клас:
След това се опитайте да се реализират замисленото, както следва:
Това решение няма да работи, както се очаква, тъй като промени се кешират и да се използват само в края на един блок от код. Ние ще спасителен принуден преформатиране, в резултат на кода ще придобие следния вид, и ще изпълни точно задачата:
Практически съвети за оптимизиране
Въз основа на този член, както и на други членове на Харб, която обхваща въпроса за оптимизиране на JS, можем да извлечем следните съвети, които ще бъдат полезни за създаване на ефективен фронтенд:
- Напиши валиден HTML и CSS, което показва, кодирането. Стилове включват по-добри . и скриптове - след .
- Трябва да се избегне сложни инвестиции селектори в CSS (това често виновни за разработчиците, използващи Препроцесорът). Също така, вместо етикети е по-добре да се използват класове или документи за самоличност. Също така, универсален за избор трябва да се избягва (*).
Надявам се, че всеки читател на статията привлече нещо полезно. Във всеки случай - благодаря за вниманието!
Свързани статии