모두
모두콘텐츠
얼마 전 작은 회사 사이트를 이전했는데, 첫 화면의 큰 이미지 한 장이 페이지 용량의 절반을 차지하고 있었다. 서버 요금제를 올리기 전에 이미지를 줄이자 모바일 로딩이 빨라졌고 전송량도 내려갔다. 웹사이트디자인을 할 때 색과 배치만큼 파일 크기와 운영 방식도 일찍 결정해야 하는 이유다.
화면보다 먼저 방문 목적을 적는다
디자인을 시작하면 첫 화면에 무엇을 더 넣을지부터 이야기하는 경우가 많다. 그런데 방문자는 대개 회사 소개를 읽거나, 가격을 확인하거나, 문의를 남기러 온다. 이 세 가지 중 가장 중요한 행동을 정하면 메뉴와 첫 화면의 순서가 달라진다. 문의가 중요한 사이트라면 화려한 전환 효과보다 연락 방법, 운영 시간, 입력 항목이 먼저 눈에 들어와야 한다.
모바일 화면을 기준으로 글자 크기와 버튼 간격도 확인한다. 데스크톱에서 보기 좋은 세 칸짜리 카드가 휴대전화에서는 긴 세로 목록이 된다. 카드마다 같은 문구를 반복하면 사용자는 아래로 여러 번 내려도 새 정보를 얻지 못한다. 화면 폭을 줄여 보는 것만으로는 부족하다. 실제 기기에서 메뉴를 열고 문의 버튼을 누른 뒤 입력까지 마쳐 봐야 한다.
운영하면서 자주 바뀌는 정보는 그림 안에 넣지 않는 편이 좋다. 가격이나 영업시간을 이미지로 만들면 수정할 때마다 새 파일을 만들고 다시 올려야 한다. 텍스트로 두면 담당자가 고치기 쉽고 작은 화면에서도 읽기 편하다. 디자인 시안에서부터 수정할 사람의 작업까지 생각해 두면 이후 관리 비용이 줄어든다.
이미지 용량을 먼저 계산한다
페이지 용량은 서버 비용과 방문자의 대기 시간에 함께 영향을 준다. 예를 들어 페이지 한 번을 열 때 1MB가 전송되고 하루 1,000회 조회된다면 단순 계산으로 하루 1GB, 30일이면 약 30GB다. 같은 페이지가 3MB라면 약 90GB가 된다. 캐시 사용 여부와 방문 경로에 따라 실제 전송량은 달라지지만, 디자인 파일의 무게가 요금제 선택에 영향을 준다는 점은 분명하다.
가장 먼저 볼 것은 화면에 표시되는 크기보다 훨씬 큰 원본 이미지다. 가로 400픽셀로 보이는 사진을 수천 픽셀짜리 파일 그대로 내려보낼 이유는 거의 없다. 화면 폭에 맞는 크기를 준비하고, 사진 품질을 눈으로 확인하면서 압축한다. 첫 화면의 대표 이미지는 바로 불러오고, 아래쪽 이미지는 필요한 시점에 불러오도록 설정한다. 대표 이미지까지 늦게 불러오게 하면 첫 화면이 오히려 늦게 나타날 수 있다.
글꼴도 점검할 만하다. 여러 굵기와 언어의 글꼴 파일을 한꺼번에 받으면 짧은 안내 페이지가 생각보다 무거워진다. 실제로 쓰는 굵기만 남기고 기본 글꼴로도 읽기 좋은 구성을 잡아 두면 선택지가 넓어진다. 장식용 동영상이나 움직이는 배경은 꼭 필요한 페이지에만 쓰는 게 낫다. 방문자가 찾는 정보보다 효과가 먼저 뜨는 사이트는 운영자에게도 부담이다.
서버 사양은 방문 수보다 요청 형태로 판단한다
월 방문자 수만 듣고 바로 VPS가 필요하다고 말하기는 어렵다. 소개 페이지 몇 장을 보여주는 사이트와 로그인, 검색, 예약을 처리하는 사이트는 서버가 하는 일이 다르다. 이미지와 문서가 대부분인 작은 사이트는 저가 웹호스팅이나 정적 파일 배포 방식으로도 충분한 경우가 많다. 반면 요청마다 데이터베이스 조회가 여러 번 일어나고 특정 시간에 접속이 몰리면 CPU와 메모리 사용량을 따로 봐야 한다.
처음에는 페이지별 전송 크기, 하루 조회 수, 가장 바쁜 시간대의 요청 수를 기록한다. 출시 전이라 측정값이 없다면 예상치를 적되 여유를 크게 부풀리지 않는다. 운영을 시작한 뒤 응답 시간과 자원 사용량을 확인해 한 단계씩 올리는 편이 낫다. 캐시할 수 있는 소개 페이지 때문에 서버 전체를 키우는 일은 비용 대비 효과가 작을 수 있다.
디자인 요소도 요청 수를 바꾼다. 첫 화면에 이미지 20장과 외부 위젯 여러 개를 넣으면 방문 한 번에 처리할 파일이 많아진다. 같은 파일을 다시 방문할 때 재사용하도록 캐시를 설정하면 반복 전송을 줄일 수 있다. 다만 자주 바뀌는 본문과 오래 보관할 이미지 파일에는 서로 다른 갱신 방식을 적용해야 수정 내용이 늦게 보이는 사고를 피할 수 있다.
공개 전에는 고장 나는 순서로 확인한다
디자인을 바꾸고 사이트가 깨지는 지점은 대개 배포 과정에 있다. 공개 전에는 모바일 메뉴, 문의 양식, 이미지 경로, 삭제된 페이지의 이동 처리부터 확인한다. 신청 버튼은 눌리는데 접수 내용이 저장되지 않는다면 예쁜 화면도 소용없다. 실제 접수 한 건을 넣어 저장 위치와 알림까지 확인해야 한다.
사이트를 이전한다면 파일과 데이터베이스를 먼저 백업하고, 복구 가능한지도 시험한다. 백업 파일이 있다는 사실과 복구가 된다는 사실은 다르다. 도메인 연결을 바꾸기 전에는 새 서버에서 화면과 주요 기능을 검증하고, 이전 설정으로 되돌리는 절차를 적어 둔다. SSL 인증서 적용 상태도 이때 함께 확인한다. 접속 오류가 생기면 화면 디자인부터 고치기보다 도메인 연결, 인증서, 서버 응답, 응용 프로그램 기록 순서로 범위를 좁히는 편이 빠르다.
공개 후에는 실제 방문자의 로딩 지표를 본다. 구글의 코어 웹 바이탈은 큰 콘텐츠가 표시되는 시간, 클릭에 반응하는 시간, 화면이 흔들리는 정도를 각각 측정한다. 숫자 하나만 보고 디자인을 다시 만들 필요는 없다. 느린 페이지와 기기부터 찾고, 큰 이미지나 불필요한 스크립트처럼 원인이 확인된 부분을 고치면 된다.
내가 운영해 본 작은 사이트들은 비싼 서버보다 가벼운 첫 화면, 제대로 작동하는 문의 기능, 복구 가능한 백업에서 더 오래 안정적으로 버텼다. 웹사이트디자인의 비용을 잡을 때도 시안 제작비만 볼 게 아니라 매달 전송할 파일과 수정할 사람의 시간을 함께 계산하는 편이 현실적이다.
