표준화된 로드 속성 채택을 위한 학습사항
이 게시물의 목표는 CMS 플랫폼 개발자 및 참여자(즉, CMS 코어를 개발하는 사용자)에게 이제 브라우저 수준 이미지 지연 로드 기능 지원을 구현할 때다라고 설득하는 것입니다. 또한 지연 로드를 구현하면서 고품질 사용자 환경을 보장하고 다른 개발자의 맞춤설정을 사용 설정하는 방법에 관한 권장사항도 공유합니다. 이 가이드라인은 WordPress에 지원을 추가하고 Joomla, Drupal, TYPO3에서 이 기능을 구현하도록 지원한 경험을 바탕으로 작성되었습니다.
CMS 플랫폼 개발자이든 CMS 사용자 (즉, CMS로 웹사이트를 빌드하는 사용자)이든 이 게시물을 통해 CMS의 브라우저 수준 지연 로드의 이점에 대해 자세히 알아보세요. CMS 플랫폼에서 지연 로드를 구현하도록 유도하는 방법에 관한 제안사항은 다음 단계 섹션을 참고하세요.
배경
지난 1년 동안 loading 속성을 사용하여 이미지와 iframe을 지연 로드하는 기능이 WHATWG HTML 표준의 일부가 되었으며 다양한 브라우저에서 점점 더 많이 사용되고 있습니다.
그러나 이러한 마일스톤은 더 빠르고 리소스를 절약하는 웹을 위한 초석에 불과합니다.
이제 loading 속성을 사용하는 것은 분산 웹 생태계의 몫입니다.
콘텐츠 관리 시스템은 웹사이트의 약 60% 를 지원하므로 이러한 플랫폼은 최신 브라우저 기능을 웹에 도입하는 데 중요한 역할을 합니다. WordPress, Joomla, TYPO3와 같은 몇 가지 인기 있는 오픈소스 CMS에서 이미 이미지에 loading 속성에 대한 지원을 구현했습니다. 다른 CMS 플랫폼에서도 이 기능을 채택하는 데 관련된 접근 방식과 유용한 정보를 살펴보겠습니다. 지연 로드 미디어는 사이트에서 대규모로 활용해야 하는 핵심 웹 성능 기능이므로 CMS 핵심 수준에서 이를 채택하는 것이 좋습니다.
지금 지연 로드를 구현해야 하는 이유
표준화
CMS에서 표준화되지 않은 브라우저 기능을 채택하면 광범위한 테스트가 용이해지고 잠재적인 개선 영역이 표시될 수 있습니다. 그러나 CMS 전반에서 브라우저 기능이 표준화되지 않는 한 각 플랫폼의 확장 프로그램 또는 플러그인 형태로 구현하는 것이 좋습니다. 표준화된 후에만 기능을 플랫폼 핵심에서 채택할 수 있습니다.
브라우저 지원
이 기능의 브라우저 지원도 마찬가지입니다. 대부분의 CMS 사용자가 이 기능의 이점을 누릴 수 있어야 합니다. 기능이 아직 지원되지 않는 브라우저가 상당히 많은 경우 기능이 적어도 이러한 브라우저에 부정적인 영향을 미치지 않도록 해야 합니다.
표시 영역과의 거리 기준점
지연 로드 구현과 관련하여 일반적으로 우려되는 점은 로드 주기가 나중에 시작되므로 이미지가 사용자의 표시 영역에 표시된 후 로드되지 않을 가능성이 원칙적으로 증가한다는 것입니다. 이전의 JavaScript 기반 솔루션과 달리 브라우저는 이 문제에 보수적으로 접근하며, 실사용자 환경 데이터를 기반으로 접근 방식을 미세 조정하여 영향을 최소화할 수 있으므로 브라우저 수준의 지연 로드는 CMS 플랫폼에서 안전하게 채택할 수 있습니다.
사용자 환경 권장사항
요소에 크기 속성 필요
레이아웃 전환을 방지하기 위해 오랫동안 권장된 방법은 이미지나 iframe과 같은 삽입된 콘텐츠에 항상 크기 속성 width 및 height을 포함하는 것입니다. 그러면 브라우저가 이러한 요소를 실제로 로드하기 전에 요소의 가로세로 비율을 추론할 수 있습니다. 이 권장사항은 요소가 지연 로드되는지 여부와 관계없이 관련이 있습니다. 하지만 뷰포인트에 한 번에 이미지가 완전히 로드되지 않을 가능성이 0.1% 더 높기 때문에 지연 로드를 사용하면 약간 더 적용할 수 있습니다.
CMS는 모든 이미지와 iframe에 크기 속성을 제공하는 것이 좋습니다. 이러한 요소마다 불가능한 경우 이러한 두 속성을 모두 제공하지 않는 지연 로드 이미지를 건너뛰는 것이 좋습니다.
로드 시 화면 위에 표시되는 요소의 지연 로드 피하기
현재 CMS는 Largest Contentful Paint 측정항목의 지연을 방지하기 위해 loading="lazy" 속성을 스크롤 아래에 배치된 이미지와 iframe에만 추가하는 것이 좋습니다. 이 측정항목은 2021년 7월에 확인된 바와 같이 경우에 따라 상당한 지연을 일으킬 수 있습니다. 그러나 렌더링 프로세스 전에 뷰포트에 대한 요소의 위치를 평가하는 것은 복잡합니다. 이는 CMS에서 loading 속성을 추가하는 데 자동화된 접근 방식을 사용하는 경우에 특히 적용되지만 수동 개입을 기반으로 하더라도 다양한 뷰포트 크기 및 가로세로 비율과 같은 여러 요소를 고려해야 합니다. 하지만 히어로 이미지와 스크롤 시 화면에 표시될 가능성이 높은 다른 이미지 또는 iframe은 지연 로드되지 않도록 하는 것이 좋습니다.
JavaScript 대체를 피하세요.
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에서 지연 로드를 구현한 방법을 살펴보세요.
조사에서 얻은 학습 내용과 이 게시물의 기술 권장사항을 사용하여 패치 또는 풀 리퀘스트의 형태로 CMS에 코드 기여를 시작할 수 있습니다.