Front-End Performance 2021: 현실적인 목표 설정

이 가이드는 프론트엔드 성능 모니터링 , 세션 재생 및 제품 분석을 결합하여 더 나은 고객 경험을 구축하는 데 도움이 되는 서비스인 LogRocket의 친구들로부터 친절하게 지원되었습니다. LogRocket 은 다음을 포함한 주요 지표를 추적합니다. DOM 완료, 첫 번째 바이트까지의 시간, 첫 번째 입력 지연, 클라이언트 CPU 및 메모리 사용량. 지금 LogRocket의 무료 평가판을 받으십시오.

목차

1. 준비하기: 계획 및 측정항목
2. 현실적인 목표 설정
3. 환경 정의
4. 자산 최적화
5. 빌드 최적화
6. 배달 최적화
7. 네트워킹, HTTP/2, HTTP/3
8. 테스트 및 모니터링
9. 빠른 승리
10. 한 페이지에 모든 것
11. 체크리스트 다운로드(PDF, Apple Pages, MS Word)
12. 다음 가이드를 놓치지 않으려면 이메일 뉴스레터를 구독하세요.

현실적인 목표 설정

1. 100밀리초 응답 시간, 60fps.
   상호 작용이 원활하게 느껴지도록 인터페이스는 사용자 입력에 응답하는 데 100ms가 있습니다. 그보다 길면 사용자는 앱을 랙으로 인식합니다. 사용자 중심의 성능 모델인 RAIL은 건강한 목표 를 제공합니다. <100밀리초 응답을 허용하려면 페이지는 늦어도 매 <50밀리초 후에 기본 스레드에 제어를 되돌려야 합니다. 예상 입력 대기 시간은 임계값에 도달했는지 알려주며 이상적으로는 50ms 미만이어야 합니다. 애니메이션과 같은 고압 포인트의 경우 할 수 있는 곳에서는 다른 작업을 하지 않는 것이 가장 좋고, 할 수 없는 곳에서는 최소한의 작업을 수행하는 것이 가장 좋습니다.

   

   또한 애니메이션의 각 프레임은 16밀리초 미만으로 완료되어야 하므로 초당 60프레임(1초 ÷ 60 = 16.6밀리초), 바람직하게는 10밀리초 미만을 달성해야 합니다. 브라우저가 새 프레임을 화면에 칠하는 데 시간이 필요하기 때문에 코드 실행이 16.6밀리초 표시에 도달하기 전에 완료되어야 합니다. 우리는 120fps(예: iPad Pro의 화면은 120Hz에서 실행됨)에 대한 대화를 시작했으며 Surma는 120fps에 대한 몇 가지 렌더링 성능 솔루션을 다루었지만 아직 우리가 보고 있는 목표는 아닙니다.

   성능 기대치는 비관적이지만 인터페이스 디자인은 낙관적이며 유휴 시간을 현명하게 사용하십시오(idlize, idle-until-urgent 및 react-idle 확인). 분명히 이러한 목표는 로드 성능이 아니라 런타임 성능에 적용됩니다.

2. FID < 100ms, LCP < 2.5s, TTI < 5s on 3G, 중요 파일 크기 예산 < 170KB(gzipped).
   달성하기가 매우 어려울 수 있지만 좋은 궁극적인 목표는 5초 미만의 상호 작용 시간이고 반복 방문의 경우 2초 미만을 목표로 하는 것입니다(서비스 작업자만 가능). 2.5초 미만의 가장 큰 콘텐츠가 포함된 페인트 를 목표로 하고 총 차단 시간 및 누적 레이아웃 이동 을 최소화합니다. 허용 가능한 첫 번째 입력 지연 은 100ms–70ms 미만입니다. 위에서 언급했듯이 우리는 400ms RTT 및 400kbps 전송 속도로 에뮬레이트된 느린 3G 네트워크의 200달러 Android 전화(예: Moto G4)를 기준으로 고려하고 있습니다.

   웹에서 콘텐츠를 신속하게 전달하기 위한 합리적인 목표를 효과적으로 형성하는 두 가지 주요 제약 조건이 있습니다. 한편으로는 TCP 느린 시작으로 인한 네트워크 전달 제약 이 있습니다. HTML의 처음 14KB(각 1460바이트, 약 14.25KB를 만드는 TCP 패킷 10개)는 문자 그대로 받아들여지지는 않지만 가장 중요한 페이로드 청크이며 첫 번째 왕복에서 전달할 수 있는 예산의 유일한 부분입니다( 모바일 깨우기 시간으로 인해 400ms RTT에서 1초 안에 얻을 수 있는 모든 것입니다.

   

   ( 참고 : TCP는 일반적으로 네트워크 연결을 상당히 활용하지 못하기 때문에 Google은 TCP 지연 제어 TCP 흐름 제어 알고리즘인 TCP Bottleneck Bandwidth 및 RRT( BBR )를 개발했습니다. 최신 웹용으로 설계되어 실제 혼잡에 응답합니다. TCP와 같은 패킷 손실 대신 처리량이 더 높고 대기 시간이 짧고 훨씬 빠르며 알고리즘은 다르게 작동합니다.( 감사합니다, Victor, Barry! )

   반면에 JavaScript 구문 분석 및 실행 시간으로 인해 메모리와 CPU에 대한 하드웨어 제약 이 있습니다(나중에 자세히 설명하겠습니다). 첫 번째 단락에서 설명한 목표를 달성하려면 JavaScript의 중요한 파일 크기 예산을 고려해야 합니다. 예산이 얼마인지에 대한 의견은 다양하지만(프로젝트의 특성에 따라 크게 다릅니다), 170KB JavaScript gzip으로 압축된 예산은 이미 중급 전화기에서 구문 분석하고 컴파일하는 데 최대 1초가 소요됩니다. 170KB가 압축 해제 시 해당 크기의 3배로 확장된다고 가정하면(0.7MB), 이는 이미 Moto G4/G5 Plus에서 "적절한" 사용자 경험의 죽음의 신호일 수 있습니다.

   

   Wikipedia 웹사이트의 경우 2020년에 전 세계적으로 Wikipedia 사용자의 코드 실행이 19% 빨라졌습니다. 따라서 연간 웹 성능 지표가 안정적으로 유지된다면 환경이 계속 개선됨에 따라 실제로 퇴행 하고 있다는 경고 신호입니다(자세한 내용은 Gilles Dubuc의 블로그 게시물 참조).

   동남아시아, 아프리카 또는 인도와 같이 성장하는 시장을 목표로 하려면 매우 다른 제약 조건을 살펴봐야 합니다. Addy Osmani는 소수의 저가, 고품질 장치, 고품질 네트워크 사용 불가, 고가의 모바일 데이터와 같은 주요 피처폰 제약 조건을 이러한 환경에 대한 PRPL-30 예산 및 개발 지침과 함께 다룹니다.

   

   

   실제로 Google의 Alex Russell은 합리적인 상한선으로 gzip으로 압축된 130~170KB를 목표로 할 것을 권장합니다. 실제 시나리오에서 대부분의 제품은 가깝지 않습니다. 오늘날 중간 번들 크기는 약 452KB 로, 이는 2015년 초에 비해 53.6% 증가한 것입니다. -대화형 .

   

   그러나 번들 크기 예산을 초과할 수도 있습니다. 예를 들어, 우리는 브라우저의 메인 쓰레드의 활동을 기반으로 성능 예산을 설정할 수 있습니다. Calibre, SpeedCurve 및 Bundlesize와 같은 도구를 사용하면 예산을 확인하고 빌드 프로세스에 통합할 수 있습니다.

   마지막으로 성능 예산 은 고정된 값이 되어서는 안 됩니다. 네트워크 연결에 따라 성능 예산이 조정되어야 하지만 느린 연결의 페이로드는 사용 방식에 관계없이 훨씬 더 "비쌉니다".

   참고 : HTTP/2가 널리 보급되고 5G 및 HTTP/3가 출시되고 휴대폰이 빠르게 발전하고 SPA가 번창하는 시대에 이처럼 경직된 예산을 설정하는 것이 이상하게 들릴 수 있습니다. 그러나 혼잡한 네트워크에서 천천히 발전하는 인프라, 데이터 한도, 프록시 브라우저, 데이터 저장 모드 및 교활한 로밍 요금에 이르기까지 모든 것을 포함하여 네트워크 및 하드웨어의 예측할 수 없는 특성을 처리할 때 합리적으로 들립니다.

목차

1. 준비하기: 계획 및 측정항목
2. 현실적인 목표 설정
3. 환경 정의
4. 자산 최적화
5. 빌드 최적화
6. 배달 최적화
7. 네트워킹, HTTP/2, HTTP/3
8. 테스트 및 모니터링
9. 빠른 승리
10. 한 페이지에 모든 것
11. 체크리스트 다운로드(PDF, Apple Pages, MS Word)
12. 다음 가이드를 놓치지 않으려면 이메일 뉴스레터를 구독하세요.