각 post/페이지의 로딩속도는 그 해당 post/페이지 에서 몇개의 ACF fields 를 불러오느냐에 따라 차이가 납니다.

하지만 하나의 post/페이지에서 정말 수백개의 ACF fields 를 불러오지 않는 이상 로딩속도 차이가 거이 나지 않아서 (하나가 추가될때 마다 대략 0.002 초 정도: 물론 서버사향에 따라 차이가 납니다.) 신경 쓰시지 않으셔도 됩니다.

그나저나 질문자 분 조만간 멘붕 오실 듯.

꽤 중요한 글이라서 여기 Kopress 에도 올려 놓긴 할텐데….

https://hackya.com/kr/구텐베르크-때문에-분열되는-워드프레스/ (publish 날짜는 4월 20일 (미국시간) 으로 예정되어 있습니다.)

워드프레스 5.0 에 탑재되는 구텐베르크 Editor 때문에 지금 개발자들 중 일부는 워드프레스 fork 해서 새로 살림차리자고 하는 분들도 계시고. 장난아니게 시끄럽습니다.

워드프레스 5.0 은 늦어도 7월 까지는 출시 될 예정인데….. 이 구텐베르크 Editor 가 core 에 탑재되면 질문자분 처럼 custom post type 으로 사이트/어플리케이션을 만들어 놓은 경우, 전부다 먹통이 됩니다. (compatible 하지가 않은거죠.)

예를 들면 우커머스의 제품들이 custom post type 이잖아요. 이게 먹통이 됩니다. 물론 워프 5.0 이 출시되기전 우커머스 처럼 워드프레스 소유 플러그인들은 워드프레스에서 compatibility issue 들을 해결하겠지만 다른 custom post type 은 개발자들이 알아서 해결해야 한다는…

그런데 구텐베르크 Editor 가 조낸 황당하게 (php 개발자 입장에서 황당하다는 얘기 입니다.) php 가 아니라 자스 (javascript), 그것도 극혐 react 기반이라서… 자신의 깨진 사이트, 플러그인등을 고치려면 php 개발자가 지금 자스 배우고 react 배워서 고쳐야 한다는…

아니 슈발 사이트 다 깨지는데 이걸 왜 내가 자스 고 react 을 배워서 고쳐야 하지? 이게 뭔 G랄이야? 차라리 워드프레스 fork 해서 따로 살림차리는게 낫겠다 슈발!!!! – 현재 이런 상황 입니다.

Matthew Park

Attorney, front-end developer, digital media artist, WordPress enthusiast, & a father of 4 wonderful children.

Lives in Colorado.

하나의 필드 그룹에 10개 정도라는 것은 하나의 포스트에 10개의 ACF 커스텀 필드를 출력하는 것과 볼 수 있네요.

ACF와 같은 커스텀 필드 관련 플러그인을 사용하는 주 이유는 커스텀 필드 데이터 등록 및 등록 인터페이스 구성의 편리를 위해서일 것입니다. 저는 그런 상황일 때 사용하는데, 아닐 수도 있고요.

커스텀 필드 생성 수, 그리고 싱글 포스트에 출력하는 커스텀 필드 수는 일반적으로 문제가 없습니다. 물론, 지나치면 안되겠죠.

만약, 아카이브(목록)에 20개 정도의 포스트를 출력하면서 각 포스트의 커스텀 필드 10개를 모두 출력한다면 사람이 체감할 수 있을 정도의 로드 속도가 저하됩니다. 최소 200개의 커스텀 필드를 하나의 목록 페이지에 출력하는 것이 되므로.

이때, 200개의 커스텀 필드를 모두 출력하면서 속도 저하를 최소화(체감하기 어려운)하려면 크게 2가지를 생각할 수 있습니다.

가. ACF와 같은 플러그인 제공 함수 사용하지 않고 워드프레스 함수 사용하기

ACF는 the_field, get_field 함수를 제공할 것인데, 이 함수는 결국 워드프레스 함수 get_post_meta로 연결됩니다. 이렇게 되면 200개의 커스텀 필드는 최소 400개의 함수를 호출하는 것과 같게 됩니다. 또, ACF는 제공 함수의 shortcode를 제공하여 포스트 편집화면에서 사용할 수 있게 지원하는데, 이렇게 되면 출력 시 필터의 단계가 추가되므로 로드 속도가 더 느려집니다.

따라서 get_post_meta 함수를 사용하면 일단 배가 되는 함수 호출 증가를 막을 수 있습니다. 여기서 ACF 제공 함수를 사용했을 때의 편리함은 포기해야 하는데, 2가지만 예를 들면…

ACF에서 이미지 등록 필드 출력 옵션에서 url, id, object 어느 것을 선택하더라도 데이터베이스에는 ID가 저장됩니다. URL을 선택하고 the_field 또는 get_field 함수를 사용하면 url이 출력되어 편리하지만, get_post_meta를 사용하면 id만 출력되므로 id로 이미지 url을 구하는 워드프레스 함수나 다른 코드가 필요하게 됩니다.

하나라면 문제 없지만, 그래도 필드 수가 많으면 get_post_meta 함수로 id를 구하고 다른 워드프레스 함수로 이미지 url을 구하는 게 경험해보면 더 빠릅니다.

또, textarea 필드가 있을 때는 ACF 함수 사용이 편리한데, 이것은 br, p 같은 단락 및 줄바꿈 태그 처리 때문으로, get_post_meta 함수를 사용하면 wpautop 함수 등과 조합하여 별도 출력 정의해야 합니다.

나. ACF 필드를 사용하여 필드 데이터 등록하고 포스트를 저장할 때 모든 필드 데이터를 _posts 테이블의 특정 필드(post_content 또는 post_excerpt)에 ‘시리얼(maybe_serialize)’ 데이터로 ‘추가’ 저장하고, 출력은 post_content 필드만 불러와 maybe_unserialize 후 출력

CPT(Custom Post Types) 정의하여 사용하는 콘텐츠(포스트)는 post_content, post_excerpt 필드를 사용할 필요가 없는 특징을 가진 때가 많다고 볼 수 있습니다. 아닐 수도 있고요.

모든 필드 데이터를 _posts 테이블에 존재하는 특정 필드에 추가 저장하여 다른 테이블 데이터 조회를 최소화하면 많은 필드를 사용하고 있다해도 성능 저하를 충분히 막으며 출력할 수 있습니다.

만약, 워드프레스로 메타 데이터가 많다고 예상할 수 있는 제품판매명세, 제품목록, 부동산매물목록, 중고자동차매물목록, 구인목록, 구직목록 등의 등록 및 출력 사이트를 구성하고, 리스트 형식 또는 테이블 형식으로 메타 데이터를 포함하여 출력한다면 최소한 시리얼 데이터의 추가 저장 및 출력 방법은 검토할 필요가 있습니다.

이와 같은 구성은 포스트 ID와 post_content 필드 2개만 가져와 사용할 수 있어 여러가지로 편리한 때가 많고, 구성 기술 난이도가 낮으며, 워드프레스 제공 훅이 있기에 빠르게 구성할 수 있습니다. 그리고 단순합니다. 검색은 본래의 커스텀 필드 데이터를 거쳐야 하지만, 출력은 다시 시리얼 데이터로 처리하면 됩니다.

실제로 하나의 판매명세에 포함된 커스텀 필드(메타 데이터)가 25개, 연결된 term 5개인 판매명세데이터 사이트를 이와 비슷한 방식으로 구성하여 사용하고 있는데, 포스트 ID와 post_content 필드만 사용하여 출력합니다.

보통의 공유 웹호스팅에서, 1000개의 판매명세 데이터를 목록으로 출력할 때 평균 1초가 걸리지만, 개별 필드를 사용한 방식은 오줌 한 번 재빠르게 누고 와야 합니다. 또, 1000개 기준 계산이 포함된 비교 차트를 그리는 시간이 시리얼 데이터는 평균 1초에 미치지 못하지만, 커스텀 필드 데이터를 개별적으로 사용하면 매우 느립니다.

—

나번은 아니라도 최소 가번 방식은 검토할 필요가 있습니다.

ACF와 같은 플러그인을 사용할 때 필드 이름에 ‘acf’와 같은 접두어를 사용하지 않고 이름을 정하는 것, 다른 CPT 간 필드 성격이 같다해도 CPT 이름을 접두어로 사용한 필드 이름을 생성하는 게 좋겠습니다. ACF 플러그인을 사용하지 않고 삭제할 때 등록한 커스텀 필드 데이터는 그대로 유지되므로 플러그인에 종속할 필요는 없습니다. 플러그인을 데이터 등록의 보조 기능 정도로 사용하는 게 좋습니다.

그래서 플러그인 함수보다 get_post_meta와 같은 워드프레스 함수를 사용할 것을 권장합니다.

Jinn

i wish i was..