첫 화면을 막는 것들
손님 화면이 흰 채로 한참 멈춰 있는 이유예요. 무거워서가 아니라, 문을 열기 전에 끝내야 할 일을 너무 많이 세워 뒀기 때문이에요. 무엇을 나중으로 미룰지 정하면 빨라져요.
쉽게 말하면
아침에 가게 문 여는 순서를 떠올려 보세요. 조명 켜고 셔터 올리면 손님은 들어올 수 있어요. 화분에 물 주기, 배경음악 고르기, 전단지 접기는 손님이 들어온 뒤에 해도 되죠. 그런데 그 셋을 다 끝낸 다음에야 셔터를 올리는 가게가 있어요. 손님은 그동안 닫힌 셔터 앞에 서 있어요. 첫 화면이 흰 채로 멈추는 건 정확히 이 상황이에요. 내용이 무거워서가 아니라, 셔터를 올리기 전에 할 일을 너무 많이 세워 둔 거예요.
그래서 이 문제의 해법은 "줄이기"가 아니라 "순서 바꾸기"예요. 아무 기능도 버리지 않고, 나중에 해도 되는 일만 뒤로 미뤄도 첫 화면이 눈에 띄게 빨라져요. 이게 빠른 화면 만들기와 다른 점이에요. 그쪽은 짐을 가볍게 하는 이야기고, 이 문서는 짐을 옮기는 순서 이야기예요.
개발하는 사람들은 이걸 렌더 블로킹이라고 불러요. 화면 그리기(렌더)를 막고 있다(블로킹)는 뜻이에요. 말은 낯설지만 가리키는 것은 셔터를 붙잡고 있는 짐 그대로예요. 이 단어를 알아두면 좋은 이유는 하나예요. 개발자나 점검 도구가 이 말을 쓸 때, 사장님이 무슨 얘기인지 바로 알 수 있어요.
손님은 이 줄이 다 끝날 때까지 흰 화면을 봐요. 휴대폰 데이터면 4초, 5초도 나와요.
빠진 기능은 하나도 없어요. 손님이 먼저 들어오고, 나머지가 뒤에서 붙어요.
손님 브라우저가 실제로 하는 일
왜 순서가 그렇게 중요한지는 브라우저가 일하는 방식을 한 번 보면 끝나요. 다섯 단계예요.
- 1손님이 주소를 눌러요. 서버가 글로 된 도면 한 장을 보내요. 아직 그림이 아니라 "여기에 제목, 여기에 사진"이라고 적힌 종이예요.
- 2브라우저가 그 도면을 위에서 아래로 읽어요. 읽다가 꾸미는 규칙 파일(글씨 크기·색·배치를 정하는 파일)을 만나면, 그 파일을 다 받아 읽을 때까지 그리기를 미뤄요.
- 3움직이는 코드 파일을 만나면 더 세게 멈춰요. 그 코드가 도면을 고칠 수도 있으니, 브라우저는 도면 읽기 자체를 중단하고 코드를 받아 실행이 끝날 때까지 기다려요.
- 4막는 것이 전부 끝나면 첫 그림을 그려요. 손님이 처음으로 뭔가를 보는 순간이 여기예요. 그 전까지는 전부 흰 화면이에요.
- 5그 뒤에 아래쪽 사진, 상담 위젯, 방문자 통계가 차례로 붙어요. 이 단계가 조금 늦어도 손님은 이미 가게 안에 있어요.
여기서 결론이 나와요
손님이 기다리는 시간은 4번까지의 합이에요. 5번은 아무리 무거워도 손님을 세워 두지 않아요. 그래서 할 일은 딱 하나예요. 4번 앞에 줄 서 있는 것들을 5번으로 옮기는 것.
무엇이 셔터를 붙잡나
첫 화면을 늦추는 것들은 성격이 다 달라요. 어떤 건 정말 셔터를 붙잡고, 어떤 건 붙잡지 않으면서 손님 눈에 늦게 보일 뿐이에요. 이 구분을 알면 엉뚱한 데를 손보는 일이 없어져요.
| 첫 화면에 얹는 것 | 셔터를 붙잡나 | 어디로 미루면 되나 |
|---|---|---|
| 꾸미는 규칙(색·글씨·배치) | 붙잡아요. 규칙을 다 모아야 그려요 | 첫 화면에 쓰는 규칙만 먼저, 아래쪽 화면 규칙은 뒤로 |
| 움직이는 코드 | 가장 세게 붙잡아요. 도면 읽기까지 멈춰요 | "화면 뜬 뒤에 실행" 표시를 붙이면 대부분 풀려요 |
| 글꼴 파일 | 글씨만 붙잡아요. 파일이 올 때까지 글자가 안 보일 수 있어요 | 기본 글씨로 먼저 보여주고 나중에 갈아 끼우기 |
| 남이 만든 위젯(상담·지도·광고) | 붙잡을 수 있어요. 남의 서버가 느리면 내 셔터가 같이 멈춰요 | 화면이 다 뜬 다음에 부르기 |
| 방문자 통계 코드 | 보통 안 붙잡지만, 잘못 넣으면 붙잡아요 | 제일 나중으로. 숫자는 그대로 쌓여요 |
| 사진 | 안 붙잡아요. 대신 첫 화면 완성이 늦어져요 | 첫 화면에 보이는 한 장만 먼저, 아래는 내려볼 때 |
| 자동재생 동영상 | 안 붙잡지만 데이터를 다 빨아가서 나머지가 늦어져요 | 첫 화면에서 빼기. 눌러야 재생되게 |
| 화면 전체를 코드로 그리는 방식 | 붙잡아요. 코드가 다 와서 실행돼야 글자가 생겨요 | 첫 화면 글자는 미리 그려 보내기 |
표에서 가장 오해가 많은 줄이 사진이에요. "느리다"고 하면 다들 사진부터 줄이는데, 사진은 셔터를 붙잡지 않아요. 사진을 줄이면 첫 화면이 완성되는 시점이 빨라지고, 흰 화면 자체를 없애는 건 그 위 두 줄이에요. 둘 다 해야 하지만 순서가 달라요. 흰 화면이 문제면 위 두 줄부터, 화면이 뜨는데 사진 자리가 계속 비어 있으면 사진 용량 줄이기로 가세요.
그대로 말하면 되는 문장
이 문제는 원인을 알아내야 말할 수 있는 게 아니에요. 눈에 보이는 증상을 그대로 말하면 나머지는 AI 나 개발자가 찾아요. 왼쪽 칸에서 내 상황을 찾아 오른쪽 문장을 그대로 붙여 넣으세요.
| 눈에 보이는 증상 | 그대로 붙여 넣을 문장 |
|---|---|
| 흰 화면이 몇 초 이어지다가 한꺼번에 뜬다 | 첫 화면이 흰 채로 몇 초 멈춰요. 첫 화면에 꼭 필요한 것만 먼저 띄우고, 나머지는 화면이 뜬 다음에 불러오게 바꿔 주세요. |
| 글씨가 처음엔 안 보이다 늦게 나타난다 | 글씨가 늦게 나타나요. 글꼴 파일을 기다리지 말고 기본 글씨로 먼저 보여준 다음에 바꿔 주세요. |
| 화면이 떴다가 내용이 아래로 밀린다 | 화면이 뜬 다음에 내용이 위아래로 밀려요. 사진과 위젯이 들어갈 자리 크기를 미리 잡아 두세요. |
| 상담 위젯이나 지도를 붙인 뒤로 느려졌다 | 상담 위젯을 첫 화면과 같이 불러오지 말고, 화면이 다 뜬 뒤에 불러오게 해 주세요. |
| 첫 화면 큰 사진이 한참 비어 있다 | 첫 화면에 보이는 사진 한 장만 먼저 받고, 아래쪽 사진들은 손님이 내려볼 때 받게 해 주세요. |
| 회사 와이파이는 괜찮은데 휴대폰에서만 느리다 | 느린 휴대폰 인터넷 기준으로 첫 화면을 점검하고, 첫 화면이 뜰 때까지 받는 파일 수를 줄여 주세요. |
한 번에 하나만
여섯 줄을 한꺼번에 요청하면 무엇이 효과가 있었는지 알 수 없어요. 하나 고치고 휴대폰으로 열어 보고, 첫 글자까지 몇 초인지 속으로 세 보세요. 그 숫자가 유일하게 믿을 수 있는 성적표예요.
지금은 신경 쓰지 않아도 되는 때
정직하게 말하면, 이 문서를 읽는 사장님의 절반은 지금 이걸 손볼 때가 아니에요. 첫 화면을 0.4초 줄이는 작업은 손님이 하루에 열 명인 가게에서 아무 매출도 만들지 않아요. 같은 하루를 손님 한 명 더 오게 하는 데 쓰는 게 훨씬 큰 돈이에요.
| 내 상황 | 판단 |
|---|---|
| 아직 문을 안 열었어요. 만드는 중 | 넘어가세요. 내용과 기능이 먼저예요. 순서는 나중에 바꿔도 안 늦어요 |
| 하루 방문자가 두 자리 수예요 | 넘어가세요. 이 사람들은 이미 나를 찾아온 사람들이라 기다려 줘요 |
| 단골이나 직원만 쓰는 화면이에요 | 넘어가세요. 올 사람은 옵니다. 대신 매일 쓰니 오작동이 더 급해요 |
| 첫 글자까지 1초 안에 떠요 | 이미 잘하고 있어요. 더 손대면 얻는 것보다 망가질 위험이 커요 |
| 점검 도구 점수가 노란색이래요 | 점수는 목표가 아니에요. 손님 체감이 괜찮으면 그냥 두세요 |
반대로, 지금 봐야 하는 신호
광고비를 쓰고 있다면 지금이에요. 문 앞에서 돌아서는 손님 하나가 광고비 그대로예요. 그 밖에 검색으로 처음 오는 손님이 생겼을 때, 휴대폰 데이터로 열었을 때 흰 화면이 3초를 넘을 때, 손님이 "안 열려요"라고 말했을 때가 신호예요. 이 넷 중 하나라도 해당되면 오늘 30분 쓸 값이 있어요.
실제로 겪는 장면
장면 1 · 외주 개발자가 보낸 점검 메모
“스크립트가 렌더 블로킹 걸려 있어서 defer 처리하고, 첫 화면에 필요한 CSS 만 인라인으로 올렸습니다. 폰트는 swap 으로 바꿨어요.”
이제 해석돼요. 셔터를 붙잡던 코드를 손님 들어온 뒤로 미뤘고(defer), 첫 화면에 필요한 꾸미기 규칙만 도면 안에 직접 적어 넣어(인라인) 파일을 기다리지 않게 했고, 글꼴이 늦게 와도 기본 글씨로 먼저 보여주게(swap) 바꿨다는 뜻이에요. 세 가지가 다 순서 조정이고, 기능을 뺀 것은 없어요.
장면 2 · 상담 위젯을 붙인 다음 날
“어제까지 잘 뜨던 첫 화면이 오늘은 5초씩 멈춰요. 제가 바꾼 건 상담 버튼 하나 붙인 것뿐인데요.”
그 하나가 원인이에요. 남의 위젯은 남의 서버에서 코드를 받아 와요. 그 서버가 느린 날에는 내 셔터가 같이 멈춰요. 위젯 자체는 좋은 기능이니 지울 필요는 없어요. 첫 화면과 같이 부르지 말고 화면이 다 뜬 뒤에 부르게 옮기면 돼요. 그리고 앞으로 위젯을 하나 붙일 때마다 첫 화면 시간을 다시 재는 습관을 들이세요.
자주 묻는 것
- Q. 흰 화면이면 고장 난 거예요?
- 대개는 고장이 아니라 순서 문제예요. 구별법이 있어요. 몇 초 기다리면 내용이 뜨면 순서 문제고, 아무리 기다려도 계속 흰 채면 오류예요. 후자면 오류 문장 읽는 법으로 가세요. 화면이 뜨는 동안 손님에게 뭔가 보여주고 싶다면 로딩 표시도 같이 보세요.
- Q. 제 사무실에서는 잘 뜨는데요?
- 그게 이 문제가 늦게 발견되는 이유예요. 사무실 와이파이와 최신 노트북에서는 거의 다 빨라요. 손님 절반은 이동 중에 휴대폰 데이터로 열어요. 판단은 가장 느린 손님 기준으로 하세요. 휴대폰에서 와이파이를 끄고 직접 열어 보는 게 제일 정확해요.
- Q. 사진을 줄였는데 흰 화면이 그대로예요.
- 정상이에요. 사진은 셔터를 붙잡지 않아요. 흰 화면의 원인은 대개 꾸미는 규칙 파일과 움직이는 코드예요. 사진 줄이기는 화면이 뜬 다음의 빈칸을 채우는 작업이고, 흰 화면은 그 앞 단계 이야기예요.
- Q. 방문자 통계 코드를 빼야 하나요?
- 빼지 마세요. 위치만 바꾸면 돼요. 화면이 다 뜬 뒤에 실행되게 옮겨도 숫자는 그대로 쌓여요. 통계를 빼면 방문자 통계로 판단할 근거가 사라져서 더 손해예요.
- Q. 바이브캠퍼스에서 만든 화면도 이런 일이 생겨요?
- 첫 화면에 무엇을 얹느냐에 따라 달라져요. 상담 위젯, 지도, 특별한 글꼴, 자동재생 동영상을 첫 화면에 계속 얹으면 어디서 만들어도 흰 화면이 길어져요. 하나 얹을 때마다 휴대폰으로 열어 보고, 느려졌으면 채팅에 "화면이 다 뜬 다음에 불러오게 해 주세요"라고 말하면 돼요.
- Q. 개발자가 점수 90점을 넘겨야 한다는데요?
- 점수는 참고 자료지 목표가 아니에요. 기준은 하나예요. 손님이 3초 안에 첫 글자를 보는가. 점수를 올리려고 손님이 좋아하는 기능을 빼는 건 거꾸로 가는 일이에요. 점수가 낮아도 체감이 괜찮으면 그대로 두세요.
헷갈리기 쉬운 것
첫 화면이 뜨는 시간과 화면이 다 채워지는 시간은 다른 숫자예요. 손님이 돌아서느냐는 앞쪽 숫자가 결정하고, 손님이 답답해하느냐는 뒤쪽 숫자가 결정해요. 흰 화면 문제는 앞쪽이에요. 여기서 다루는 것도 앞쪽이고요.
서버를 좋은 걸로 바꾸면 해결되나요? 대개 아니에요. 서버는 도면 한 장을 보내는 일까지만 담당해요. 그 뒤로 줄 서 있는 파일들을 기다리는 시간은 손님 브라우저 안에서 벌어지는 일이라, 서버 사양과 관계가 적어요. 돈을 쓰기 전에 순서부터 보세요. 순서 조정은 대개 공짜예요. 브라우저가 하는 일이 더 궁금하면 브라우저가 화면을 그리는 방식을 보세요.
확인해 보세요
휴대폰으로 내 사이트를 열었더니 흰 화면이 3초 이어지다가 한꺼번에 떠요. 가장 먼저 확인할 것은?
하나 더
상담 위젯을 붙인 뒤로 첫 화면이 5초가 됐어요. 어떻게 할까요?
직접 해보기
첫 화면 순서를 한 번 바꿔 보세요
만들고 있는 화면을 열고 채팅에 이렇게 그대로 붙여 보세요. "첫 화면에 꼭 필요한 것만 먼저 띄우고, 상담 위젯과 지도와 통계는 화면이 다 뜬 다음에 불러오게 해 주세요." 그리고 휴대폰에서 와이파이를 끄고 열어, 첫 글자가 보일 때까지 몇 초인지 세 보세요. 바꾸기 전 숫자를 먼저 재 두면 효과가 눈에 보여요.
스튜디오 열기더 깊이 (안 읽어도 괜찮아요)
꾸미는 규칙은 왜 일부러 막는 걸까 · 브라우저가 규칙을 다 모으기 전에 그려 버리면, 손님은 아무것도 꾸며지지 않은 맨몸 화면을 한 번 봤다가 갑자기 확 바뀌는 걸 보게 돼요. 그게 흰 화면보다 더 불쾌해서, 브라우저가 일부러 기다리도록 만들어졌어요. 그러니까 이건 고장이나 실수가 아니라 설계예요. 해결 방향도 "기다리지 마"가 아니에요. 첫 화면에 필요한 규칙만 아주 작게 만들어 도면 안에 직접 적어 넣고, 나머지 규칙 파일은 뒤로 미루는 것이 정석이에요. 개발자가 "크리티컬 CSS"라고 부르는 게 이 작업이에요.
"나중에 실행" 표시가 두 가지인 이유 · 코드를 미루는 표시에 종류가 둘 있어요. 하나는 도면 읽기를 멈추지 않고 파일을 받아 두었다가 도면을 다 읽은 뒤 적어 둔 순서대로 실행해요. 다른 하나는 파일이 도착하는 즉시 실행해서 도면 읽기를 중간에 끊을 수 있고, 순서도 보장하지 않아요. 화면을 건드리거나 다른 코드에 의존하는 것은 앞쪽이고, 방문자 통계처럼 혼자 돌아도 되는 것은 뒤쪽이 빨라요. 사장님이 직접 고를 일은 없지만, 개발자에게 물을 때 쓸 문장은 하나예요. "이 코드는 순서가 중요한가요?" 답이 정해지면 표시도 정해져요.
흰 화면이 정말로 하얀 경우 · 화면 전체를 코드가 그리는 방식으로 만들면, 서버가 보내는 도면에는 내용이 거의 없어요. "여기를 채워라"는 표시만 있고 글자는 코드가 만들어 넣어요. 그래서 코드가 도착해 실행될 때까지는 진짜로 아무것도 없는 흰 종이예요. 코드가 클수록 흰 시간이 길어지고, 손님 휴대폰이 오래된 기종이면 더 길어져요. 방향은 둘이에요. 첫 화면 글자만이라도 서버에서 미리 그려 보내기, 또는 코드를 화면별로 쪼개서 첫 화면 몫만 먼저 보내기. 앞쪽을 하면 검색 로봇도 글자를 읽을 수 있어서 검색 노출까지 같이 좋아져요. 이 판단은 만드는 방식 자체를 고르는 문제라, 처음 구조를 잡을 때 물어보는 게 훨씬 싸요.
이것만 기억하세요
- ·첫 화면이 흰 것은 무거워서가 아니에요. 문 열기 전에 세워 둔 일이 많아서예요
- ·셔터를 붙잡는 건 주로 꾸미는 규칙과 움직이는 코드예요. 사진은 다른 문제예요
- ·남이 만든 위젯을 하나 얹을 때마다 첫 화면 시간을 다시 재세요
- ·손님이 아직 적거나 문을 안 열었다면 지금 볼 일이 아니에요. 광고비를 쓰기 시작하면 그때가 신호예요
- ·말할 문장은 하나예요. 첫 화면에 필요한 것만 먼저, 나머지는 뜬 다음에