변환된 페이지는 직접 만든 페이지만큼 빠를 수도 있고, 눈에 띄게 느릴 수도 있습니다. 변환 중과 변환 후에 내리는 몇 가지 선택에 따라 달라집니다.
HTML 블록보다 네이티브 위젯을 선택하세요
가장 큰 영향을 주는 요소입니다. 하나의 큰 HTML 위젯에 통째로 넣은 페이지는 페이지에 없는 요소를 위한 규칙까지 포함해 원본 스타일시트 전체를 함께 가져옵니다. 네이티브 구성요소 모드는 실제 위젯을 만들어 내며, 그 스타일은 Elementor가 페이지별로 생성하고 캐시합니다. 따라서 사용되지 않는 CSS가 훨씬 적게 전송되고, 덤으로 편집 가능한 페이지까지 얻게 됩니다.
원본 스타일시트를 어떻게 할지 결정하세요
인라인 스타일을 유지하는 것은 변환 중에는 유용합니다. 클래스 기반 스타일을 정확하게 측정할 수 있게 해 주기 때문입니다. 하지만 위젯이 자체 설정을 갖게 되면 페이지 상단에 남은 CSS 블록은 불필요한 경우가 많습니다. 제거해 보고 레이아웃을 확인하세요. 아무것도 달라지지 않는다면 쓸모없는 덩어리를 방금 덜어낸 것입니다.
이미지에 가장 많은 주의를 기울이세요
- 데이터 URL을 삽입하지 말고 실제 이미지를 미디어 라이브러리에 업로드하세요. Base64 이미지는 크기를 조정할 수도, 따로 캐시할 수도, 지연 로드할 수도 없으며 페이지 HTML 자체를 부풀립니다.
- 모든 곳에 큰 크기 하나를 강제하지 말고 WordPress가 반응형 크기를 제공하도록 맡기세요.
이미지 최적화 옵션이 실제로 하는 일
이 옵션은 이름이 주는 인상보다 범위가 좁으며, 그 경계를 알아 두면 하지 않는 일을 기대하지 않게 됩니다.
이 옵션은 고충실도 모드에서만 실행되고, 약 135KB보다 큰 Base64 데이터 이미지(PNG, JPEG, WebP)에만 적용됩니다. 해당 이미지는 디코딩된 뒤 가장 긴 변이 최대 2560px가 되도록 축소되고 다시 인코딩됩니다. 결과 화면에는 몇 개가 처리되었고 얼마나 절약되었는지가 표시됩니다.
하지 않는 일도 있습니다. URL로 참조된 이미지는 건드리지 않습니다. 그것은 서버에 있는 파일이며, 도구가 다시 쓸 대상이 아니기 때문입니다. 그리고 네이티브 구성요소 모드에서는 아예 실행되지 않습니다. 그 모드에서 Base64 이미지는 미디어 라이브러리에서 채워 넣을 수 있도록 레이블이 붙은 빈 슬롯이 되며, 어차피 그쪽이 더 나은 결과입니다.
따라서 솔직하게 요약하면, 이 옵션은 한 가지 특정 상황을 구제합니다. 이미지가 모두 인라인으로 들어간 페이지를 고충실도로 가져오는 경우이며, 대개 AI 도구가 생성한 페이지입니다. 이미지가 제대로 된 URL이라면 이 옵션은 관련이 없고, 실제 최적화는 마땅히 이루어져야 할 곳, 즉 WordPress가 반응형 크기를 생성하는 미디어 라이브러리에서 이루어집니다.
중첩 깊이를 확인하세요
깊은 컨테이너 트리는 편집하기 불편할 뿐만이 아닙니다. 각 단계는 또 하나의 DOM 노드이자 또 한 묶음의 생성된 CSS 규칙입니다. 구조 맵에 깊이가 7이나 8로 표시된다면 원본을 단순화하거나 트리의 더 깊은 곳에 복사 루트를 설정하세요. 결과물이 평평할수록 더 빠르고 유지 관리하기도 쉽습니다.
글꼴
변환된 페이지는 원본이 사용한 글꼴을 그대로 지정합니다. 그것이 사이트에서 이미 불러오는 글꼴이 아니라면, 제대로 등록하거나 사이트 타이포그래피로 전환해 페이지가 이미 제공 중인 글꼴을 사용하도록 하세요. 피해야 할 것은 가져온 섹션 하나 때문에 두 번째 글꼴 패밀리를 불러오는 일입니다.
동작은 네이티브 방식으로 다시 추가하세요
스크립트는 변환 중에 제거되며, 이는 안전뿐 아니라 성능 면에서도 좋은 일입니다. 슬라이더, 탭, 카운터를 다시 만들 때는 제3자 스크립트를 다시 붙여넣지 말고 Elementor 자체 위젯을 사용하세요. 그 위젯들은 이미 불러오고 있는 번들의 일부입니다.
변환된 페이지가 자동으로 비대해지지 않는 이유
자동 변환이 페이지를 설정값으로 뒤덮고, 그 설정이 모두 CSS가 될 것이라는 걱정은 타당합니다. 두 가지가 그런 일을 막아 줍니다.
첫째, 반응형 값은 데스크톱과 다른 곳에만 기록됩니다. 모든 너비에서 패딩이 같은 컨테이너는 패딩 값을 세 개가 아니라 하나만 갖습니다. 위젯이 60개인 페이지에서는 이것이 가벼운 스타일시트와 3분의 2가 중복 규칙인 스타일시트의 차이를 만듭니다.
둘째, 아무 역할도 하지 않는 것이 확인된 래퍼는 변환되지 않고 제거됩니다. 남아 있는 모든 컨테이너는 자체 생성 규칙을 가진 실제 <div>이므로, 스타일 효과가 없는 것을 버리면 DOM 노드와 그 CSS가 함께 사라집니다.
이 가운데 어느 것도 해결하지 못하는 것은 처음부터 깊었던 원본 마크업입니다. 변환기는 HTML을 그대로 반영할 뿐, 다시 설계하지는 않습니다. 7단계 깊이의 원본은 각 단계를 아무리 신중하게 처리해도 무거운 페이지가 됩니다. 그래서 원본 단계에서 평평하게 만드는 것이 가져온 뒤의 어떤 정리보다 가치가 있습니다.
측정한 다음 정리하세요
정리 작업 전후로 페이지를 속도 테스트에 돌려 보세요. 대개 개선은 세 곳에서 나옵니다. 불필요한 스타일시트 블록 제거, 지나치게 큰 이미지 교체, 과도하게 중첩된 트리의 평탄화입니다. 어느 것도 오래 걸리지 않으며, 셋을 합치면 보통 차이의 대부분을 차지합니다.
올바른 수치를 살펴보세요. 전체 페이지 용량과 Largest Contentful Paint는 이미지 작업에 반응합니다. Cumulative Layout Shift는 이미지에 명시적인 크기가 지정되는지에 반응합니다. 미디어 라이브러리에서 채운 자리표시자에는 크기가 있지만 Base64 이미지에는 없는 경우가 많습니다. 그리고 대부분의 보고서에 표시되지만 대부분의 사람이 지나치는 DOM 노드 수가, 중첩이 통제되고 있는지를 알려 주는 수치입니다.