Elementor 대 커스텀 테마: 진짜 비용

Elementor와 커스텀 테마를 둘러싼 논쟁은 대개 취향 문제로, 가끔은 진영 논리로 다뤄집니다. 둘 다 아닙니다. 이것은 비용 문제이며 그 모양은 예측 가능합니다. 페이지 빌더는 비용을 구축 단계에서 사이트의 운영 기간으로 옮깁니다. 그 거래가 이득인지는 거의 아무도 협상 테이블에 올리지 않는 두 숫자에 달려 있습니다. 사이트에 페이지가 몇 개인지, 그리고 그 페이지가 얼마나 자주 바뀌는지입니다.

논쟁이 끝나지 않는 이유는 양쪽 모두 일화로 말하기 때문입니다. 누군가는 빌더가 느리다고 말하고, 다른 누군가는 초록색 Lighthouse 점수를 올리며, 아무것도 정리되지 않습니다. 성능은 실재하는 비용이지만, 더 긴 청구서의 한 줄일 뿐입니다. 같은 청구서에는 라이선스 갱신, 플러그인 구성, 편집 처리량, 접근성 개선, 그리고 마지막에는 내 콘텐츠를 다시 꺼내오는 값까지 함께 적혀 있습니다.

Elementor는 나쁜 도구가 아닙니다. 상당히 넓은 부류의 사이트에는 정답이며, 정직한 비교라면 그 말을 먼저 해야 합니다. 유용한 질문은 빌더가 좋은지가 아니라 어디에서 수지가 맞지 않게 되는지이고, 그 경계선은 시끄러운 논쟁이 암시하는 것보다 훨씬 또렷합니다.

Elementor와 맞춤 제작 테마 중 실제로 더 싼 쪽은 어디일까요? Elementor는 구축이 싸고 운영이 비쌉니다. 맞춤 제작 테마는 그 반대입니다. 교차점은 대략 이런 지점에 있습니다. 소수의 반복되는 레이아웃으로 만든 페이지가 25개를 넘고, 이미 개발 인건비를 지불하고 있으며, 바라기만 하는 것이 아니라 반드시 충족해야 하는 성능 또는 접근성 기준이 있는 경우입니다. 그 선 아래에서는 총비용에서 빌더가 대체로 이깁니다. 그 위에서는 구축에서 아낀 돈이 2년에서 3년 안에 소진됩니다.

페이지 빌더가 출력물에 실제로 하는 일

빌더가 느리다고 단언하는 것은 쓸모가 없습니다. 느리지 않을 때도 있기 때문입니다. 안정적인 것은 작동 방식이고, 거기에는 세 부분이 있습니다. 각각은 확실성이 아니라 경향이며, 그래서 스크린숏 공방으로는 아무것도 결론이 나지 않습니다.

문서의 깊이

비주얼 빌더는 레이아웃을 컨테이너로 표현해야 하고, 컨테이너는 곧 요소입니다. 섹션이 칼럼을 담고, 칼럼이 위젯을 담고, 위젯은 자기 래퍼와 그 내용을 담습니다. 손으로 쓴 마크업이라면 두세 개 요소로 표현할 디자인을 빌더는 여섯이나 일곱 개로 뱉어냅니다.

그 깊이는 공짜가 아닙니다. 스타일 재계산, 레이아웃, 페인트는 모두 브라우저가 훑어야 하는 노드 수와 그 노드에 일치하는 선택자의 복잡도에 따라 늘어납니다. DOM 크기와 상호작용성에 관한 Google의 안내는 실용적인 기준을 제시합니다. Lighthouse는 800개 노드를 넘으면 경고하기 시작하고, 1,400개를 넘는 페이지는 과도하다고 봅니다. 빌더 페이지는 1,400을 일상적으로 넘고, 슬라이더 여러 개와 메가 메뉴를 갖춘 긴 페이지는 3천에서 4천 개에 이르기도 합니다.

이 비용은 두 번 지불됩니다. 한 번은 첫 렌더링에서, 또 한 번은 트리를 바꾸는 모든 상호작용에서입니다. 아코디언을 열거나 목록을 걸러낼 때마다 브라우저가 같은 작업을 다시 수행해야 하기 때문입니다.

페이지마다 생성되는 스타일시트

CSS 렌더링 성능에 관한 Elementor 자체 기술 글은 두 가지 출력 방식을 솔직하게 설명합니다. CSS는 문서 안의 <style> 태그로 출력되거나, 페이지와 함께 불러오는 파일로 기록됩니다. 파일 출력은 정적이며 페이지가 바뀔 때만 다시 생성됩니다.

두 방식 모두 놓치기 쉬운 비용이 있습니다. 스타일이 사이트 전체에서 공유되지 않고 페이지마다 생성되므로, 방문자가 홈페이지에서 서비스 페이지로 이동하면 캐시된 것을 재사용하는 대신 새 스타일시트를 내려받습니다. 내부 삽입 방식에서는 CSS가 요청할 때마다 HTML 안에 실려 오기 때문에 문서가 커지고 캐싱은 완전히 무력화됩니다.

손으로 만든 테마는 이것을 뒤집습니다. 스타일시트는 하나, 캐시는 한 번, 어디서나 재사용되며, 방문자가 여는 두 번째 페이지의 CSS 비용은 거의 0입니다.

레이아웃이 확정되기 전에 실행되는 스크립트

위젯은 저마다 자기 JavaScript를 가지고 다닙니다. 슬라이더, 탭, 아코디언, 카운터, 팝업, 폼은 모두 핸들러를 등록하고, 그중 몇몇은 최종 크기를 실행 시점에 결정합니다. 스크립트가 실행되기 전까지 콘텐츠의 위치를 알 수 없을 때 브라우저는 한 번 그린 뒤 다시 다른 레이아웃을 그립니다.

이것이 전형적인 레이아웃 시프트 패턴이고, 크기가 지정되지 않은 미디어와 늦게 불러오는 웹 폰트가 겹치면 더 심해집니다. 고칠 수 없는 것은 없지만 수정은 위젯 단위이고, 페이지를 편집할 때마다 다시 해야 하며, 페이지를 편집하는 사람은 대개 그 수정을 적용한 사람이 아닙니다.

Core Web Vitals, 그리고 빌더가 실제로 악화시키는 지표

먼저 지표 목록을 정확히 잡아야 합니다. 빌더에 관한 논평의 상당수가 이제는 존재하지 않는 지표를 두고 여전히 다투고 있기 때문입니다. Core Web Vitals는 세 가지이고, Google의 정의는 좋은 경험의 기준값을 정확히 제시합니다. Largest Contentful Paint는 페이지 로드가 시작된 뒤 2.5초 이내에 일어나야 하고, Interaction to Next Paint는 200밀리초 이하여야 하며, Cumulative Layout Shift는 0.1 이하여야 합니다. 세 가지 모두 페이지 로드의 75번째 백분위수에서, 모바일과 데스크톱을 나누어 평가합니다.

First Input Delay는 사라졌습니다. Interaction to Next Paint가 2024년 3월 12일에 안정된 Core Web Vital로 그것을 대체했고, 이 변화는 여기서 중요합니다. FID는 첫 상호작용이 처리되기까지의 지연만 측정했기 때문에 무거운 페이지를 실제보다 좋아 보이게 만들었습니다. INP는 입력에서 다음에 그려지는 프레임까지의 전체 경로를 페이지의 여러 상호작용에 걸쳐 측정하고, 최악에 가까운 값을 고릅니다.

왜 INP가 끝까지 저항하는 지표인가

Largest Contentful Paint는 대체로 전달의 문제입니다. 더 나은 호스팅, CDN, 적절한 크기로 압축한 이미지, 미리 불러온 히어로 이미지, 렌더링을 막는 리소스의 감소만으로 대부분의 빌더 사이트는 빌더 자체를 건드리지 않고도 2.5초 아래로 들어옵니다.

Cumulative Layout Shift는 규율의 문제입니다. 미디어에 크기를 지정하고, 나중에 삽입되는 것의 자리를 미리 확보하고, 페이지를 다시 흐르게 하지 않도록 폰트를 불러오면 0.1은 닿을 수 있는 값입니다.

Interaction to Next Paint는 구조의 문제입니다. 이것은 응답하기 전에 메인 스레드가 처리해야 하는 작업량을 측정하는데, 깊은 마크업과 위젯 스크립트 더미가 바로 그 작업입니다. 캐시로 우회할 수 없고 빠른 서버도 도움이 되지 않습니다. Elementor 페이지와 군더더기 없는 맞춤 테마가 가장 크게 갈리는 지표가 이것이며, 쉬운 최적화를 마친 뒤에도 계속 갈린 채로 남는 지표도 이것입니다. 저희 WordPress 성능 감사 가이드는 운영 중인 사이트에서 이 세 문제를 분리하는 방법을 다룹니다.

실제로 좋아진 부분

여기서 공정한 것은 예의가 아니라 정확성의 문제입니다. Elementor를 향한 비판의 상당 부분이 2019년판 Elementor를 향한 것이기 때문입니다.

Elementor는 현재 WordPress 플러그인 디렉터리에서 버전 4.2.4로 배포되며, WordPress 6.8 이상과 PHP 7.4 이상을 요구하고, 천만 건이 넘는 활성 설치를 보고합니다. 편집기 V4는 Elementor가 원자 요소라고 부르는 것을 중심으로 요소 아키텍처를 다시 만들었고, CSS 우선 접근을 택했으며, 회사 자신의 표현을 빌리면 “레거시 DOM 비대화의 부담” 없이 동작합니다. Elementor는 Atomic Editor가 4.0부터 모든 신규 웹사이트의 기본 경험이라고 밝히고 있습니다.

머리기사보다 중요한 단서가 둘 있습니다. 첫째, 기존 사이트는 업데이트한다고 그것을 얻지 못합니다. Elementor는 4.0으로의 업데이트가 현재 운영 중인 사이트에 영향을 주지 않으며 새 기능은 수동으로 활성화한다고 명시하고 있어서, 2022년에 만든 사이트는 누군가 다시 만들기 전까지 2022년의 출력물을 그대로 유지합니다. 둘째, 마이그레이션 중에는 V3와 V4 요소가 같은 페이지에 공존하므로, 부분적으로만 옮겨진 페이지는 두 아키텍처와 두 몫의 부담을 함께 지게 됩니다.

이 개선은 실제이고 앞을 내다본 것으로 받아들이십시오. 그것은 새 Elementor 사이트가 무엇이 될 수 있는지를 바꿉니다. 지금 여러분이 가진 사이트가 어떤 상태인지를 바꾸지는 않습니다.

종속 구조를 제대로 설명하면

이것은 빌더에 대한 가장 강력한 반론이면서도 거의 언제나 잘못 설명됩니다. 흔한 버전, 즉 깨진 숏코드가 가득한 화면이 남는다는 이야기는 실제로 일어나는 일과 조금 다르고 쉽게 반박당합니다. 정확한 버전은 그보다 나쁩니다.

Elementor의 데이터 구조 문서는 여러분의 페이지가 어디에 있는지 정확히 말해 줍니다. 편집기는 페이지 데이터와 레이아웃을 JSON 형식으로 WordPress 글 메타데이터로, 즉 wp_postmeta 테이블에 저장하며, 문서는 그것이 WordPress 관리자 화면에 보이지 않는 비공개 사용자 정의 필드로 저장된다고 적고 있습니다. 여러분의 레이아웃과 스타일, 그리고 본문의 상당 부분이 Elementor만 읽을 수 있는 직렬화된 구조 안에 들어 있습니다.

그것을 WordPress 코어와 비교해 보십시오. 블록 편집기는 블록을 post_content에 직렬화해 HTML 주석 구분자를 가진 HTML로 저장하고, 속성은 주석 안의 JSON 리터럴로 실어 나릅니다. 코어가 내세운 목표는 읽을 수 있는 상태를 유지하고 WordPress 콘텐츠를 다루는 다른 모든 것과 호환되는 단일 진실 공급원입니다. 블록 편집기를 걷어내도 콘텐츠 필드에는 유효한 HTML이 남습니다.

차이는 그것이 전부입니다. 한쪽 시스템은 여러분의 콘텐츠를 WordPress가 늘 콘텐츠를 두어 온 자리에 둡니다. 다른 쪽은 그 옆의 비공개 필드에 둡니다.

3년 뒤 리뉴얼에 이것이 뜻하는 바

Elementor를 비활성화해도 페이지는 우아하게 저하되지 않습니다. WordPress는 post_content를 렌더링하는데, 빌더 페이지에서 그것은 대개 비어 있거나 조각뿐이므로 페이지는 소박해지는 것이 아니라 백지가 됩니다. 아무것도 삭제되지 않았지만 아무것도 렌더링되지 않습니다.

실무적으로 이것은 리뉴얼을 두 개의 프로젝트로 바꿉니다. 여러분은 테마를 바꾸는 것이 아니라 콘텐츠 마이그레이션을 수행하게 됩니다. 페이지마다 렌더링된 HTML을 추출하거나 JSON을 파싱한 다음, 새 시스템에서 각 레이아웃을 다시 만드는 일입니다. 마이그레이션으로 예산을 잡으면 감당할 수 있습니다. 리뉴얼 도중에 이것을 발견하면 일정을 날려 버리는 바로 그 요인이 됩니다. 같은 규율이 CMS 마이그레이션에도 그대로 적용되며, 결과를 결정하는 작업은 무엇인가를 꺼 버리기 전에 이루어집니다.

Elementor를 위한 정직한 변론

빌더가 타협이 아니라 올바른 엔지니어링 결정이 되는 사이트 부류가 실제로 있고, 그것은 큰 부류입니다.

10페이지에서 20페이지 규모의 소개형 사이트. 사내 개발자가 없고 채용할 생각도 없는 조직. 티켓과 브랜치와 배포를 거치지 않고 오늘 오후에 제목을 바꾸고 사진을 교체하고 랜딩 페이지를 발행해야 하는 마케팅 담당자. 맞춤 제작에는 정말로 닿지 않는 예산이어서, 대안이 더 나은 사이트가 아니라 더 나쁜 사이트이거나 아예 없는 사이트인 경우입니다.

이런 조건에서 빌더는 개발자 의존을 구독료로 바꿔 주며, 그것은 대개 좋은 거래입니다. 조직의 누구도 업데이트할 수 없는 사이트는, 조금 무겁더라도 마케팅 팀이 온전히 소유하는 사이트보다 못한 자산입니다. 맞춤 제작 노선의 실패 양상은 느림이 아니라, 모든 변경이 외부 사람을 필요로 하는 탓에 사이트가 낡아 가는 것입니다.

정직한 이유가 하나 더 있습니다. 첫 매출까지의 속도입니다. 3개월이 아니라 3주 만에 신뢰할 만한 사이트를 띄우는 일에는 어떤 Core Web Vitals 수치도 담아내지 못하는 가치가 있고, 신생 사업에는 그 가치가 위에서 논한 모든 것보다 큰 경우가 많습니다.

Elementor와 커스텀 테마를 가르는 판단 기준

일반적인 사이트가 아니라 여러분의 사이트에 적용할 수 있는 기준을 제시합니다. 다음 여섯 가지를 채점하고, 세 개 이상이면 빌더가 절약하는 것보다 더 많은 비용을 만들기 시작하는 지점으로 보십시오.

페이지 수 대 템플릿 수. 서로 다른 레이아웃이 여덟 종류가 채 안 되는데 페이지가 25개를 넘는다면, 여러분은 반복에 값을 치르고 있는 것입니다. 테마는 그 반복을 한 번만 표현하고, 빌더는 25곳에서 유지보수하게 만듭니다.

편집 처리량. 주당 콘텐츠 변경이 몇 건을 넘고 그것을 한 사람 이상이 수행한다면, 편집 경험보다 도구와 검토 절차가 더 중요해집니다.

이미 존재하는 디자인 시스템. Figma에 진짜 토큰 세트가 있다면 테마는 그것을 한 번 코드로 옮겨 강제할 수 있습니다. 빌더는 아무것도 강제하지 못합니다. 모든 페이지가 모든 것을 덮어쓸 수 있기 때문입니다.

다국어 콘텐츠. 언어가 늘어날 때마다 유지해야 할 빌더 구조가 배로 늘고, 번역 플러그인은 post_content 바깥에 저장된 레이아웃과 궁합이 나쁩니다.

계약으로 정해진 성능 예산. Core Web Vitals가 입찰 문서나 SLA, 고객 계약에 등장한다면, 바라는 수치가 아니라 스스로 통제하는 하한선이 필요합니다.

접근성 의무. 아래에서 다루지만, 이것 하나만으로도 결정적인 경우가 많습니다.

어느 것도 해당하지 않는다면 빌더를 쓰고 아낀 돈을 콘텐츠에 쓰십시오. 네 개 이상 해당한다면 맞춤 제작 테마는 사치가 아니라 사이트의 수명 전체에서 더 저렴한 선택지입니다.

대부분의 비교가 건너뛰는 중간 길

세 번째 선택지가 있습니다. 맞춤 제작 테마도 아니고 서드파티 빌더도 아닙니다. WordPress 코어는 2022년 1월 5.9 버전부터 전체 사이트 편집을 제공해 왔고, 사이트 편집기는 이제 제품의 성숙한 일부입니다.

중요한 제약은 WordPress 사이트 편집기 문서에 담담하게 적혀 있습니다. 사이트 편집기는 블록 테마를 설치하고 활성화했을 때만 사용할 수 있습니다. 활성화하면 편집자는 아이덴티티, 스타일, 페이지, 내비게이션, 패턴, 템플릿을 다룰 수 있고, WordPress 6.3부터는 그 안에서 페이지를 관리하고 편집할 수 있습니다. 전역 스타일, 타이포그래피, 색상 팔레트, 레이아웃은 테마의 theme.json에서 한 번 설정되어 사이트 전체에 적용됩니다.

이것이 해결하는 것은 빌더가 지닌 진짜 가치의 대부분입니다. 마케팅은 페이지를 바꾸고 헤더를 편집하고 사이트 스타일을 다시 잡아 배포 없이 발행할 수 있습니다. 게다가 빌더가 주지 못하는 것도 함께 얻습니다. 콘텐츠는 post_content에 있고, 디자인 시스템은 개발자가 정의하며, 서드파티 라이선스가 없고, 사이트 편집기의 내보내기는 템플릿과 스타일을 포함한 테마 압축 파일을 만들어 냅니다.

해결하지 못하는 것은 규율입니다. 느슨한 theme.json과 서드파티 블록 플러그인 더미를 가진 블록 테마는 빌더의 문제를 코어 안에서 그대로 재현하며, 종속도 함께 재현합니다. 그 블록들은 플러그인이 떠날 때 여러분의 페이지를 함께 떠나기 때문입니다. 또한 제대로 세팅하려면 여전히 개발자가 필요하고, 기존 Elementor 사이트를 그 위로 옮기는 일은 여전히 콘텐츠 마이그레이션입니다.

접근성, 빌더가 조용히 실패하는 지점

이것은 아무도 시연하지 않는 실패 양상이며, 느린 페이지가 아니라 법적 문제로 번지는 쪽의 실패입니다.

제목 순서가 의미가 아니라 레이아웃을 따릅니다. 편집자가 H2는 너무 커 보인다는 이유로 H3을 고르면 문서 개요는 더 이상 내용을 설명하지 못합니다. 그것이 WCAG 2.2의 성공 기준 1.3.1 정보와 관계, 레벨 A이며, 그 위에 2.4.6 제목과 레이블, 레벨 AA가 얹힙니다. 빌더 안에는 그것을 막을 장치가 없습니다. 제목 컨트롤 자체가 스타일 컨트롤이기 때문입니다.

대비 기본값. 1.4.3 대비(최소), 레벨 AA는 일반 텍스트에 최소 4.5:1, 큰 텍스트에 3:1의 비율을 요구하고, 1.4.11 텍스트 아닌 콘텐츠의 대비는 인터페이스 구성요소와 그래픽 개체에 대해 인접한 색상 대비 최소 3:1을 요구합니다. 흰 배경 위의 옅은 회색 본문과 색을 깐 섹션 위의 흐린 아이콘은 저희가 빌더 사이트에서 가장 자주 발견하는 두 가지 실패이며, 둘 다 시연에서 보기 좋았던 템플릿에서 그대로 넘어옵니다.

중첩된 컨테이너 안의 초점 순서. 2.4.3 초점 순서, 레벨 A는 초점을 받을 수 있는 구성요소가 의미와 조작 가능성을 지키는 순서로 초점을 받도록 요구하고, 2.4.7 초점 시각화, 레벨 AA는 보이는 초점 표시를 요구합니다. 깊게 중첩된 컨테이너, 절대 위치의 오버레이, 팝업은 이 둘을 일상적으로 깨뜨리며, 빌더용 테마는 지저분해 보인다는 이유로 기본 초점 윤곽선을 제거해 두는 일이 잦습니다.

영국에서 이것은 상당수 조직에 선택 사항이 아닙니다. GOV.UK 안내는 공공 부문 기관이 2018년 공공 부문 기관(웹사이트 및 모바일 애플리케이션)(제2호) 접근성 규정에 따라 WCAG 2.2 레벨 AA를 충족하고 접근성 성명을 게시해야 한다고 명시합니다. 그 요구는 공급업체 질의서를 통해 민간 부문 조달로도 점점 번지고 있습니다. 생성된 마크업을 고치는 일은 직접 쓴 마크업을 고치는 일보다 확연히 어렵습니다.

각 경로가 실제로 드는 비용

직접 확인할 수 있는 라이선스 항목

라이선스 가격부터 봅니다. 이 절에서 저희가 만든 것이 아닌 유일한 숫자이기 때문입니다. Elementor는 가격을 파운드로 직접 공개하므로 환산은 전혀 없습니다. Elementor 가격 페이지를 2026년 9월 2일에 확인한 시점에서 연간 요금제는 Essential이 연 GBP 48, Advanced Solo가 연 GBP 72, Advanced가 연 GBP 84, Expert가 연 GBP 168입니다. 더 새로운 묶음 등급은 Elementor One이 연 GBP 144, One Agency가 연 GBP 348입니다.

아래의 나머지 숫자는 저희가 제시하는 가격대이며 공개된 수치가 아닙니다. 또한 이커머스 구축이 아니라 영국의 중소 규모 사업 사이트를 전제로 합니다.

구축비, 운영비, 그리고 끝에 오는 리뉴얼

표는 요약일 뿐이니 산문으로 읽으십시오. 빌더 사이트는 구축비가 세 배 이상 싸고 운영비가 가장 비쌉니다. 연간 금액이 Elementor 라이선스에 더해 거의 항상 따라오는 유료 애드온, 그 주위에서 자라나는 플러그인 구성, 그리고 결코 끝나지 않는 주기적 성능 작업까지 함께 지고 있기 때문입니다.

비교가 결판나는 곳은 리뉴얼 열입니다. 빌더 사이트를 다시 만드는 비용은 테마 사이트를 다시 만드는 비용보다 큽니다. 이유는 위에서 말한 대로, 다시 만들기 전에 콘텐츠를 꺼내야 하기 때문입니다. 5년을 놓고 보면 GBP 4,000짜리 빌더 사이트와 GBP 20,000짜리 맞춤 제작 사이트는 양쪽이 예상하는 것보다 가까운 지점에 놓이며, 어느 쪽이 이기는지는 취향이 아니라 페이지 수와 편집 빈도가 결정합니다. 저희 웹사이트 비용 분석은 더 큰 규모에서 이 가격대가 어떻게 움직이는지 다루고, 웹사이트 개발 서비스 페이지는 맞춤 제작에 무엇이 포함되는지 정리합니다.

이미 빌더 위에 있고 벗어나고 싶다면

순서를 제대로 잡으면 마이그레이션은 감당할 만하고, 잘못 잡으면 고통스럽습니다.

계획보다 먼저 재고 조사를 시작하십시오. 글 메타를 조회해 어떤 페이지가 실제로 빌더 데이터를 가지고 있는지 찾으십시오. 대부분의 사이트에서 그 수는 예상보다 훨씬 적고, 블로그 글은 대개 이미 순수한 콘텐츠입니다. 그다음 분류합니다. 다시 만들 것, 변환할 것, 삭제할 것. 대부분의 사이트에는 1년 동안 아무도 방문하지 않았고 마이그레이션 비용을 들일 이유도 없는 페이지가 길게 꼬리처럼 남아 있습니다.

다시 만들기 전에 추출하십시오. 살아남을 페이지를 하나씩 렌더링해 HTML을 보관하거나 글 메타에서 JSON을 파싱해, 플러그인과 무관한 형태로 콘텐츠를 확보하십시오. 손으로 다시 만들 예정인 페이지에 대해서도 그렇게 하십시오. 플러그인이 떠나고 나면 그것이 유일한 사본이기 때문입니다.

URL은 유지하십시오. 재구축은 주소를 바꿀 이유가 되지 못하며, 바뀐 주소마다 그에 대응하는 구체적인 페이지로의 리디렉션이 필요합니다.

그다음 작업을 페이지 단위로 진행하고, 마지막 페이지가 떠날 때까지 Elementor를 설치된 상태로 두며, Interaction to Next Paint를 실험실 점수가 아니라 실제 현장 데이터로 전후 측정하십시오. 빠른 노트북에서의 실험실 점수는 애초에 문제가 없었다고 말해 줄 뿐입니다.

결론은 어디에 놓이는가

이 선택은 이념 문제가 아닙니다. 빌더는 작고 변화가 느리며 개발자가 없는 사이트에 정당한 답이고, 개발자들이 인정하고 싶어 하는 것보다 훨씬 자주 옳은 답입니다. 페이지 수, 템플릿 재사용, 편집 처리량, 또는 확고한 성능이나 접근성 요구가 그림 안에 들어오는 순간 그것은 더 이상 옳은 답이 아니며, 그 지점을 지나 계속 남아 있는 비용은 조용히 지불됩니다. 해마다 라이선스로, 개선 작업으로, 그리고 마지막에는 마이그레이션으로.

Mecanik은 둘 다 만듭니다. 경제적으로 타당한 고객에게는 빌더 사이트를 운영해 드리고, 더 이상 타당하지 않게 되면 교체합니다. 교체 대상은 대개 완전한 맞춤 제작이 아니라 코어 위의 블록 테마입니다. 여러분의 사이트가 이 선의 어느 쪽에 있는지 솔직한 답을 원하신다면 웹사이트 개발과 WordPress 개발 페이지에 저희가 범위를 잡는 방식이 정리되어 있고, WordPress 개발자를 고용할 때 무엇을 물어야 하는지에 관한 가이드는 저희를 포함해 상대를 어떻게 검증할지 다룹니다.

자주 묻는 질문

Elementor는 SEO에 나쁜가요? 아닙니다. Elementor는 색인을 막지 않으며, 잘 만든 Elementor 페이지는 다른 페이지와 똑같이 순위가 매겨집니다. 검색에 주는 압박은 간접적이고 Core Web Vitals, 주로 Interaction to Next Paint에 나타납니다. 깊게 생성된 마크업과 위젯 스크립트가 메인 스레드에 더 많은 일을 주기 때문입니다. Vitals는 여러 입력 중 하나이므로, 내용이 더 좋은 느린 빌더 페이지가 내용이 부실한 빠른 페이지를 여전히 이깁니다.

Elementor를 비활성화하면 페이지는 어떻게 되나요? 레이아웃이 사라집니다. Elementor는 페이지 구조를 post_content가 아니라 wp_postmeta 테이블의 비공개 사용자 정의 필드에 JSON으로 보관하므로, 플러그인을 끄면 WordPress는 post_content에 든 것만 렌더링하게 되는데 빌더 페이지에서 그것은 대개 비어 있거나 조각뿐입니다. 아무것도 삭제되지 않지만 아무것도 표시되지 않으며, 페이지를 되살리는 일은 테마 교체가 아니라 데이터 마이그레이션입니다.

영국에서 커스텀 WordPress 테마 비용은 얼마인가요? 저희가 제시하는 가격대는 맞춤 제작 테마가 대략 GBP 12,000에서 GBP 40,000, WordPress 코어 위에 만든 블록 테마가 GBP 6,000에서 GBP 18,000, 빌더 사이트가 GBP 2,000에서 GBP 6,000입니다. 맞춤 제작 수치는 첫날에 가장 나빠 보이고 5년을 놓고 보면 가장 좋습니다. 라이선스가 없고 플러그인 구성이 작으며 마지막 리뉴얼이 훨씬 싸기 때문입니다.

Elementor 사이트도 Core Web Vitals를 통과할 수 있나요? 통과할 수 있고 실제로 많이 통과합니다. Largest Contentful Paint 2.5초 미만과 Cumulative Layout Shift 0.1 미만은 좋은 호스팅과 크기를 지정한 미디어, 위젯 절제만으로 대체로 닿을 수 있습니다. 저항하는 것은 200밀리초 미만의 Interaction to Next Paint인데, 이것은 전달이 아니라 메인 스레드 작업량을 반영하며 빌더 마크업과 위젯 스크립트가 가장 큰 대가를 치르게 하는 지표입니다.

블록 테마가 Elementor보다 나은 대안인가요? 많은 경우 그렇고, 대부분의 비교가 건너뛰는 선택지입니다. 블록 콘텐츠는 주석 구분자를 가진 HTML로 post_content에 저장되어 테마를 바꿔도 살아남고, 사이트 편집기는 마케팅이 배포 없이 템플릿과 스타일을 편집하게 해 줍니다. 다만 수고가 없지는 않습니다. 사이트 편집기에는 블록 테마가 필요하고, 누군가 디자인 시스템을 제대로 정의하지 않으면 같은 문제를 코어 안에서 다시 만든 셈이 됩니다.