Bubble.io 페이지가 느리다면? Element Conditional Rendering 최적화 방법
Bubble.io로 웹앱을 만들다 보면 기능이 늘어날수록 첫 화면이 늦게 나타나는 문제가 생길 수 있습니다. 버튼 몇 개를 추가했을 뿐인데 페이지가 무거워지거나, 대시보드가 열릴 때 잠시 멈추는 현상이 나타나기도 합니다.
이때 플러그인이나 데이터베이스만 의심하기 쉽지만, 실제로는 한 페이지에 배치된 많은 Element와 복잡한 표시 조건이 원인일 수 있습니다.
특히 여러 메뉴를 하나의 페이지에 넣고 조건에 따라 Group을 보여주는 방식이라면 Element Conditional Rendering 최적화가 필요합니다.
Bubble.io 페이지가 로딩되는 기본 원리
Bubble 공식 문서에 따르면 페이지를 불러올 때 대략 다음과 같은 과정이 진행됩니다.
- 페이지에 포함된 보이는 요소와 숨겨진 요소의 코드가 전달됩니다.
- 현재 화면에 보이는 요소가 브라우저에 그려집니다.
- 보이는 요소에 필요한 동적 데이터를 가져옵니다.
따라서 Element를 숨겨 놓았다고 해서 해당 요소가 페이지 구성에서 완전히 제외되는 것은 아닙니다. 다만 일반적으로 숨겨진 Element는 화면에 표시될 때까지 그려지지 않으며, 보이는 요소가 해당 Element의 Data source를 참조하지 않는다면 관련 동적 데이터도 즉시 불러오지 않습니다.
여기서 중요한 점은 Element 종류보다 페이지에 들어 있는 전체 Element 수가 성능에 더 큰 영향을 줄 수 있다는 것입니다.
단순히 투명하게 만들면 안 되는 이유
Element를 숨기기 위해 투명도만 0%로 설정하는 경우가 있습니다. 그러나 투명도 0%는 해당 요소를 실제로 숨긴 것이 아닙니다.
사용자 눈에만 보이지 않을 뿐 다음 상태가 유지됩니다.
- Element가 페이지 공간을 차지함
- 너비와 높이가 그대로 유지됨
- 화면에 존재하는 요소로 처리됨
- 연결된 동적 데이터나 조건식이 평가될 수 있음
페이지 로딩을 줄이려는 목적이라면 투명도보다 This element is visible on page load와 Conditional 설정을 이용하는 편이 적절합니다. Bubble의 Property Editor 문서에서도 0% opacity는 Element를 숨기는 기능이 아니라고 설명합니다.
1. 처음부터 필요하지 않은 Element는 숨김 상태로 시작하기
로그인 후에만 사용하는 메뉴, 상세정보 팝업, 관리자 기능처럼 첫 화면에서 필요하지 않은 요소는 다음과 같이 설정합니다.
설정 방법
- 최적화할 Group을 선택합니다.
- Appearance 또는 Visibility 설정을 확인합니다.
- This element is visible on page load를 해제합니다.
- Conditional 탭으로 이동합니다.
- 실제로 필요한 상황에서만
This element is visible을 활성화합니다.
예를 들어 관리자 전용 메뉴라면 다음과 같이 설정할 수 있습니다.
When Current User's role is admin
→ This element is visible = yes
다만 페이지가 열리자마자 사용자 정보를 검색해야 하는 조건이라면 조건식 자체도 처리 비용을 발생시킬 수 있습니다. 단순히 숨김 설정만 늘리는 것이 아니라, 조건에 포함된 검색도 함께 살펴봐야 합니다.
2. 개별 Element보다 상위 Group을 제어하기
하나의 메뉴 안에 텍스트, 아이콘, 버튼, 입력창 등 20개의 Element가 들어 있다고 가정해 보겠습니다.
각 Element에 같은 표시 조건을 반복해서 지정하면 관리하기 어려울 뿐 아니라 동일하거나 비슷한 조건이 여러 번 평가될 수 있습니다.
다음과 같은 구조가 효율적입니다.
Group Admin Panel
├─ Text Title
├─ Input Search
├─ Repeating Group Users
└─ Button Save
하위 Element마다 관리자 여부를 확인하지 않고, 가장 바깥쪽의 Group Admin Panel에 한 번만 조건을 설정합니다.
When Current User's role is admin
→ Group Admin Panel is visible
이렇게 구성하면 조건 관리가 간결해지고, 나중에 권한 기준이 변경되더라도 상위 Group의 조건만 수정하면 됩니다.
3. ‘Collapse when hidden’을 함께 설정하기
숨겨진 Group이 계속 빈 공간을 차지한다면 레이아웃이 어색해질 수 있습니다. 이때 Layout 탭의 Collapse when hidden을 활성화합니다.
이 옵션을 사용하면 Group이 숨겨졌을 때 차지하던 영역이 접히면서 아래쪽 Element가 자연스럽게 올라옵니다. Bubble 공식 문서에서도 숨겨진 Element 아래의 콘텐츠가 빈 공간을 채우도록 하는 기능으로 안내하고 있습니다.
권장 설정
- This element is visible on page load: 해제
- Collapse when hidden: 활성화
- Animate the collapse operation: 필요한 경우에만 사용
빠른 메뉴 전환이 중요하다면 접힘 애니메이션은 끄는 편이 좋습니다. 애니메이션이 많으면 실제 로딩 속도와 별개로 화면 반응이 느리게 느껴질 수 있습니다.
4. Conditional 안의 데이터 검색 줄이기
다음처럼 조건 안에서 매번 데이터베이스를 검색하는 구조는 주의해야 합니다.
When Search for Orders:count is greater than 0
→ This element is visible
이 조건이 여러 Element에 반복되면 같은 목적의 검색이 계속 실행될 가능성이 있습니다.
가능하다면 이미 불러온 데이터나 상위 Group의 값을 활용합니다.
When Parent group's User's Orders:count > 0
또는 페이지에서 한 번 확인한 값을 Custom State에 저장해 여러 Element가 공유하도록 구성할 수 있습니다.
Page Custom State: has_orders
이후에는 다음처럼 간단한 조건을 사용합니다.
When Page's has_orders is yes
→ This element is visible
단, Custom State에 검색 결과를 저장하면 해당 시점의 값이 유지될 수 있으므로 실시간 변경 반영이 필요한 데이터인지 먼저 판단해야 합니다.
5. 조건식은 빠른 검사부터 배치하기
Bubble의 조건식은 왼쪽부터 평가하며, 결과를 판단하는 데 필요한 부분까지만 처리합니다. 따라서 처리하기 쉬운 조건을 앞에 배치하는 것이 유리합니다.
다음 조건을 예로 들어보겠습니다.
Current User is logged in
and Search for Orders:first item is not empty
로그인하지 않은 사용자라면 첫 번째 검사에서 조건이 거짓이 되므로 뒤쪽의 데이터 검색을 확인할 필요가 줄어듭니다.
반대로 데이터베이스 검색을 맨 앞에 배치하면 로그아웃 상태에서도 불필요한 검색이 먼저 평가될 수 있습니다.
권장 순서
- 로그인 여부
- 입력값 존재 여부
- Custom State 또는 URL Parameter
- 현재 Group이 가진 데이터
- 데이터베이스 검색
조건의 결과가 같더라도 어떤 순서로 작성하는지에 따라 처리량이 달라질 수 있습니다.
6. 숨겨진 Element를 다른 Element에서 참조하지 않기
Group을 숨김 상태로 설정했더라도 화면에 보이는 다른 Element가 그 Group의 Data source를 참조하면 최적화 효과가 줄어들 수 있습니다.
예를 들어 다음 구조를 확인해야 합니다.
보이는 Text의 값
= Hidden Group's List of Products:count
숨겨진 Group이 가진 데이터가 필요하기 때문에 페이지 로딩 중 관련 데이터 처리가 발생할 수 있습니다.
가능하면 공통 데이터를 Page, 상위 Group 또는 별도의 상태값에서 관리하고, 보이는 Element가 숨겨진 Element를 직접 참조하지 않도록 구성합니다.
7. Repeating Group 셀 내부를 가볍게 만들기
Repeating Group은 하나의 셀 디자인을 여러 번 반복합니다. 셀 안에 Element가 10개 있고 30개 항목을 표시한다면 브라우저가 처리해야 할 화면 구성은 빠르게 늘어납니다.
다음 항목을 점검해 보는 것이 좋습니다.
- 셀 안의 장식용 Element가 꼭 필요한가?
- 같은 조건을 가진 Element를 하나의 Group으로 묶을 수 있는가?
- 셀마다 별도의
Search for가 실행되고 있지는 않은가? - 처음부터 너무 많은 항목을 표시하고 있지는 않은가?
- 모든 셀에 복잡한 Reusable Element를 넣고 있지는 않은가?
특히 각 셀 안에서 추가 검색을 실행하는 구조는 데이터가 늘어날수록 체감 속도가 크게 떨어질 수 있습니다.
8. 조건부 이미지도 자동으로 가벼워지는 것은 아니다
이미지를 조건부로 숨기면 처음에는 내려받지 않을 것이라고 생각하기 쉽습니다. 하지만 Bubble은 성능 처리 방식상 앱에서 확인 가능한 이미지를 미리 불러올 수 있으며, 여기에는 조건에 따라 표시되는 이미지도 포함될 수 있습니다.
따라서 이미지가 많은 페이지에서는 Conditional Rendering만으로 충분하지 않습니다.
- 원본 이미지를 필요한 표시 크기에 맞게 조정하기
- 불필요하게 큰 PNG 사용을 줄이기
- 같은 이미지를 여러 Element에 중복 배치하지 않기
- 상품 목록은 썸네일 이미지를 사용하기
- 첫 화면에 필요 없는 이미지 섹션을 별도 페이지로 분리하기
조건부 표시 설정과 이미지 용량 최적화를 함께 적용해야 실제 로딩 속도 개선을 기대할 수 있습니다.
9. 한 페이지에 모든 기능을 넣지 않기
Bubble에서는 Group을 숨기고 보여주는 방식으로 SPA 형태의 화면을 만들 수 있습니다. 메뉴 전환이 빠르고 자연스럽다는 장점이 있지만, 대시보드·상품관리·회원관리·통계·설정을 한 페이지에 모두 넣으면 전체 Element 수가 지나치게 많아질 수 있습니다.
기능이 커졌다면 다음 기준으로 페이지 분리를 고려합니다.
| 한 페이지 유지가 적합한 경우 | 페이지 분리가 적합한 경우 |
|---|---|
| 메뉴별 Element 수가 적을 때 | 메뉴마다 복잡한 Repeating Group이 있을 때 |
| 동일한 데이터를 공유할 때 | 각 메뉴가 별도의 검색을 많이 실행할 때 |
| 빠른 탭 전환이 중요할 때 | 첫 페이지 진입 속도가 더 중요할 때 |
| 기능 구조가 단순할 때 | 관리자 기능과 일반 사용자 기능이 함께 있을 때 |
무조건 SPA 구조가 좋은 것은 아닙니다. 사용자가 자주 이동하는 기능은 한 페이지에 두고, 무거운 통계나 관리자 메뉴는 별도 페이지로 분리하는 혼합 방식도 효과적입니다.
적용 전후 테스트 방법
최적화가 끝난 후에는 느낌만으로 판단하지 말고 동일한 조건에서 비교해야 합니다.
- 브라우저의 시크릿 창을 엽니다.
- 캐시가 없는 상태에서 페이지에 접속합니다.
- 첫 콘텐츠가 나타나는 시간을 확인합니다.
- 메뉴를 전환하면서 끊김이 있는지 살펴봅니다.
- Bubble Logs에서 반복되는 검색과 Workflow를 확인합니다.
- 모바일 네트워크 환경에서도 다시 테스트합니다.
한 번에 모든 설정을 변경하면 어떤 항목이 효과가 있었는지 알기 어렵습니다. Group 구조, 조건식, Repeating Group, 이미지 순서로 하나씩 수정한 뒤 결과를 기록하는 편이 좋습니다.
최종 점검표
다음 항목 중 해당되는 부분이 많다면 페이지 구조를 다시 살펴볼 필요가 있습니다.
- 사용하지 않는 Element가 페이지에 남아 있다.
- 숨김 처리에 opacity 0%를 사용하고 있다.
- 같은 표시 조건이 여러 하위 Element에 반복되어 있다.
- Conditional 안에
Search for가 자주 등장한다. - 보이는 Element가 숨겨진 Group의 Data source를 참조한다.
- Repeating Group의 각 셀에서 추가 검색을 실행한다.
- 첫 화면에 필요하지 않은 Group이 기본 표시 상태다.
- 고용량 이미지가 여러 개 배치되어 있다.
- 관리자와 일반 사용자 화면이 한 페이지에 모두 들어 있다.
- 숨김 Group에 민감한 URL이나 정보가 포함되어 있다.
마지막 항목은 성능뿐 아니라 보안과도 관련이 있습니다. 숨겨진 Element도 페이지 코드에 포함될 수 있으므로 API 키, 비공개 URL, 관리자 전용 정보 등을 Element에 넣어 두어서는 안 됩니다. 화면 표시 조건은 보안 장치가 아니며, 중요한 데이터는 Privacy Rules와 서버 측 조건으로 보호해야 합니다.
마무리
Bubble.io의 Element Conditional Rendering 최적화는 단순히 요소를 보이지 않게 만드는 작업이 아닙니다.
초기 화면에 필요한 Element만 표시하고, 동일한 조건은 상위 Group에서 처리하며, 조건 안의 데이터 검색과 Repeating Group 셀 구조를 줄이는 것이 핵심입니다. 여기에 이미지 용량과 페이지 분리까지 함께 적용하면 초기 로딩뿐 아니라 화면 전환 속도와 유지관리 편의성도 개선할 수 있습니다.
처음부터 완벽하게 바꾸기보다 가장 무거운 페이지 하나를 선택한 뒤 Element 수 확인 → 초기 표시 설정 → Conditional 검색 점검 → Repeating Group 정리 순서로 개선해 보세요.




댓글 0
첫 댓글을 남겨보세요.