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

표준화된 로드 속성 채택에 대한 학습 내용

이 게시물의 목표는 지금이 브라우저 수준 이미지 지연 로드 기능 지원을 구현할 적기라는 CMS 플랫폼 개발자와 기여자(CMS 코어 개발자)를 설득하는 것입니다. 또한 지연 로드를 구현하는 동안 고품질의 사용자 환경을 보장하고 다른 개발자의 맞춤설정을 사용 설정하는 방법에 관한 권장사항도 공유합니다. 이 가이드라인은 WordPress에 지원을 추가하고 Joomla, Drupal, TYPO3에서 이 기능을 구현하는 데 도움을 준 Google의 경험을 바탕으로 합니다.

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

배경

지난 1년 동안 loading 속성을 사용하는 이미지 및 iframe 지연 로드WhatWG HTML 표준의 일부가 되었으며 다양한 브라우저에서 채택되고 있습니다. 하지만 이러한 주요 시점은 더 빠르고 리소스를 절약하는 웹을 위한 토대일 뿐입니다. 이제 분산 웹 생태계에서 loading 속성을 사용합니다.

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

지금 지연 로드를 구현하는 사례

표준화

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

브라우저 지원

이 기능의 브라우저 지원도 유사한 문제입니다. 즉, 대다수의 CMS 사용자가 이 기능의 이점을 누릴 수 있습니다. 상당한 비율의 브라우저에서 이 기능이 아직 지원되지 않는다면 기능은 최소한 이러한 브라우저에 부정적인 영향을 주지 않도록 해야 합니다.

표시 영역으로부터의 거리 임계값

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

사용자 환경 권장사항

요소에 크기 속성 필요

오랫동안 레이아웃 변경을 방지하기 위해 이미지 또는 iframe과 같은 삽입된 콘텐츠에는 항상 크기 속성 widthheight를 포함해야 합니다. 그러면 브라우저가 실제로 요소를 로드하기 전에 이러한 요소의 가로세로 비율을 추론할 수 있습니다. 이 권장사항은 요소가 지연 로드되는지 여부와 관계없이 관련이 있습니다. 그러나 이미지가 표시 영역에 한 번 완전히 로드되지 않을 가능성이 0.1% 더 높기 때문에 지연 로드를 사용하면 약간 더 적절하게 적용될 수 있습니다.

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

스크롤 없이 볼 수 있는 부분의 요소에 대한 지연 로드 피하기

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

자바스크립트 대체 방지

자바스크립트를 사용하여 아직 loading 속성을 지원하지 않는 브라우저에 지연 로드를 제공할 수 있지만, 이러한 메커니즘은 항상 이미지 또는 iframe의 src 속성을 초기에 삭제해야 하므로 이 속성을 지원하는 브라우저가 지연됩니다. 또한 대규모 CMS의 프런트엔드에 이러한 자바스크립트 기반 솔루션을 출시하면 잠재적인 문제의 노출 영역이 늘어납니다. 이러한 이유로 표준화된 브라우저 기능 이전에 핵심 CMS가 지연 로드를 채택한 주요 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 순회 또는 정규 표현식을 통해 속성을 추가할 수 있으며, 후자가 성능을 위해 권장됩니다.

정규 표현식 사용은 최소한으로 유지해야 합니다. 예를 들어 단일 정규식은 속성을 포함하여 콘텐츠의 모든 imgiframe 태그를 수집한 다음 필요에 따라 각 태그 문자열에 loading 속성을 추가합니다. 예를 들어 WordPress는 하나의 일반 정규 표현식을 사용하여 특정 요소에 다양한 작업을 즉석에서 수행하는 데까지 이르렀으며, 여러 기능을 지원하기 위해 단일 정규 표현식을 사용하여 loading="lazy"를 추가하는 것은 단 하나의 정규 표현식에 불과합니다. 또한 이러한 형태의 최적화는 CMS 핵심에서 지연 로드를 채택하는 것이 확장 프로그램보다 권장되는 또 다른 이유입니다. 이렇게 하면 서버 측 성능 최적화가 향상됩니다.

다음 단계

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

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

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

연구에서 얻은 교훈과 이 게시물의 기술 권장사항을 사용하여 패치 또는 pull 요청 등의 형태로 CMS에 코드를 기여할 수 있습니다.

히어로 사진: Colin Watts, Unsplash