가장 빠르고 최적화된 리소스는 전송되지 않은 리소스입니다. 애플리케이션에서 불필요한 리소스를 제거해야 합니다. 팀과 함께 암시적 및 명시적 가정을 의심하고 주기적으로 재검토하는 것이 좋습니다. 예를 들면 다음과 같습니다.
- 항상 페이지에 리소스 X를 포함해 왔지만 리소스를 다운로드하고 표시하는 데 드는 비용이 사용자에게 제공하는 가치를 상쇄하나요? 가치를 측정하고 입증할 수 있나요?
- 리소스 (특히 서드 파티 리소스인 경우)가 일관된 성능을 제공하나요? 이 리소스가 핵심 경로에 있나요? 아니면 있어야 하나요? 리소스가 중요 경로에 있는 경우 사이트의 단일 장애점이 될 수 있나요? 즉, 리소스를 사용할 수 없는 경우 페이지의 성능과 사용자 환경에 영향을 미치나요?
- 이 리소스에 SLA가 필요하거나 SLA가 있나요? 이 리소스는 압축, 캐싱 등의 성능 권장사항을 준수하나요?
페이지에 불필요한 리소스가 포함되어 있거나, 더 나쁜 경우 방문자나 호스팅된 사이트에 큰 가치를 제공하지 않으면서 페이지 성능을 저해하는 리소스가 포함되어 있는 경우가 많습니다. 이는 퍼스트 파티 및 서드 파티 리소스와 위젯에 동일하게 적용됩니다.
- 사이트 A는 방문자가 빠르게 클릭하여 여러 사진을 미리 볼 수 있도록 홈페이지에 사진 캐러셀을 표시하기로 결정했습니다. 페이지가 로드될 때 모든 사진이 로드되고 사용자가 사진을 탐색합니다.
- 질문: 캐러셀에서 여러 장의 사진을 보는 사용자 수를 측정했나요? 대부분의 방문자가 절대 보지 않는 리소스를 다운로드하여 오버헤드가 발생할 수 있습니다.
- 사이트 B는 관련 콘텐츠를 표시하거나, 소셜 참여도를 개선하거나, 기타 서비스를 제공하기 위해 서드 파티 위젯을 설치하기로 결정했습니다.
- 질문: 위젯을 사용하는 방문자 수 또는 위젯에서 제공하는 콘텐츠의 클릭수를 추적했나요? 이 위젯이 생성하는 참여도가 오버헤드를 정당화하기에 충분한가요? 또한 로드 전략을 사용하여 필요할 때까지 스크립트가 로드되지 않도록 할 수 있나요?
불필요한 다운로드를 제거할지 결정하려면 신중한 사고와 측정이 필요합니다. 최상의 결과를 얻으려면 페이지의 모든 확장 소재에 대해 주기적으로 이러한 질문을 점검하고 재검토하세요.
Core Web Vitals에 미치는 영향
Core Web Vitals 이니셔티브는 사용자가 웹을 사용할 때 경험하는 상황을 반영하는 측정항목을 제공하기 위해 Google에서 도입했습니다. Core Web Vitals를 위한 최적화 전략은 다양하지만 페이지에 특정 리소스를 로드할지 여부를 의심해 보면 웹사이트에서 이러한 측정항목을 개선할 수 있는 방법을 찾을 수 있습니다. 다음은 고려해 볼 만한 몇 가지 예시로, 각 Core Web Vitals별로 그룹화되어 있습니다. 다음은 예시의 일부일 뿐이며 예시는 많습니다. 예시를 읽어보면 유용한 아이디어를 얻을 수 있습니다.
최대 콘텐츠 렌더링 시간(LCP)
최대 콘텐츠 렌더링 시간 (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 리소스를 사용하면 웹 성능의 중요한 측면인 사용자 상호작용에 더 빠르게 응답하는 환경을 만들 수 있다는 것입니다.
결론
웹사이트에서 불필요한 다운로드를 감사하는 것은 빠른 사용자 환경을 제공하는 한 가지 측면일 수 있지만 큰 영향을 줄 수 있는 측면입니다. 요약하면 다음과 같습니다.
- 페이지에서 자체 저작물과 서드 파티 저작물의 인벤토리를 확인합니다.
- 각 확장 소재의 가치와 기술적 성능을 측정합니다.
- 리소스가 충분한 가치를 제공하는지 확인합니다.
- 불필요한 다운로드가 Core Web Vitals 및 지원 측정항목에 미치는 영향을 이해합니다.
이러한 방식으로 콘텐츠 효율성을 최적화하면 전반적인 성능이 개선될 뿐만 아니라 사용자의 대역폭을 낭비하지 않을 수 있으며, 사용자 중심의 측정항목을 개선하고 더 나은 사용자 환경을 제공할 수도 있습니다.