스타일 계산의 범위와 복잡성 줄이기

Jeremy Wagner

Paul Lewis

JavaScript는 종종 시각적 변화를 유발합니다. 때로는 스타일 조작을 통해 직접 변경되거나, 때로는 계산을 통해 변경되기도 합니다. 데이터 검색 또는 정렬과 같은 시각적 변화를 초래합니다. 타이밍이 나쁘거나 오래 실행되는 JavaScript는 성능 문제의 일반적인 원인이 될 수 있으므로 가능한 한 그 영향을 최소화하는 방법을 찾아야 합니다

스타일 계산

요소 추가 및 제거, 속성 및 클래스 변경, 애니메이션을 재생하면 브라우저가 요소 스타일을 다시 계산하고 많은 경우 페이지의 일부 또는 전체의 레이아웃입니다. 이 프로세스를 계산된 스타일 계산.

브라우저가 스타일 계산을 시작하고자 하는 경우 주어진 요소에 적용할 클래스, 의사 선택기 및 ID를 결정합니다. 그런 다음 일치하는 선택기의 스타일 규칙을 처리하여 요소의 최종 스타일을 지정합니다.

참고: Blink에서 사용되는 시간의 절반 정도는 Chromium 및 파생 브라우저)에서 요소의 계산된 스타일을 계산하는 것은 선택자를 일치시키는 데 사용되고, 나머지 절반은 계산된 스타일 표현을 삭제합니다. Rune Lillesveen, Opera / Blink에서 스타일 무효화

스타일 재계산 시간 및 상호작용 지연 시간

다음 페인트에 대한 상호작용 (INP)은 사용자 중심 런타임입니다. 사용자 입력에 대한 페이지의 전반적인 응답성을 평가하는 성능 측정항목입니다. 사용자가 페이지와 상호작용한 시점부터 페이지와 상호작용한 시점부터 페이지가 실행될 때까지의 상호작용 지연 시간을 측정합니다. 브라우저는 사용자 인터페이스입니다.

상호작용의 중요한 구성요소는 다음 상호작용을 그리는 데 걸리는 시간입니다. 있습니다. 다음 프레임을 표시하기 위해 수행되는 렌더링 작업은 많은 부분으로 구성되며 레이아웃, 페인트, 작업 직전에 발생하는 페이지 스타일 계산을 비롯한 작업을 합성할 수 있습니다. 이 페이지에서는 스타일 계산 비용에 중점을 두지만 상호작용과 관련된 렌더링 단계에서 전체 여기에는 스타일 계산을 비롯한 여러 지연 시간이 포함됩니다.

선택기의 복잡성 줄이기

선택기 이름을 단순화하면 페이지 스타일 속도를 높일 수 있습니다. 많은 시간을 할애합니다. 가장 간단한 선택기는 클래스 이름:

.title {
  /* styles */
}

하지만 프로젝트가 커지면 더 복잡한 CSS가 필요하게 되어 다음과 같은 선택기로 변경할 수 있습니다.

.box:nth-last-child(-n+1) .title {
  /* styles */
}

이러한 스타일이 페이지에 적용되는 방식을 결정하려면 브라우저가 '이 요소가 title 클래스가 포함된 요소이며 box 클래스가 포함된 하위 요소 minus-nth-plus-1을 어떻게 정의하나요?" API에 사용되는 선택자에 따라 이를 계산하는 데 해당 브라우저가 포함됩니다. 이를 간소화하기 위해 클래스 이름만 바꾸면 됩니다.

.final-box-title {
  /* styles */
}

대체 클래스 이름이 어색해 보일 수 있지만 브라우저의 훨씬 간단해집니다. 예를 들어 이전 버전에서는 브라우저가 요소는 해당 유형의 마지막 요소이며, 먼저 요소에 대한 모든 것을 알아야 합니다. 그 뒤에 오는 요소가 다른 요소를 포함할 수 있는지 여부를 nth-last-child이어야 합니다. 이는 다른 컴퓨팅 리소스를 사용하는 것보다 계산 비용이 단지 해당 클래스가 일치한다는 이유로 선택기를 요소와 일치시키는 것입니다.

스타일이 지정되는 요소 수 줄이기

또 다른 성능 고려사항이며 선택기보다 더 중요한 경우가 많습니다. 복잡도는 요소가 변경될 때 발생해야 하는 작업의 양입니다.

일반적으로 계산된 요소 스타일을 계산하는 데 드는 최악의 비용은 은 요소 수에 선택기 수를 곱한 값입니다. 왜냐하면 브라우저가 각 요소를 모든 스타일에 대해 적어도 한 번은 검토하여 일치하지 않습니다.

참고: 전에는 한 요소의 클래스를 변경하면 모든 요소가 하위 요소의 경우 계산된 스타일을 다시 계산해야 합니다. 일부 브라우저에서는 대신 각 요소에 대해 고유한 소규모 규칙 모음을 유지 관리하여 요소의 스타일이 변경되면 다시 계산될 것입니다. 즉, 트리 내 위치에 따라 요소를 다시 계산해야 할 수 있습니다. 확인할 수 있습니다.

스타일 계산은 일부 요소를 무효화하는 대신 직접 타겟팅할 수 있습니다. 전체 페이지 최신 브라우저에서는 이러한 문제가 덜 발생하는 경향이 있는데, 브라우저가 변경사항이 영향을 미칠 수 있는 모든 요소를 항상 확인할 필요는 없습니다. 반면 이전 브라우저는 이러한 작업에 항상 최적화되어 있지는 않습니다. 위치 무효화되는 요소의 수를 줄여야 합니다.

참고: 웹 구성요소의 스타일 계산은 약간 다릅니다. 스타일은 기본적으로 Shadow DOM 경계를 넘지 않으며 범위가 개별 구성요소를 구성할 수 있습니다 그러나 전반적으로 개념은 여전히 적용됨: 규칙이 간단한 작은 트리가 더 많이 처리됨 더 복잡한 규칙을 가진 더 큰 트리보다 더 효율적으로 데이터를 효율적으로 처리할 수 있습니다.

스타일 재계산 비용 측정

스타일 재계산 비용을 측정하는 한 가지 방법은 패널을 닫습니다. 시작하려면 다음 단계를 따르세요.

1. DevTools를 엽니다.
2. 성능 탭으로 이동합니다.
3. 녹화를 클릭합니다.
4. 페이지와 상호작용합니다.

녹화를 중지하면 다음과 같은 이미지가 표시됩니다.

<ph type="x-smartling-placeholder">

</ph>

스타일 계산을 보여주는 DevTools 보고서

상단의 스트립은 시간 단위당 프레임 수도 표시하는 소형 Flame Chart입니다. 둘째, 활동이 스트립 하단에 가까울수록 더 빠르게 브라우저가 프레임을 그리는 중입니다. Flame Chart가 수평이 아니라 위에 빨간색 막대가 있는 경우 이를 발생시키는 작업이 실행할 수 있습니다

<ph type="x-smartling-placeholder">

</ph>

DevTools 활동에서 오래 실행되는 프레임 요약해 줍니다.

스크롤과 같은 상호작용 중 장기 실행되는 프레임은 가까이서 보는 것이 좋습니다. 보여드리겠습니다 큰 보라색 블록이 표시되면 활동을 확대하고 원하는 항목을 선택합니다. 스타일 다시 계산이라는 라벨이 지정된 작업을 하여 잠재적으로 스타일 재계산에 대한 자세한 내용을 다시 계산하지 않아도 됩니다.

<ph type="x-smartling-placeholder">

</ph>

오랜 시간이 걸리는 방식의 재계산은 25ms 이상입니다.

이벤트를 클릭하면 호출 스택이 표시됩니다. 만약 렌더링 작업이 스타일 변경을 트리거한 자바스크립트를 호출합니다. 또한 변경사항이 영향을 미치는 요소의 수(900여 개)도 보여 줍니다. 요소 및 스타일 계산에 걸린 시간이 포함됩니다. 이때 이 정보를 사용하여 코드에서 수정 사항을 찾기 시작합니다.

블록, 요소, 수정자 사용

BEM (블록, 요소, 수정자)과 같은 코딩 접근 방식 선택자 매칭 성능 이점에 관해 알아보겠습니다. BEM은 모든 것은 단일 클래스가 있고 계층 구조가 필요한 경우 해당 계층 구조는 클래스 이름에 포함됩니다.

.list {
  /* Styles */
}

.list__list-item {
  /* Styles */
}

마지막 하위 요소 예에서와 같이 수정자가 필요한 경우 다음과 같이 추가할 수 있습니다. 다음과 같습니다.

.list__list-item--last-child {
  /* Styles */
}

BEM은 구조에서 CSS를 구성할 때 유용한 출발점입니다. 그리고 스타일 조회가 촉진되기 때문에 단순화된 형태로 제공됩니다.

BEM이 마음에 들지 않는 경우 CSS에 접근할 수 있는 다른 방법이 있지만 기기와 인체공학을 평가해 보세요.

리소스

• Blink에서 스타일 무효화
• BEM (블록, 요소, 수정자)

Markus Spiske의 Unsplash 히어로 이미지