Oxygen Builder 백엔드 로딩 시간 테스트

이 기사에서는 Oxygen Builder의 백엔드 로딩 시간을 살펴볼 것입니다. 많은 사람들이 이것을 이 WordPress PageBuilder의 주요 단점이라고 말하므로 여러 장치에서 테스트하기로 결정했습니다. 무엇이 발견되었는지 봅시다.

먼저 동일한 장치에서 서로 다른 브라우저를 비교할 것입니다. 그런 다음 동일한 브라우저를 사용하여 다른 장치를 비교합니다. 이를 통해 Oxygen Builder를 가장 빠르게 로드하는 장치뿐만 아니라 이 작업에 가장 적합한 브라우저를 식별할 수 있습니다.

이 비교에 엄청난 복잡성을 추가하므로 다른 호스팅 설정 테스트를 제외할 것입니다. 또한: 저렴한 호스팅을 사용하는 경우 WordPress 웹 사이트의 프런트 엔드와 백 엔드 모두에서 로드 시간이 느려진다는 것은 잘 알려진 사실입니다. 이것이 사실이라면 그것은 전적으로 당신에게 달려 있습니다. (그러나 우리는 미래에 이것을 다시 살펴볼 수 있습니다).

피험자

우리의 테스트 주제는 청중을 위해 우리가 만든 비교적 표준적인 산소 생성기 웹사이트입니다. 페이지의 초기 성능, 크기 및 추가 측면을 살펴 보겠습니다.

이 테스트 웹사이트는 2GB RAM 및 표준 설정이 있는 전용 DO 프리미엄 서버에서 호스팅됩니다. 속도, 비용 및 지원 면에서 권장되는 호스트인 Cloudways에서 관리합니다. 테스트 당시 사이트에서 추가 속도 최적화를 완료하지 않았습니다. 인스턴스를 가동한 후 서버 설정이 변경되지 않았습니다.

읽기: WordPress 호스팅을 위한 Cloudway의 5가지 서버 선택 분석

참고 사항: 이것은 개발 및 트래픽이 적은 사이트를 위한 훌륭한 서버 옵션으로, 시작할 때 쉽게 확장할 수 있습니다. 가입할 때 ISOTROPIC 코드를 사용하여 Cloudways 할인을 받고 3일 무료 평가판을 받으세요(CC 없음).

테스트한 페이지는 해당 웹사이트의 홈페이지입니다. 테스트 당시에는 다음과 같이 보였습니다.

로드된 페이지의 주요 요소는 Oxygen Builder 메뉴 요소, 사용자 정의 검색 표시줄, 데모 포스트의 쉬운 포스트 그리드(첫 번째 섹션), WSForm Oxygen 요소 및 내부에 반복 레이아웃이 있는 OxyExtras 캐러셀이었습니다. 이 리피터에는 MetaBox 필드를 기반으로 하는 9개 이상의 게시물과 수십 개의 조건이 있습니다.

Deals.isotropic.co 하위 도메인 DNS가 Cloudflare를 통해 프록시되므로 페이지가 공개되었습니다.

총 페이지 크기는 5.05MB였습니다. 이는 주로 테스트 당시 최적화된 이미지를 사용했기 때문입니다. 이것은 초기 단계의 개발 웹사이트라는 것을 기억하십시오. 이런 종류의 웹사이트는 일반적인 개발 환경을 시뮬레이트하는 Oxygen Builder의 백 및 로딩 속도를 테스트하는 가장 좋은 방법이라고 생각합니다.

사용중인 플러그인은 다음과 같습니다.

*여기에서 입증된 것처럼 실제로 사용하는 플러그인을 검토합니다. :)

우리가 Oxygen Builder 3.9 Beta 2를 사용하고 있었다는 점에 유의하는 것이 중요합니다 . WooCommerce 요소도 설치했지만 WooCommerce 자체는 이 시점에서 설치되지 않았습니다.

개발자 보고서에 따르면 이 버전의 Oxygen은 이전 버전보다 백엔드에서 로드하는 속도가 거의 두 배나 빠릅니다.

또한 OxyExtras, WPGridbuilder, OxyMade 및 WSForm은 모두 빌더의 백엔드에 요소를 추가했습니다. Swiss Knife, 스킨/워크플로 도구 및 Hydrogen Pack도 백엔드에 로드됩니다.

기본적으로 이 테스트 주제는 Oxygen Builder를 사용하는 많은 사람들이 로딩 경험이 있는 페이지입니다. 빌더 및 타사 플러그인 모두에서 백엔드에 로드되는 몇 가지 추가 기능, 확장 및 스크립트가 있습니다.

마지막으로 내 WiFi를 간단히 살펴보겠습니다.

이 테스트가 실행되는 방법

이 테스트는 페이지 백엔드에서 "산소로 편집"을 클릭하여 Oxygen Builder를 직접 로드하여 관리합니다.

버튼을 누르면 타이머가 시작됩니다. 톱니바퀴 아이콘이 중지되고 브라우저가 완전히 초기화되면 테스트가 중지됩니다.

iPhone 스톱워치를 사용하여 수동으로 타이밍을 측정하므로 이것이 완전히 정확하지는 않지만 이 플러그인을 가장 빠르게 로드하는 장치와 브라우저에 대한 좋은 근사치를 제공해야 합니다. 또한 주목할 가치가 있습니다. 페이지는 이전에 fontend에서 로드되었지만 백엔드 빌더에서는 관리자로 로드된 적이 없습니다 . Deals.isotropic.co를 로드하고 상단 표시줄로 이동하여 페이지 편집을 클릭한 다음 산소로 편집 버튼을 클릭하여 빌더로 이동합니다.

이 테스트의 목표는 속도 달리기가 아닙니다. 속도와 효율성에 대한 우려가 정당한지 확인하기 위해 이 플러그인의 뒷면과 로딩 시간에 대한 진정한 실제 데이터를 얻는 것입니다. 실제 시간 수치를 보는 대신 장치와 브라우저와 관련하여 이러한 수치의 차이점을 살펴보십시오.

마지막으로 충동 구매를 유도하는 Amazon 링크(제휴사)를 포함시켰습니다.

브라우저별 산소 빌더 로딩 시간

먼저 내 Mac Mini M1에 설치된 모든 브라우저에서 로드해 보겠습니다. 장치별로 테스트할 때 통계가 다시 표시되지만 이것은 Big Sur V11.3.1을 실행하는 8GB 램이 있는 2020 M1 Mac Mini입니다. 이것은 나의 "일상 데스크탑"입니다.

우리는 브라우저 테스트로 시작하여 어느 것이 산소를 로드하는 데 가장 빠른지 결정합니다. 다른 장치를 테스트할 때 이 브라우저를 사용합니다.

Safari V14.1, Chrome V95.0.4638.69 및 Firefox V94를 테스트합니다.

• Firefox는 05.59초에 시작됩니다.
• 크롬은 17.52초에 나옵니다.
• 사파리는 6.20초에 나옵니다.

Chrome은 여기서 명백한 이상점이었습니다. 로딩에 딸꾹질이 있는지 확인하기 위해 다시 실행했습니다. 두 번째 로딩에 약 16.5초 정도 소요되었기 때문에 평균이 비교적 정확한 수치라고 생각합니다.

여기서 중요한 점은 Firefox가 가장 빠른 브라우저라는 것입니다. 이것은 공식 Facebook 그룹에서 한동안 논의된 주제이므로 이 경험적 데이터가 이 브라우저를 사용해야 함을 증명하기를 바랍니다. 개인적으로 Firefox는 고품질 프론트 엔드 개발자 도구가 많기 때문에 웹 사이트를 개발할 때 가장 좋아하는 브라우저입니다. 그러나 크롬에 비해 보안 및 성능 감사가 부족합니다.

우리는 장치 테스트를 위해 해당 브라우저를 사용할 것입니다.

브라우저별 산소 빌더 로딩 시간

이 테스트에서는 동일한 Wi-Fi 네트워크에 있는 모든 장치를 사용하고 동일한 버전의 Firefox를 사용하여 이전과 동일한 페이지를 로드합니다. 차별화 요소는 장치와 그 뒤에 있는 테스트 통계입니다. 라인업입니다.

2020 Mac Mini(이미 테스트됨)

• 애플 M1 칩
• 16GB 램

05.59초 만에 산소를 로드합니다.

2019 XPS 13 9370

• 인텔 i7-8550U
• 16GB 램

11.54초 만에 산소를 로드합니다.

2020 아이패드 에어 10.9인치 MYFT2LL/A

• 애플 A14 칩
• 4GB 램

11.96초 만에 산소를 로드합니다.

읽어보기: iPad Pro에서 웹사이트를 개발할 수 있습니까?

2019 Dell Latitude 7400

• 인텔 i7 8655U
• 16GB 램

16.19초 만에 산소를 로드합니다.

2020 맥북 프로 13인치

• 인텔 코어 i5
• 16GB 램
• Intel Iris Plus 그래픽 645 1536MB

9.66초 만에 산소를 로드합니다.

2021 맥북 프로 16인치

• 애플 M1 맥스 칩
• 64GB 램

5.43초 만에 산소를 로드합니다.

모든 장치는 테스트 중에 배터리 충전기에 연결됩니다. Firefox 브라우저는 유일하게 열려 있는 앱/프로그램입니다. 내가 이 모든 장치에 액세스할 수 있는 이유가 궁금할 것입니다. 저는 개인적으로 이러한 전자 제품을 모두 소유하고 있는 것이 아니라 지역 대학에서 대여할 수 있습니다.

중요한 시사점

첫째, 여러 번 언급했듯이 이것은 불완전한 테스트입니다. 실험실 환경에서 수행되지 않았습니다. 동적 데이터가 적은 페이지는 백엔드 빌더에서 더 빨리 로드되고 동적 데이터가 더 많은 페이지는 느리게 로드됩니다. 이미지, DOM 요소 및 스크립트에 대해서도 동일합니다.

이 숫자를 임의로 사용하는 것이 좋습니다. Oxygen이 X.XX초 안에 로드될 것이라고 말하는 대신 숫자를 사용하여 브라우저와 장치를 비교하십시오.

요점 1: 브라우저 문제

Facebook이 일관되게 언급했듯이 Firefox는 Oxygen Builder를 로드하는 가장 빠른 브라우저입니다. 저는 개인적으로 Firebox 개발자 에디션을 사용합니다.

요점 2: 장치의 중요성

가장 빠른 두 장치는 Apple 실리콘을 사용하는 최신 Apple 장치입니다. 이것은 의미가 있습니다. 이 프로세서는 시장에 나와 있는 다른 프로세서보다 훨씬 빠릅니다. 그리고 그들은 그렇게 비싸지 않습니다. 기본 M1 Mac Mini는 리퍼비시 $600 미만이며 M1 Macbook Air는 $899입니다.

테이크어웨이 2B: 프로세서가 RAM보다 더 중요한 것 같습니다.

또한 프로세서가 더 강력할수록 백엔드 빌더의 로딩 시간이 더 빨라지는 것처럼 보입니다. 예를 들어 64GB RAM이 장착된 노트북은 16GB RAM이 장착된 노트북과 비슷하게 로드됩니다. 프로세서 전력이 떨어지면 빌더의 로딩 시간도 줄어듭니다.

Chromebook이나 통계가 낮은 다른 기기에서 빌더를 로드하는 것은 어려울 수 있습니다.

마지막 생각들

이 테스트의 평균 Oxygen Backend 로딩 시간은 동적 데이터가 많고 최적화되지 않은 대규모 페이지의 경우 약 10초였습니다. 또한 방대한 맞춤형 글로벌 CSS 컬렉션과 함께 페이지에 고유한 요소를 로드하는 여러 애드온이 있었습니다. 이것은 내 책에서 매우 수용 가능합니다. Collaboration 플러그인을 사용하여 빌더를 다시 로드할 필요 없이 CSS 클래스 및 전역 옵션을 동기화할 수 있는 변경 사항이 있으면 훨씬 더 수용 가능합니다.

대부분의 프로젝트에 Oxygen을 사용하는 webdev로서, 빌더의 속도는 저에게 영향을 미치지 않았지만, 가장 좋은 설정이 무엇인지 진지하게 살펴보고 싶었습니다.

자신의 비교 번호가 있는 경우 아래 의견 섹션에 자유롭게 게시하십시오.