엘리멘터 사이트 속도를 높이는 최적화 방법

엘리멘터 관리 – 엘리멘터 내적 요소

엘리멘터의 퍼포먼스 관련 기능 살펴보기

엘리멘터는 몇 가지 퍼포먼스 관련 기능을 제공하는데, 이 기능들이 기존의 사이트 퍼포먼스를 유의미하게 향상시키지는 않지만 앞으로도 덩치가 점점 커져가는 엘리멘터의 최소한의 성능을 보장할 도구이므로 짚고 넘어간다.
엘리멘터는 퍼포먼스와 관련한 기능에 대한 사용유무를 사용자의 선택에 맡기고 있는데,

1. 아직 테스트 중인 베타 스테이징인 경우
2. 결과가 이용자의 선택에 따라 상대적으로 크게 달라질 수 있거나 사이드 이펙트가 발생할 여지가 있는 경우

엘리멘터에서 제공하는 기능을 기본으로 사용하기

엘리멘터와 다른 퍼포먼스 관련 플러그인을 함께 사용한다면 항상 엘리멘터 내장 기능을 기본으로 사용한다. 예를들어 배경 이미지 지연 로딩 기능을 사용하고 싶다면 엘리멘터에서만 활성화하고 다른 플러그인에서는 모두 비활성화 한다.
엘리멘터가 제공하는 기능은 당연히 엘리멘터에서 가장 잘 작동하므로 굳이 다른 플러그인의 기능을 사용할 이유가 없다.

Optimized Control Loading

비쥬얼 편집기답게 콘트롤 패널에서 모든 사용자의 결정을 처리하고 프론트엔드에 반영하므로 엘리멘터에서 작업 부하가 가장 많이 걸리는 곳이 Contorl이다. 사용하는 콘트롤만 선별해서 로딩하는 옵션인데, 테스트 상으로는 프론트엔드와 백엔드 편집화면에서 서버 응답 속도에 대한 유의미한 향상은 없었다. 최초 응답속도 보다는 워드프레스 코어에 내장된 객체 캐싱처럼 엘리멘터에서 사용되는 각종 위젯의 로직 전반에 걸친 렌더링 성능을 개선하는 것으로 보인다.
아직 베타 스테이징이고 앞으로 성능이 개선 될 여지가 충분하므로 활성화 하는 편이 좋다.

Element Caching

엘리멘터 버전 3.22에 추가 된 캐싱 기능이다. 페이지에 사용된 위젯의 HTML 출력을 서버측에 사본을 두어 로딩 속도를 개선하는 방식인데, 페이지 전체 캐싱이 아니라 요소별 캐싱이다.
회원 이름, 업데이트 날짜 등, Dynamic Tag(동적 태그)를 이용해 컨텐츠를 동적으로 받아오는 경우에는 캐시에서 제외되며, 위젯의 콘트롤러에서 선택적으로 토글할 수도 있다.

엘리멘터에서 캐싱 플러그인을 사용하지 않고도 페이지 로딩 속도를 유의미하게 향상시킬 수 있는 중요한 업데이트로 보인다. 현재는 베타 스테이징이고 실제로 적용하면 약 0.5초(500ms)에 해당하는 속도 향상을 확인했다(관리자 로그인이 되어있지 않은 브라우저에서 개발자 도구의 Network 탭에 위치한 Disable Cache를 해제한 후 테스트).
전체 페이지 캐싱에는 훨씬 못미치지만 대부분의 경우에 캐시를 지우기 위한 별도의 Purge 행위가 필요없고, 캐시 솔루션을 사용하지 않는 사용자에게 기본으로 제공하기에는 충분히 좋다.

테스트 결과 엘리멘트 캐싱을 활성화해도 동적 태그에 의한 큰 문제는 보이지 않았다. Features 탭에서 Activate로 설정한 후, 혹시라도 문제가 발생하는 위젯이 있다면 해당 위젯의 Advanced 탭에서 별도로 Inactive로 비활성하면 된다.
Speed up page loading with Element Caching 기사를 통해 자세한 정보를 확인할 수 있다.

Optimized Image Loading

로딩 후 바로 보여져야 하는 이미지에 대해서는 fetchpriority="high" 어트리뷰트를 추가하고 그 외 뷰포트에 보이지 않는 요소에 대해서는 loading="lazy"와 decoding="async"를 추가한다. 이 기능은 스크롤이 매우 긴 문서에 여러 이미지가 있는 경우에는 요청을 줄일 수 있다. 하지만 생각보다 뷰포트 임계값이 높아 뷰포트에 보이지 않는 이미지 모두가 이 혜택을 받진 않는다.

예를들어, 2560x1440의 웹 브라우저의 뷰포트 높이는 1440px이지만 웹 브라우저는 2500px 거리에 해당하는 이미지는 모두 최초 로딩에 포함시켰다. 따라서 뷰포트 바로 아래 바둑판식 격자에 40개의 이미지 겔러리가 있다면 이 이미지들은 lazy loading의 효과를 받지 못한다는 의미다.
브라우저마다 임계값이 다를 수 있지만 보통 스크롤이 매우 길고 이미지가 많은 블로그 게시물 같은 형태에서 더 효율이 좋다.

Lazy Load Background Images

페이지의 첫 요소를 제외한 나머지 배경 이미지에 대해 지연 로딩하는 기능인데, 필자는 이 기능이 작동하도록 엘리멘터에서 여러 상황을 구현해 봤지만 지연 로딩에 모두 실패했다.

• 컨테이너 위젯의 콘트롤러를 통해 삽입 : 실패
• 컨테이너 위젯의 Custom CSS를 통해 삽입 : 실패
• HTML Widget에서 DOM 요소를 만들고 CSS를 작성 : 실패
• 엘리멘터의 CSS 첨부 형식을 문서 내부 작성으로 변경 : 실패

이는 다른 최적화 플러그인에서도 마찬가지인데, CSS에 포함된 이미지를 지연 로딩하는 방법 자체가 DOM을 다루는 다소 트릭성 스크립트를 사용한다. 엘리멘터 버전 3.9 이전에는 뷰포트에 보이지 않는 배경 이미지의 가장 작은 썸네일 이미지를 원본 대신 로드한 후, 스크롤을 통해 뷰포트에 노출되면 원본 이미지를 다시 로드하는 형태였다고 한다.
이후, 엘리멘터 버전 3.9 베타 3부터는 뷰포트에 보이지 않는 배경 이미지는 아예 로드를 하지 않고 뷰포트에 노출될 경우에만 로드한다고 공식 개발자 문서에서 언급하고있지만 실제로는 그렇지 않았다.

UPDATE 28/11/2022: In elementor-3.9-beta-3 we were able to further enhance background-image lazy loading! Instead of loading thumbnail size images on page load, Elementor uses the image dominant colors as background colors. This little change removes entirely background images from the initial page load.

이 기능을 활성화 한 후 브라우저의 개발자 도구에서 확실한 지연 로딩이 확인된다면 활성화하고 그렇지 않다면 끄는 것을 권한다.

쿼리(Query)를 사용하는 위젯을 주시한다

워드프레스에서 글 목록을 가져오는 것은 자연스러운 일이다. 블로그 글을 가져오거나 우커머스의 상점 아이템을 가져오는 일련의 행위는 서버에 쿼리를 보내 필터링 된 결과를 화면에 출력한다. 이 쿼리는 엘리멘터의 특정 위젯에서도 보낼 수 있는데, 대표적으로 엘리멘터 프로의 기본 기능 중 하나인 Loop Grid 위젯이다.
그리고 쿼리를 사용하는 위젯은 엘리멘터를 사용하는 사이트의 페이지 로딩을 지연시키는 가장 큰 요소다.

앞서 소개했던 많은 최적화 기능들을 모두 활성화해도 일반적인 사이트에서 사용자가 체감할 수 있는 성능 향상은 없다시피하지만, 쿼리를 사용하는 위젯은 바로 체감이 된다. 또한 써드파티 플러그인의 루프 위젯을 사용하면 지연 시간이 0.1초에서 0.5초까지도 상승한다. 한마디로 JS나 CSS, 이미지등의 정적인 요소의 최적화 보다는 쿼리와 같이 동적으로 컨텐츠를 요청하는 경우를 잘 관리해야 한다.

테마의 php 파일에서 query_posts 메서드를 사용하는 것이 가장 속도가 빠르지만 엘리멘터를 사용하는 이상 위젯 사용이 강제되는 만큼 쿼리를 사용하는 위젯을 잘 선택해야 한다. 엘리멘터의 Loop Grid 위젯을 1순위로 두는 것이 좋다. JetEngine의 Listing Grid는 초기 응답이 가장 느리지만 별도의 Lazy Loading 기능을 제공하므로 이 기능을 사용한다면 응답시간이 0이 된다. 다만, 눈으로 확인이 가능한 실제 컨텐츠는 약 2초의 로딩 후 화면에 출력된다.

가능하다면 Hello Elementor 테마를 사용한다

엘리멘터는 그 자체로 하나의 거대한 테마라고 할 수 있다. 엘리멘터에서 제공하는 Theme Builder는 헤더, 푸터, 검색 결과처럼 워드프레스의 모든 파트를 템플릿화하므로 별도의 유/무료 테마가 필요하지 않다. 기성 테마처럼 완전히 디자인 된 페이지가 필요하다면 템플릿에 엘리멘터의 내장 Library Kit나 Jetcraft의 템플릿을 그대로 복사해서 넣으면 된다.
기성 테마는 페이지 로딩 성능을 떨어뜨리는 요소가 존재할 수 있고 엘리멘터 호환 위젯들에 대한 스타일 상속을 방해할 수 있다. 하지만 기본 Hello Elementor 테마는 빈 캔버스처럼 시작 테마이므로 사이트 성능에 대한 완전한 제어권을 보장받고 시작할 수 있다.

Hello Elementor 테마가 로드하는 styles.css와 theme.css는 각각 HTML 요소의 스타일 초기화(normalize.css나 reset.css 역할)과 테마가 사용하는 기본 헤더, 푸터 따위의 스타일을 정의하고 있다. 관리자 메뉴의 Appearance → Theme Settings에서 토글할 수 있으며 사이트 성능에는 큰 영향이 없다.

컨테이너 위젯은 항상 ‘Full Width’를 기본으로 사용한다

엘리멘터에서 흔하게 사용하는 Container Widget은 페이지의 Top Level에서 생성 시 Content Width의 기본 값을 Boxed로 설정한다. Boxed는 실제 라이브 페이지에서 max-width 설정이 포함 된 추가 DOM 요소(div)를 생성한다. 따라서 Boxed는 페이지의 최상위 컨테이너 이외에는 사용할 필요가 없다. 기존에 생성한 컨테이너를 Full Width로 변경해 불필요한 추가 DOM 요소를 생성시키지 않도록 한다.

추가로 생성되는 DOM 요소가 실제 웹 사이트의 렌더링 성능에 큰 영향을 끼치진 않더라도 편집 화면에서는 매우 중요한 부분이다. 엘리멘터의 편집 화면은 대단히 많은 양의 DOM 요소를 사용하는데, 여기서 boxed로 설정된 컨테이너는 콘트롤을 위해 라이브 페이지보다 더 많은 양의 추가 DOM 요소를 생성하고, 이는 편집 화면의 리로딩 속도에 큰 영향을 미친다.
실제로 엘리멘터 편집 화면의 좌측 상단에 위치한 햄버거 메뉴에서 Site Settings 메뉴에 진입했다가 나오면 이러한 편집 화면의 DOM 요소가 렌더링에 어느정도의 영향을 끼치는지 실감할 수 있다.

텍스트 편집기 위젯의 사용 빈도를 줄인다

TextEditor Widget은 위지윅을 지원하는 편리한 위젯이다. 이 위젯은 Classic Editor, Advanced Classic Editor 등의 추가 플러그인을 사용하면 기능을 더욱 확장할 수 있다. 하지만 그런만큼 자원을 많이 소모하는 위젯이기도 하다. 편집기 위젯이 페이지 내에 많이 사용되면 편집 화면을 로딩하는데 많은 시간이 걸린다. 방문자의 경험만큼이나 관리자가 페이지를 편집하는데 거부감이 들지 않도록 하는 것도 중요하다.

편집기 위젯은 간단한 단락이나 문구를 넣을 때 사용하기에 부적합하다. 블로그 게시물처럼 끊김없이 하나의 긴 컨텐츠를 채울 때 사용하는 것이 좋다. 그러기 위해서는 이미지나 비디오, 리스트 양식, 테이블, 코드하이라이터, h1 - h6에 해당하는 헤딩과 같은 각종 컨텐츠 요소들이 위젯 내부에서 최대한 조화롭게 스타일링 되도록 준비하는 것이 가장 좋다.
그렇지 않으면 편집기 위젯을 사용하다가 도중에 멈추고 이미지 위젯, 비디오 위젯과 같은 별도의 위젯을 사용한 후 또 다시 새로운 편집기 위젯을 사용하게 된다.

필자는 TextEditor 위젯 내부에서 이런 다양한 요소들을 처리할 수 있도록 템플릿을 제작해 배포하고 있다. (Jetcraft-block-content-01 템플릿)

동일한 결과를 내는 더 적합한 위젯을 사용한다

페이지에서 가장 많이 사용하는 컨텐츠 레이아웃은 타이틀과 이미지, 그리고 글 단락으로 이루어진 구성이다. 이러한 구성을 위해 헤딩 위젯, 이미지 위젯, 텍스트 편집기 위젯을 조합하는 것 보다 Image Box Widget 혹은 Call To Action 위젯 하나를 사용하는 편이 라이브 서비스와 편집 환경 모두에서 DOM 요소를 훨씬 적게 생성한다.

위젯은 그 자체로도 하나의 DOM 요소를 사용하면서 추가로 elementor-widget-container라는 래퍼용 요소도 출력한다. 페이지 내에 사용하는 위젯의 수가 증가하면 이런 추가적인 DOM 요소가 기하급수적으로 증가한다. 단순히 제목과 글 단락으로 이루어진 구성이 필요하다면 엘리멘터 위젯 카테고리 중 Wordpress 항목에 위치한 Text Widget도 좋은 선택이다.