CMS용 브라우저 수준 지연 로드

표준화된 로드 속성 채택을 위한 학습

Felix Arntz

이 게시물의 목표는 CMS 플랫폼 개발자와 참여자(즉, CMS 코어를 개발하는 사람들)에게 지금이 브라우저 수준 이미지 지연 로드 기능에 대한 지원을 구현할 때임을 설득하는 것입니다. 또한 지연 로드를 구현하면서 고품질 사용자 환경을 보장하고 다른 개발자가 맞춤설정할 수 있도록 하는 방법에 관한 권장사항도 공유하겠습니다. 이 가이드라인은 WordPress에 지원을 추가하고 Joomla, Drupal, TYPO3에서 이 기능을 구현하도록 지원한 경험을 바탕으로 작성되었습니다.

CMS 플랫폼 개발자이든 CMS 사용자 (즉, CMS로 웹사이트를 빌드하는 사람)이든 이 게시물을 통해 CMS에서 브라우저 수준 지연 로드의 이점에 대해 자세히 알아볼 수 있습니다. CMS 플랫폼에서 지연 로드를 구현하도록 유도하는 방법에 관한 제안사항은 다음 단계 섹션을 참고하세요.

배경

지난해 loading 속성을 사용한 이미지 및 iframe 지연 로드가 WHATWG HTML 표준의 일부가 되었으며 다양한 브라우저에서 채택이 증가했습니다. 하지만 이러한 이정표는 더 빠르고 리소스를 절약하는 웹을 위한 기반을 마련할 뿐입니다. 이제 분산 웹 생태계에서 loading 속성을 사용할 수 있습니다.

콘텐츠 관리 시스템은 웹사이트의 약 60% 를 지원하므로 이러한 플랫폼은 웹에 최신 브라우저 기능을 도입하는 데 중요한 역할을 합니다. WordPress, Joomla, TYPO3와 같은 몇 가지 인기 있는 오픈소스 CMS는 이미 이미지의 loading 속성 지원을 구현했습니다. 이러한 CMS의 접근 방식과 다른 CMS 플랫폼에서도 이 기능을 채택하는 데 도움이 되는 핵심 사항을 살펴보겠습니다. 미디어 지연 로드는 사이트가 대규모로 활용해야 하는 핵심 웹 성능 기능이므로 CMS 핵심 수준에서 채택하는 것이 좋습니다.

지금 지연 로드를 구현해야 하는 이유

표준화

CMS에서 비표준 브라우저 기능을 채택하면 광범위한 테스트가 용이해지고 잠재적인 개선 영역이 드러날 수 있습니다. 그러나 CMS 전반의 일반적인 합의는 브라우저 기능이 표준화되지 않는 한 각 플랫폼의 확장 프로그램 또는 플러그인 형태로 구현하는 것이 바람직하다는 것입니다. 표준화된 기능만 플랫폼 핵심에 채택될 수 있습니다.

브라우저 지원

기능의 브라우저 지원도 비슷한 문제입니다. 대부분의 CMS 사용자가 이 기능을 활용할 수 있어야 합니다. 기능이 아직 지원되지 않는 브라우저의 비율이 상당한 경우 해당 기능은 최소한 이러한 브라우저에 부정적인 영향을 미치지 않도록 해야 합니다.

표시 영역으로부터의 거리 기준점

지연 로드 구현과 관련된 일반적인 우려는 로드 주기가 이후 단계에서 시작되기 때문에 원칙적으로 이미지가 사용자의 표시 영역에 표시되면 로드되지 않을 가능성이 높아진다는 것입니다. 이전의 JavaScript 기반 솔루션과 달리 브라우저는 이 문제에 보수적으로 접근하며, 실제 사용자 환경 데이터를 기반으로 접근 방식을 미세 조정하여 영향을 최소화할 수 있으므로 CMS 플랫폼에서 브라우저 수준의 지연 로드를 안전하게 채택할 수 있습니다.

사용자 환경 권장사항

엘리먼트에 측정기준 속성 필요

레이아웃 변경을 방지하기 위해 이미지 또는 iframe과 같은 삽입된 콘텐츠에는 항상 크기 속성 width 및 height를 포함하여 브라우저가 실제로 로드하기 전에 이러한 요소의 가로세로 비율을 추론할 수 있도록 하는 것이 오랫동안 권장되어 왔습니다. 이 권장사항은 요소가 지연 로드되는지 여부와 관계없이 관련이 있습니다. 하지만 뷰포트에 이미지가 완전히 로드되지 않을 가능성이 0.1% 더 높기 때문에 지연 로드를 적용하면 약간 더 적용 가능성이 높아집니다.

CMS는 모든 이미지와 iframe에 크기 속성을 제공하는 것이 좋습니다. 모든 요소에 대해 이 작업을 수행할 수 없는 경우 이러한 속성을 모두 제공하지 않는 이미지의 지연 로드를 건너뛰는 것이 좋습니다.

스크롤해야 볼 수 있는 부분의 요소 지연 로드 방지

현재 CMS는 최대 콘텐츠 페인트 측정항목의 지연을 방지하기 위해 스크롤해야 볼 수 있는 부분에 배치된 이미지와 iframe에만 loading="lazy" 속성을 추가하는 것이 좋습니다. 2021년 7월에 발견된 바와 같이 경우에 따라 지연이 심각할 수 있습니다. 하지만 렌더링 프로세스 전에 표시 영역을 기준으로 요소의 위치를 평가하는 것은 복잡하다는 점을 인정해야 합니다. 이는 특히 CMS가 loading 속성을 추가하는 자동화된 접근 방식을 사용하는 경우에 적용되지만, 수동 개입을 기반으로 하는 경우에도 다양한 표시 영역 크기 및 가로세로 비율과 같은 여러 요소를 고려해야 합니다. 하지만 히어로 이미지와 스크롤 없이 볼 수 있는 부분에 표시될 가능성이 높은 기타 이미지 또는 iframe은 지연 로드에서 제외하는 것이 좋습니다.

자바스크립트 대체 방지

JavaScript를 사용하여 loading 속성을 (아직) 지원하지 않는 브라우저에 지연 로드를 제공할 수 있지만, 이러한 메커니즘은 항상 이미지 또는 iframe의 src 속성을 처음에 삭제하는 것에 의존하므로 속성을 지원하는 브라우저에서 지연이 발생합니다. 또한 대규모 CMS의 프런트엔드에 이러한 JavaScript 기반 솔루션을 출시하면 잠재적인 문제가 발생할 수 있는 노출 영역이 늘어납니다. 이는 표준화된 브라우저 기능 이전에 핵심에 지연 로드를 채택한 주요 CMS가 없었던 이유 중 하나입니다.

기술 권장사항

기본적으로 지연 로드 사용 설정

브라우저 수준 지연 로드를 구현하는 CMS에 대한 전반적인 권장사항은 기본적으로 이를 사용 설정하는 것입니다. 즉, loading="lazy"를 이미지와 iframe에 추가해야 하며, 가급적 크기 속성을 포함하는 요소에만 추가해야 합니다. 이 기능을 기본적으로 사용 설정하면 이미지별로 수동으로 사용 설정해야 하는 경우보다 네트워크 리소스를 더 많이 절약할 수 있습니다.

loading="lazy"는 최대한 스크롤해야 볼 수 있는 부분에 표시될 가능성이 높은 요소에만 추가해야 합니다. 클라이언트 측 인식 부족과 다양한 표시 영역 크기로 인해 CMS에서 이 요구사항을 구현하는 것은 복잡할 수 있지만, 최소한 대략적인 휴리스틱을 사용하여 스크롤 없이 볼 수 있는 부분에 표시될 가능성이 높은 히어로 이미지와 같은 요소가 지연 로드되지 않도록 생략하는 것이 좋습니다.

요소별 수정 허용

loading="lazy"는 기본적으로 이미지와 iframe에 추가해야 하지만, 특정 이미지에서 속성을 생략할 수 있도록 허용하는 것이 중요합니다(예: LCP에 최적화). CMS의 잠재고객이 평균적으로 기술에 더 능숙하다고 간주되는 경우, 이는 모든 이미지와 iframe에 노출되는 UI 컨트롤일 수 있으며, 이를 통해 해당 요소의 지연 로드를 선택 해제할 수 있습니다. 또는 서드 파티 개발자가 코드를 통해 유사한 변경을 수행할 수 있도록 API를 서드 파티 개발자에게 노출할 수 있습니다.

예를 들어 WordPress에서는 전체 HTML 태그 또는 컨텍스트 또는 콘텐츠의 특정 HTML 요소에 대해 loading 속성을 건너뛸 수 있습니다.

기존 콘텐츠 개조

대략적으로 CMS에서 HTML 요소에 loading 속성을 추가하는 방법에는 두 가지가 있습니다.

  • 백엔드의 콘텐츠 편집기 내에서 속성을 추가하여 데이터베이스에 영구적으로 저장합니다.
  • 프런트엔드의 데이터베이스에서 콘텐츠를 렌더링할 때 즉시 속성을 추가합니다.

기존 콘텐츠에도 지연 로드의 이점을 제공하기 위해 CMS에서 렌더링 시 즉시 속성을 추가하는 것이 좋습니다. 편집기를 통해서만 속성을 추가할 수 있다면 새 콘텐츠 또는 최근에 수정된 콘텐츠만 이점을 누릴 수 있으므로 네트워크 리소스 절약에 대한 CMS의 영향이 크게 줄어듭니다. 또한 브라우저 수준 지연 로드의 기능이 더 확장될 경우 즉시 속성을 추가하면 향후 수정이 쉬워집니다.

속성을 즉시 추가하면 요소에 잠재적으로 존재하는 loading 속성을 처리하고 이러한 속성이 우선 적용되도록 해야 합니다. 이렇게 하면 CMS 또는 CMS 확장 프로그램도 중복 속성과 충돌하지 않고 편집자 중심 접근 방식을 구현할 수 있습니다.

서버 측 성능 최적화

예를 들어 서버 측 미들웨어를 사용하여 콘텐츠에 loading 속성을 즉시 추가할 때는 속도를 고려해야 합니다. CMS에 따라 DOM 순회 또는 정규 표현식을 통해 속성을 추가할 수 있으며, 성능을 위해서는 후자가 권장됩니다.

정규 표현식 사용은 최소한으로 유지해야 합니다. 예를 들어 콘텐츠의 모든 img 및 iframe 태그를 속성과 함께 수집한 다음 해당하는 경우 각 태그 문자열에 loading 속성을 추가하는 단일 정규 표현식을 사용합니다. 예를 들어 WordPress는 단일 일반 정규 표현식을 사용하여 특정 요소에 대한 다양한 즉석 작업을 수행하며, loading="lazy" 추가는 단일 정규 표현식을 사용하여 여러 기능을 용이하게 하는 작업 중 하나에 불과합니다. 이러한 형태의 최적화는 CMS의 핵심에 지연 로드를 채택하는 것이 확장 프로그램보다 권장되는 또 다른 이유입니다. 이를 통해 서버 측 성능 최적화를 개선할 수 있습니다.

다음 단계

CMS에 해당 기능에 대한 지원을 추가하기 위한 기존 기능 요청 티켓이 있는지 확인하고, 아직 없는 경우 새 티켓을 엽니다. 필요에 따라 이 게시물에 대한 참조를 사용하여 제안을 지원하세요.

질문이나 의견이 있거나 브라우저 수준 지연 로드 지원이 추가된 경우 이 페이지에 CMS를 표시하려면 트윗 (felixarntz@)을 보내주세요. 다른 문제가 발생하면 이에 대해 자세히 알아보고 해결책을 찾고 싶습니다.

CMS 플랫폼 개발자인 경우 다른 CMS에서 지연 로드를 구현한 방법을 살펴보세요.

조사에서 얻은 지식과 이 게시물의 기술 권장사항을 사용하여 패치 또는 pull 요청과 같은 형태로 CMS에 코드를 제공할 수 있습니다.