웹사이트가 느리게 열리는 이유, 디자인 문제일까 개발 문제일까? 이 질문은 기업 웹사이트를 운영하는 사람이라면 거의 모두 한 번쯤 겪게 됩니다. 사장님이 공식 홈페이지를 열었는데 5초 동안 로딩만 돌아가면, 첫 반응은 대개 「서버가 너무 안 좋은 거 아닌가」입니다. 하지만 실제로는 서버가 일부일 뿐이고, 디자인과 개발이 각각 큰 비중을 차지합니다.
제가 본 전형적인 사례가 있습니다. 장비를 만드는 회사인데, 홈페이지를 리뉴얼한 후 첫 페이지 로딩이 2초에서 8초로 늘어났습니다. 사장님은 데이터센터 문제라고 생각해서 서버 업체를 두 곳이나 바꿨지만 여전히 느렸습니다. 결국 원인은 디자인 시안에 첫 페이지에 고화질 대형 이미지 12장을 넣었고, 개발 쪽에서 압축과 지연 로딩을 구현하지 않아 첫 화면에서 한 번에 30개 이상의 리소스를 요청한 것이었습니다.
그래서 이 문제는 감으로 답할 수 없습니다. 아래에서 점검 순서에 따라 하나씩 풀어보겠습니다.
1. 먼저 「느림」의 세 가지 유형을 구분하자
느리게 열리는 것은 하나의 병이 아니라, 최소 세 가지로 나뉩니다:
- 첫 화면 흰 화면이 오래 지속됨: 링크를 클릭한 후 오랫동안 빈 화면이 보이는 경우로, 보통 리소스 용량이 크거나, API가 느리거나, 스크립트가 차단하고 있을 때 발생합니다.
- 열리긴 하지만 인터랙션이 버벅임: 페이지는 나오지만 스크롤, 클릭, 탭 전환이 버벅이는 경우로, 대부분 프런트엔드 로직이나 애니메이션이 너무 무겁게 작성된 것입니다.
- 때때로 빠르고 때때로 느림: 낮에는 느리고 밤에는 빠르거나, 특정 지역에서 느린 경우로, 대부분 대역폭, CDN, 서버 설정 문제입니다.
먼저 어떤 유형인지 파악한 후 책임 소재를 논해야 합니다. 그렇지 않으면 「디자인은 개발이 최적화를 안 했다고, 개발은 디자인 시안이 너무 크다고」 서로 책임을 떠넘기는 상황이 쉽게 발생합니다.
2. 디자인 단계: 시안이 처음부터 문제를 심어놓았을 수 있다
디자인은 예쁘게 그리는 것만이 아닙니다. 디자인 결정이 페이지 무게를 직접 결정합니다. 흔한 함정은 다음과 같습니다:
1. 첫 화면 대형 이미지가 비현실적임: 4K 메인 비주얼 한 장을 첫 화면에 바로 넣고, 압축도 하지 말라고 요구합니다.
2. 폰트를 너무 많이 사용함: 한 페이지에 중국어 폰트를 네다섯 종류 도입하고, 각각 수백 KB라면 로딩이 느릴 수밖에 없습니다.
3. 애니메이션 과다 중첩: 진입 애니메이션, 스크롤 애니메이션, 시차 효과를 모두 넣으면 모바일에서 바로 버벅입니다.
4. 이미지 규격 설명이 없음: 디자인 시안은 효과만 제공하고 크기와 포맷 제안을 하지 않아, 개발자는 그대로 옮길 수밖에 없습니다.
함정을 피하는 방법은 간단합니다. 디자인 단계에서 첫 화면 메인 이미지는 300KB 이하, 전체 사이트 중국어 폰트는 두 세트 이하, 애니메이션은 필요한 한두 개만 유지하기로 합의하면 됩니다. 이는 창의성을 제한하는 것이 아니라, 창의성이 실제로 작동할 수 있게 만드는 것입니다.
3. 개발 단계: 성능 문제는 대부분 이 몇 곳에서 발생한다
디자인 시안 자체에 문제가 없다면, 웹사이트 개발 단계를 봐야 합니다. 흔한 성능 약점은 다음과 같습니다:
- 이미지 압축 없음, WebP 변환 없음, 지연 로딩 없음: 가장 흔하고 가장 고치기 쉬운 유형입니다.
- API 직렬 호출: 첫 페이지가 A API 응답을 기다린 후에야 B API를 요청해서, 몇백 밀리초를 불필요하게 더 기다립니다.
- 서드파티 스크립트 과다: 통계, 고객센터, 지도, 광고 플러그인이 각각 하나씩 붙어서, 모두 첫 화면을 느리게 만듭니다.
- 캐시 전략 없음: 매번 접속할 때마다 전체 데이터를 다시 가져와서 서버 부담도 크고 사용자도 오래 기다립니다.
- 프런트엔드 번들 분할 없음: 몇 MB짜리 JS 파일을 한 번에 로드하면 첫 화면이 반드시 느립니다.
여기에 판단 팁이 하나 있습니다. 브라우저 개발자 도구의 Network 패널을 보세요. 첫 화면 요청 수가 50개를 넘거나 단일 리소스가 1MB를 넘으면, 기본적으로 개발 최적화가 제대로 안 된 것으로 볼 수 있습니다.
4. 서버와 배포: 유일한 원인으로 보지도 말고, 무시하지도 말자
서버도 확실히 속도에 영향을 주지만, 보통 첫 화면이 느린 주원인은 아닙니다. 주목해야 할 점은 다음과 같습니다:
- 대역폭이 충분한지, 특히 이미지가 많은 기업 웹사이트에서 중요합니다.
- CDN을 적용했는지, 정적 리소스가 사용자와 가까운 노드로 분산되었는지.
- 데이터베이스 쿼리에 슬로우 쿼리가 있는지, 특히 백오피스 관리 시스템에서 두드러집니다.
- Gzip 또는 Brotli 압축을 켰는지.
흔한 오해는 큰돈을 들여 서버를 업그레이드하면서 이미지 압축은 하지 않는 것입니다. 결과적으로 돈은 썼는데 속도는 조금만 빨라집니다. 순서는 먼저 프런트엔드 리소스를 최적화하고, 그다음 사양 업그레이드를 고려하는 것이어야 합니다.
5. 구체적 사례: 예약 미니프로그램과 백오피스 시스템은 왜 느릴까
기업 웹사이트뿐만 아니라 미니프로그램 개발과 App 개발에서도 같은 문제가 발생합니다.
예를 들어 예약 미니프로그램에서 사용자가 열면 예약 가능 시간이 표시되기까지 3초를 기다려야 했습니다. 점검해보니 페이지 진입 시 매장 목록, 서비스 항목, 사용자 정보, 예약 가능 시간대 네 개의 API를 동시에 요청하고 있었고 캐시도 없었습니다. 스켈레톤 화면을 먼저 렌더링하고, API를 병렬 요청하고, 시간대 데이터를 로컬 캐시하도록 바꾼 후 첫 화면이 1초 이내로 줄었습니다.
또 다른 예로 백오피스 관리 시스템에서 목록 페이지가 페이지를 넘길 때마다 전체 테이블을 다시 조회했습니다. 인덱스를 추가하고 페이지네이션 캐시를 적용한 후 응답 시간이 4초에서 300밀리초로 줄었습니다.
이런 것들은 디자인 문제도 아니고, 완전히 서버 문제도 아닙니다. 바로 개발 단계의 성능 의식 문제입니다.
6. 어떤 경우 MIC Studio를 찾는 것이 좋을까
위 순서대로 점검했는데도 원인을 찾지 못했거나, 팀에 디자인, 프런트엔드, 백엔드, 배포를 동시에 이해할 수 있는 사람이 없다면 전문 팀의 개입이 적합합니다.
MIC Studio는 기업 웹사이트, 미니프로그램 개발, App 개발, 스크립트 개발을 하며, 웹사이트 보안 테스트와 리버스 테스트도 수행합니다. 우리가 이런 문제를 처리하는 방식은 먼저 속도를 측정해 원인을 찾고, 최적화 목록을 제공한 뒤, 우선순위에 따라 수정하는 것이지, 처음부터 다시 만들라고 요구하는 것이 아닙니다.
우리를 찾는 것이 적합한 경우는 다음과 같습니다:
- 공식 홈페이지 리뉴얼 후 확실히 느려졌는데, 직접 원인을 찾을 수 없을 때;
- 미니프로그램이나 App 첫 화면 로딩이 3초를 넘어 전환에 영향을 줄 때;
- 백오피스 시스템이 사용할수록 느려지고, 데이터가 늘어난 후 응답이 매우 느릴 때;
- 포괄적인 「최적화를 권장합니다」가 아니라 실행 가능한 성능 최적화 방안이 필요할 때.
마무리: 실행 가능한 세 가지 제안
1. 먼저 측정하고 수정하자: 개발자 도구나 속도 측정 플랫폼으로 첫 화면 시간, 요청 수, 리소스 크기를 기록하고, 데이터로 말하세요. 느낌만으로 서버를 바꾸지 마세요.
2. 디자인과 개발을 미리 정렬하자: 시안 단계에서 이미지 규격, 폰트 수, 애니메이션 범위를 합의하면 이후 대량의 재작업을 줄일 수 있습니다.
3. 최적화 순서를 뒤집지 말자: 먼저 이미지 압축, 요청 감소, 캐시 추가를 하고, 그다음 대역폭과 서버 업그레이드를 고려하는 것이 가성비가 가장 높습니다.
웹사이트가 느린 것이 두려운 게 아니라, 계속 추측하는 것이 두렵습니다. 문제를 디자인, 개발, 배포 세 덩어리로 나누고 하나씩 측정하면 답은 자연스럽게 나옵니다.