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