어떤 사이트의 로딩 속도를 측정하는 가장 객관적인 기준 중 하나는
크롬이나 파이어폭스 같은 최신 브라우저의 개발자도구(F12) 기능을 사용해서
Time to first byte (TTFB) 또는 Waiting 시간을 확인하는 것입니다. (둘 다 같은 의미입니다.)
서버에 요청을 전송한 후 서버에서 내용을 보내기 시작할 때까지 얼마나 시간이 걸리는지를 측정하는 거지요.
(전송을 마치기까지 얼마나 걸리는지는 인터넷 속도에 달려 있으므로 서버 성능의 문제가 아닙니다.)
물론 TTFB 시간이 전부는 아닙니다.
서버에서 내용을 받아오긴 했는데 무거운 자바스크립트가 엄청나게 들어 있거나,
대용량 이미지를 추가로 다운받아야 한다면 시간이 한참 더 걸리기 마련이죠.
그러나 이런 부분은 가벼운 레이아웃을 쓰거나 .htaccess에서 캐싱을 설정하는 방법으로 어느 정도 만회가 가능합니다.
반면, TTFB 시간은 서버가 웹페이지를 생성하기 위해 열심히 일을 하는 데 소요되는 시간이므로
쉽게 줄이기도 힘들고, 서버 부하와도 직결되는 문제입니다.
0.3초
보통 XE로 만든 사이트에서 TTFB 시간이 0.3~0.5초 (300~500ms) 정도 나오면 꽤 빠르다는 느낌을 받습니다.
일반적인 웹호스팅에 일반적인 XE 기반 사이트라면 대개 이 정도가 한계입니다.
0.2초
빠르기로 유명한 더쿠넷이나 XE타운은 0.2초 (200ms) 정도를 유지하고 있지요. XE 공홈도 비슷합니다.
가벼운 사이트라면 이 정도 나올 수 있습니다.
0.1초
아주 가벼운 사이트 + 고성능 서버 + 튜닝을 잘 하면 0.1초 (100ms) 이하로 낮출 수도 있습니다.
설치 직후에 내용이 하나도 없을 때는 0.05초 (50ms) 까지도 가능합니다.
여기서 더 낮출 수는 없을까요?
무겁기로 소문난 XE로는 불가능한 걸까요?
0.01초
아래의 스크린샷은 라이믹스로 만든 어느 커뮤니티 사이트의 로딩 속도를 파이어폭스 개발자도구로 살펴본 것입니다.
0.018초 (18ms) 의 TTFB 시간이 보이시나요?
(Connecting 시간이 0인 이유는 방금 새로고침했기 때문에 이미 서버에 연결되어 있어서 그렇습니다. HTTP/2 만세!)
라이믹스 자체의 기능은 아닙니다. 요즘 개발하고 있는 무시무시한 캐시 모듈 덕분입니다.
정식 배포할 경우 XE에서도 대부분의 기능을 활용할 수 있게 될 예정입니다.
캐시(cache)의 성격상 속도가 들쭉날쭉하므로 모든 상황에서 저런 속도가 나오지는 않겠지만,
로그인하지 않고 그냥 둘러보기만 하는 사용자의 비율이 높거나, 검색로봇의 방문이 잦은 사이트라면
일부 페이지를 빨리 처리하는 것만으로도 서버 부하를 크게 줄일 수 있게 됩니다.
다른 사용자들도 0.01초까지는 아니라도 평소보다 좀더 쾌적하게 사이트를 이용할 수 있게 될 테고요.
0.005초
제 개발서버에서 기록한 순간최고속도입니다.
이 정도 되면 서버에서 웹페이지를 생성하는 데 드는 시간보다
그 내용을 서울에서 지방으로 전송하는 데 드는 시간이 오히려 더 길어집니다.
저도 집에서 서울에 ping을 넣어 보면 0.01초 정도 걸리거든요.
지금 당장 XE로 만든 사이트도 튜닝만 잘 하면 서버 한 대로 동접 10,000명을 감당할 수 있습니다.
성능을 개선할 방법은 이렇게 점점 많아지고, 서버의 성능은 점점 좋아지고 있으니
동접 100,000명에 도전해 볼 날도 멀지 않았을 거예요 ^^
그 내용을 서울에서 지방으로 전송하는 데 드는 시간이 오히려 더 길어집니다.
이 문장 무섭네요...