RAIL: 성과 평가 프레임워크

이 문서는 다음과 같은 영역을 다룹니다.

레일 모형 개술.

픽셀 파이프와 프레임 여정 개요.

프레임워크 드랍 문제와 크롬 개발 도구를 사용하여 디버깅과 해결을 하는 예시적인 문제를 소개한다.

컴퓨터 과학에서 현장 표현은 많은 것을 의미할 수 있다.하지만 여기서 네트워크 성능, 특히 사용자 중심의 성능을 소개하겠습니다. 이것이 바로 RAIL 모델의 기초입니다.
이 모델은 사용자가 모든 응용 프로그램에서 수행하는 4가지 서로 다른 유형의 주요 동작인 응답, 애니메이션, 유휴 및 로드(RAIL)를 기반으로 합니다.모든 목표를 정의하고 실현하는 것은 사용자 체험을 개선하는 데 도움이 될 것이다.

답변:

사용자의 상호작용에 대한 응답 - 예를 들어 클릭, 클릭, 전환은 100밀리초 안에 이루어져야 하며, 이렇게 하면 사용자가 상호작용이 즉각적이라고 느낄 수 있다.

애니메이션:

사용자는 추적 운동을 잘하는데, 그들은 애니메이션이 원활하지 않을 때를 좋아하지 않는다.애니메이션은 초당 60개의 새 프레임을 렌더링할 때(나중에 자세히 설명) 부드럽게 표시됩니다.
따라서 프레임당 렌더링 시간은 프레임당 16ms(1000/60)입니다. 이는 브라우저가 화면에 새 프레임을 그리는 데 필요한 시간을 포함합니다.브라우저는 한 프레임을 렌더링하는 데 약 6밀리초가 필요하기 때문에 개발자는 한 프레임을 만드는 데 약 10밀리초가 걸린다.
프레임의 렌더링 시간이 10밀리초를 넘으면 삭제되며, 사용자는 떨림/땡그랑 소리를 체험할 수 있습니다.

유휴:

유휴 시간을 최대화하여 페이지가 50밀리초 동안 사용자의 입력에 응답할 확률을 증가시킵니다.우리는 주 라인이 사용자의 상호작용에 응답하는 것을 막고 싶지 않다.
여가 시간을 현명하게 사용하기 위해 작업은 약 50밀리초의 블록으로 나뉜다.왜?사용자가 상호작용을 시작하면, 2초 템플릿 렌더링의 중간에 머무르지 않고 100밀리초의 응답 창에서 응답하기를 원합니다.

로드:

3G 연결 속도가 느린 중저가 휴대전화의 경우 5초 이내에 콘텐츠를 납품하고 상호작용을 실현한다.실적 예산 증가, 경쟁사 추적 및 기타 각종 요소도 작용했다.
이 목표를 실현하려면 관건적인 렌더링 경로를 우선순위로 정렬해야 하며, 보통 후속 비필요 로딩을 빈 시간대(또는 필요에 따라 로딩을 지연시켜야 한다) 로 미루어야 한다.
요약하면 다음은 철도 모델의 네 가지 요소 중 하나하나의 목표이다.
응수
애니메이션
한가하고 있었어
페이지 로드
100밀리초도 안 되는 시간 안에 가볍게 두드려서 그립니다.
각 프레임은 16ms 내에 완성됩니다.
여가 시간을 이용하여 주동적으로 일을 안배하다.
만부하 시 응답 목표를 충족시킵니다.
16ms 이내로 드래그합니다.
50밀리초의 시간을 써서 이 일을 완성하다.
1000밀리초 동안 첫 번째 의미 있는 페인트를 얻을 수 있다.
이제 프레임과 렌더링 과정을 한층 더 알아보겠습니다.

문제는 다음과 같습니다.

성능에 대해 말하자면, 우리는 각양각색의 문제에 부딪힐 수 있다.우리는 특수한 유형의 문제를 고려할 것이다.시차 효과가 있는 사이트에 대해 말하자면, 끊임없이 다시 과장하고 다시 그려야 한다. 당신은 약간의 떨림에 주의할 수 있다.그리는 데 많은 CPU 시간이 소요되어 프레임이 손실됩니다.특히 CPU 전력 소비량이 낮은 장치에서는 그렇습니다.그림을 그리는 데 많은 CPU 시간이 걸려서 프레임이 삭제됩니다.

위의gif를 보면 연속 두루마리에 떨림과 연속 재그림 (녹색 반짝임 돌출 재그림) 이 나타나는 것을 알 수 있습니다. 이것은 프레임이 삭제된 원인 중 하나일 수 있습니다.그러나 우리가 해결 방안을 토론하기 전에, 이 문제에 대한 더 많은 정보를 얻기 위해 픽셀 파이프 (프레임 스케일) 에 대한 개술이다.

픽셀 파이프:

이전에 우리는 왜 10밀리초 안에 프레임을 만들어서 애니메이션을 매끄럽게 유지해야 하는지 토론했다.이제 픽셀 파이프나 렌더링 파이프를 보면서 프레임을 풀고 떨리거나 귀를 찌르는 문제를 피하는 방법을 알아보자.

Javascript

매 주기마다 발생하는 첫 번째 일은 마운트된javascript를 실행하는 것입니다.일반적으로 시각적 변화를 촉발하는 것은 모두 이 단계의 일부분이다.다음은 JS 실행 최적화를 위한 권장 사항입니다.

시각 업데이트의 설정 시간 초과나 설정 간격을 피한다.항상 requestAnimationFrame을 사용하십시오.

장시간 실행 중인 JavaScript를 주 스레드에서 웹 작업자로 옮깁니다.

여러 프레임에서 마이크로 작업을 사용하여 DOM 변경

Chrome DevTools Timeline과 JavaScript Profiler를 사용하여 JavaScript의 영향을 평가합니다.

콘셉트

이것은 일치 선택기를 기반으로 어떤 CSS 규칙이 어떤 요소에 적용되는지 결정하는 과정입니다.

배치

브라우저가 어떤 규칙이 요소에 적용되는지 알면, 브라우저가 차지하는 공간과 화면에 있는 위치를 계산할 수 있다.위치, 너비, 여백 및 표시와 같은 속성은 페이지의 요소 레이아웃에 영향을 줍니다.그 중에서 많은 요소, 예를 들어 원소의 높이를 높이면 페이지에서 원소를 아래로 추진할 때 원소의 구조에 영향을 줄 수 있다.따라서 이러한 속성을 업데이트하는 비용은 왕왕 매우 높다. 왜냐하면 당신은 거의 항상 다른 요소를 업데이트하기 때문이다.애니메이션에 대해서는 가능한 한 그것들을 피해야 한다.(다음은 우리가 행동을 볼 것이다)

페인트

이것은 픽셀을 채우는 과정이다.그림% 1개의 캡션을 편집했습니다.이 그림은 실제로 두 가지 임무를 포함한다.

도면 단위 목록 만들기

픽셀 채우기(래스터화라고도 함)

합성하다

파이프를 렌더링하는 마지막 단계는 화면의 개별 뷰에 서로 다른 레이어를 결합하는 것입니다. 먼저 레이어에 대한 작업이 필요할 수 있습니다.
프레임이 파이프의 단계를 피할 수 있을수록 렌더링에 걸리는 시간이 짧고 잠재적인 귀를 찌르는 소리를 피할 수 있기 때문에 성능이 높아진다.

솔루션

다시 그려야 할 구역을 찾기 위해 개발 도구를 사용하는 방법을 보여 드리겠습니다.
devtools를 연 후 Cmd+Shift+P를 누르고 show rendering를 입력합니다.페인트가 반짝이고 프로그램과 상호작용할 수 있는 많은 옵션을 얻을 수 있습니다.

위의 GIF에서 녹색으로 반짝이는 사각형은 내가 계속 굴러갈 때 다시 그려진 영역을 보여 줍니다.
사용자가 스크롤할 때 정지 이벤트를 분리하고, 사용자가 정지할 때 다시 연결해서 이 문제를 해결할 수 있습니다.다음은 같은 페이지를 스크롤할 때 최적화된 효과입니다.

보시다시피, 내가 굴러갈 때, 녹색으로 반짝이는 직사각형은 다시 나타나지 않습니다.스크롤을 멈추면 출력이 변하지 않는 동시에 렌더링 성능도 향상됩니다.
이제 다시 그리는 영역을 개선하는 방법을 알았습니다. 픽셀 타임라인의 레이아웃 (렌더링) 부분을 보여 드리겠습니다.

dev tools post profiling에 있는 performance 탭의 화면 캡처입니다.
첫 번째 행에는 FPS, CPU 및 NET가 표시됩니다.보라색은 렌더링을 의미하며, 이 화면 캡처는 CPU가 연속적으로 렌더링에 사용되고 있음을 보여 줍니다.또한 위에서 볼 수 있는 FPS와 일치하는 빨간색 막대 - 프레임이 삭제되고 애니메이션이 부드럽지 않음을 나타냅니다.
일반적으로 프레임 레이아웃이 변경되는 경우 - 위치, 높이, 여백 또는 표시 등의 속성을 변경하면 페이지의 요소 레이아웃에 영향을 줍니다.따라서 이미지에 있는 코드에서 다음 CSS 코드를 사용했습니다.

#demo p img {
  position: relative;
  cursor: pointer;
  height: 100%;
  transition: all 0.3s;
}

#demo p.hover img:hover {
  box-shadow: 0 0 12px 13px #ccc;
  top: -12px;
  height: 105%;
  left: 10px;
}

여기서 마우스를 가져가면 요소와 인접한 요소의 레이아웃에 영향을 주는 모든 속성이 변경됩니다.
이 문제를 해결하는 방법은 합성기 속성만 사용하여 프레임을 새로운 층으로 업그레이드하고 GPU에서 단독으로 운행하며 메인 라인을 비우고 프레임 전달을 최적화하는 것이다.그래서 나는 다음과 같이 바꾸었다.

#demo p img {
  position: relative;
  cursor: pointer;
  height: 100%;
  transition: all 0.3s;
}

#demo p.hover img:hover {
  transform: translateY(-12px);
  transform: translateX(10px);
  transform: scale(1.05);
}

변경한 후 다시 분석하면 다음과 같은 출력을 얻을 수 있습니다.

이 두 화면 캡처를 비교하면 CPU가 렌더링에 걸리는 시간이 크게 줄어든 것을 알 수 있습니다.이 프로그램에도 현재 jank가 없습니다. 프레임이 삭제되는 경우가 드물기 때문입니다.최종 결과는 어떻습니까?사용자에게 있어서 이것은 더욱 유창한 체험이다✨
만약 이것이 당신이 오늘 새로운 것을 배우는 데 도움이 된다면, 사랑을 표현하세요!👏
감사합니다!
그리고 만약 당신이 성능 극객이라면 다음은 저의 추천서입니다.마음껏 몰입해.

https://web.dev/rail/

https://developers.google.com/web/fundamentals/performance/rendering

https://developers.google.com/web/fundamentals/performance/rendering/simplify-paint-complexity-and-reduce-paint-areas

https://developers.google.com/web/fundamentals/performance/rendering/stick-to-compositor-only-properties-and-manage-layer-count

http://jankfree.org/