가장 빠르고 최적화된 리소스는 전송되지 않는 리소스입니다. 애플리케이션에서 불필요한 리소스를 제거해야 합니다. 팀과 함께 암시적이고 명시적인 가정에 대해 의문을 제기하고 주기적으로 다시 논의하는 것이 좋습니다. 예를 들면 다음과 같습니다.
- 항상 페이지에 리소스 X를 포함해 왔는데, 이를 다운로드하고 표시하는 비용이 사용자에게 제공하는 가치를 상쇄하나요? 그 가치를 측정하고 증명할 수 있나요?
- 리소스 (특히 타사 리소스인 경우)가 일관된 성능을 제공하나요? 이 리소스가 핵심 경로에 있습니까? 아니면 있어야 합니까? 리소스가 핵심 경로에 있다면 이것이 사이트의 단일 장애 지점이 될 수 있나요? 즉, 리소스를 사용할 수 없는 경우 페이지의 성능과 사용자 경험에 영향을 미치나요?
- 이 리소스에 SLA가 필요하거나 있나요? 이 리소스가 압축, 캐싱 등의 성능 권장사항을 준수하나요?
페이지에 불필요하거나 더 안 좋은 리소스가 포함되어 있어 방문자 또는 페이지가 호스팅되는 사이트에 많은 가치를 제공하지 않으면서 페이지 성능을 저해하는 경우가 너무 많습니다. 이는 퍼스트 파티 및 서드 파티 리소스 및 위젯에 동일하게 적용됩니다.
- 사이트 A는 방문자가 클릭 한 번으로 여러 사진을 미리 볼 수 있도록 홈페이지에 사진 회전 기능을 표시하기로 결정했습니다. 페이지가 로드될 때 모든 사진이 로드되며 사용자가 사진을 탐색합니다.
- 질문: 캐러셀에서 여러 장의 사진을 보는 사용자 수를 측정해 보셨나요? 대부분의 방문자가 보지 않는 리소스를 다운로드함으로써 높은 오버헤드가 발생할 수 있습니다.
- 사이트 B는 관련 콘텐츠를 표시하거나 소셜 참여도를 개선하거나 기타 서비스를 제공하기 위해 서드 파티 위젯을 설치하기로 결정했습니다.
- 질문: 위젯을 사용하는 방문자 수 또는 위젯에서 제공하는 콘텐츠의 클릭연결을 추적했나요? 이 위젯이 생성하는 참여가 이러한 오버헤드를 정당화하기에 충분한가요? 또한 필요할 때까지 스크립트가 로드되지 않도록 로드 전략을 사용할 수 있나요?
불필요한 다운로드를 제거할지 여부를 결정하려면 많은 고민과 측정이 필요합니다. 최상의 결과를 얻으려면 페이지의 모든 애셋에 대해 주기적으로 인벤토리를 작성하고 이러한 질문을 다시 검토하세요.
Core Web Vitals에 미치는 영향
Core Web Vitals 이니셔티브는 사용자가 웹을 사용할 때 경험하는 환경을 반영하는 일련의 측정항목을 제공하기 위해 Google에서 도입되었습니다. Core Web Vitals를 위한 최적화 전략은 여러 가지가 있지만 특정 리소스를 페이지에 로드할지 의문을 가지면 웹사이트에서 이러한 측정항목을 개선하는 데 도움이 될 수 있습니다. 아래에는 코어 웹 바이탈별로 그룹화한 몇 가지 예시가 나와 있습니다. 이 목록에 모든 사례가 포함되어 있는 것은 아니지만, 읽어보면 아이디어를 얻는 데 도움이 될 수 있습니다.
최대 콘텐츠 페인트(LCP)
콘텐츠가 포함된 최대 페인트 (LCP)는 최대 콘텐츠 (예: 히어로 이미지 또는 광고 제목)가 로드되는 시점을 측정합니다. 사이트 로드 속도가 빠르다는 인상을 사용자에게 주는 중요한 인지 측정항목으로 간주됩니다.
일반적으로 리소스 다운로드가 적다는 것은 사용자가 보유한 대역폭이 더 적은 리소스에 할당된다는 것을 의미하며, 따라서 LCP가 개선될 수 있습니다. 대표적인 예로 페이지가 로드되는 동안 표시 영역 밖의 이미지는 브라우저에서 사용자가 볼 가능성이 높다고 판단할 때까지 다운로드되지 않는 지연 로드를 들 수 있습니다. 예를 들어 50개의 이미지로 구성된 대규모 미리보기 이미지 갤러리가 있는 경우, 상위 10개 이미지를 제외한 모든 이미지를 지연 로드하면 브라우저가 사용 가능한 대역폭을 더 효율적으로 사용할 수 있으며 사용자에게 표시되는 첫 이미지가 더 빠르게 로드됩니다.
하지만 로드하는 것보다 적은 이미지를 로드하는 것만은 아닙니다. 브라우저에는 각 리소스가 수신해야 하는 대역폭을 결정하는 내부 우선순위 스키마가 있습니다. 그러나 이렇게 모든 리소스, 특히 높은 우선순위로 다운로드된 리소스가 있더라도 잠재적인 LCP 요소의 종속 리소스가 박탈될 가능성이 있습니다. 특히 네트워크 연결이 느린 경우에는 더욱 그렇습니다. 이러한 종속 리소스는 페이지의 LCP 요소를 나타내는 이미지 파일일 수도 있지만, 페이지의 LCP 요소로 결정될 수 있는 텍스트 노드를 브라우저에서 렌더링해야 하는 웹 글꼴 리소스일 수도 있습니다.
웹사이트에 텍스트가 많은 경우 페이지의 LCP 요소가 텍스트 노드인 경우일 수 있습니다. 우수한 글꼴 최적화 및 로드 전략이 많이 있지만, 텍스트 노드인 LCP 요소가 웹 글꼴 리소스에 대한 의존성 없이 로드되고 CSS와 HTML이 서버에서 도착할 때 거의 즉시 페인트할 수 있도록 시스템 글꼴이 웹사이트의 요구에 충분한지 여부를 고려하는 것이 좋습니다.
누적 레이아웃 이동(CLS)
로드하는 모든 리소스는 페이지의 레이아웃 변경 횟수 (CLS)에 영향을 미칠 가능성이 있으며, 특히 초기 페인트까지 다운로드가 완료되지 않은 경우에는 더욱 그렇습니다. 이미지의 경우 CLS를 피하려면 명시적인 크기를 설정하는 등의 방법이 필요합니다. 글꼴의 경우, 글꼴 로드 및 잠재적으로 대체 글꼴 매칭을 관리하면 웹 글꼴의 스왑 기간 동안 이동을 최소화할 수 있습니다. JavaScript의 경우, 레이아웃 변경이 허용 가능한 정도로 줄어들도록 스크립트가 DOM을 조작하는 방법을 관리할 수 있습니다.
페이지의 CLS에 기여하는 모든 리소스는 페이지 레이아웃이 충분히 안정적으로 작동하도록 하기 위해 어느 정도의 작업을 해야 합니다. 특정 리소스가 필요한지 의문을 제기함으로써 페이지 로드 속도를 높일 뿐 아니라 레이아웃 안정성을 유지하는 데 필요한 인지 노력을 줄일 수 있습니다. 이렇게 하면 프로젝트에서 다른 목표를 추진하는 데 더 많은 시간을 할애할 수 있으므로 사용자 경험이 크게 줄어들 뿐만 아니라 개발자 경험도 줄어듭니다.
다음 페인트에 대한 상호작용 (INP)
다음 페인트에 대한 상호작용 (INP)은 페이지의 수명 주기 동안 사용자 입력에 대한 응답성을 측정합니다. 페이지의 INP는 로드되는 JavaScript의 영향을 크게 받을 수 있습니다. JavaScript는 웹에서 대부분의 상호작용 경험을 주도하기 때문입니다. 특히 페이지 로드 중에 다운로드되는 스크립트 리소스의 양은 스크립트 평가 및 컴파일과 관련된 잠재적으로 많은 비용이 드는 작업을 시작할 수 있습니다. 시작 시 로드하는 JavaScript가 적을수록 사용자가 상호작용하려고 할 수 있는 페이지 경험의 중요한 지점에서 브라우저가 해야 하는 작업이 줄어듭니다.
코드 분할 및 트리 쉐이킹과 같이 시작 시 다운로드되는 JavaScript 리소스의 크기를 줄이기 위한 전략이 있지만 프로젝트에서 사용하는 패키지를 감사하여 이러한 패키지가 필요한지 확인해 보는 것이 좋습니다. 예를 들어 lodash에는 현재도 유용한 메서드가 많지만 매핑, 축소, 필터링, 다양한 기타를 위한 Array
전용 함수 등 브라우저에서 즉시 제공하는 메서드가 함께 제공됩니다.
점진적 개선 역시 JavaScript에 유용한 접근 방식으로, 더 강력한 기기와 더 빠른 네트워크 연결을 사용하는 사용자에게 추가할 수 있는 기본 (하지만 여전히 작동되는) 환경을 사용자에게 제공할 수 있습니다. 점진적 개선의 원칙을 고수하든 하지 않든 핵심은 변하지 않습니다. 다운로드를 피할 수 있는 모든 JavaScript 리소스는 웹 성능의 필수적인 요소인 사용자 상호작용에 더 빠르게 응답하는 환경을 제공할 수 있다는 것입니다.
결론
웹사이트에서 불필요한 다운로드가 있는지 감사하는 것은 빠른 사용자 경험을 제공하기 위한 한 가지 측면일 수 있지만 높은 효과를 가져올 잠재력이 있습니다. 요약하면 다음과 같습니다.
- 페이지에 있는 자체 애셋과 서드 파티 애셋의 인벤토리를 작성합니다.
- 각 애셋의 가치와 기술적 성능을 측정합니다.
- 리소스가 충분한 가치를 제공하는지 확인합니다.
- 불필요한 다운로드가 코어 웹 바이탈 및 지원 측정항목에 미치는 영향을 파악합니다.
이러한 방식으로 콘텐츠 효율성을 최적화하면 전반적인 성능이 개선될 뿐만 아니라 사용자의 대역폭이 낭비되지 않도록 주의할 뿐만 아니라 잠재적으로 사용자 중심 측정항목을 개선하고 더 나은 사용자 환경을 제공할 수 있습니다.