언젠가, 어느 외국기사를 보니, 사용자가 URL을 치고 페이지가 뜰 때까지 기다려주는 평균시간이 3.5초인가 그렇다고 한다. 예전에 비해 매우 짧아졌다고 할 수 있다.

서버 성능이 향상되고 인터넷 회선들도 빨라졌으며 사용자의 PC도 고성능화되어있음에도 여전히 페이지가 늦게 열리는 사이트들(일시적인, 혹은 고정적으로…)을 보면 나자신도 답답한데, 그래서 F5를 자꾸 누르게 되거나, 혹은 아예 서핑을 포기하곤 한다.

개편이전에 gesomoon.com이 그랬었고, zdnet과 한겨레도 가끔 그런다.
서버나 회선의 문제가 아니라면, 결국은 HTML의 문제.

많은 개발자들은 php, asp, jsp, perl 뭐 기타등등 CGI/Server Script들의 최적화를 위해 고민들을 한다. 어떻게 하면 루프를 한번 덜 돌릴까, 어떻게 하면 불필요한 분기문을 없앨까.
현장에서는 그런 문제로 사수들이 부사수들에게 갈굼(?) 또는 교육을 행한다. “여기 이 for문은 위에서 이렇게 처리했으면 없어도 되잖아.”
이렇게 해서 개선되는 처리속도는 시간으로 따지면 대략 0.01초 차이. 뭐, 바보가 아닌 이상 1초이상 돌아가는 루프문을 만들었을리는 없을테니까.

서버성능이 비약적으로 발달해서 싸구려 리눅스 서버래도 램좀 꼽아주고 나면 웹사이트 하나 돌리는 것이 아까울 정도로 황송한 속도가 나온다. 서버사이드 프로그램들의 속도개선 옵티마이징은 사실상 투자대 효용으로 치면 그다지 효율적이라고 할 수 없다는 표현까지 가능하겠다.

그래서 좀 똘똘해지면 DB쪽 커스터마이징이 더 중요하다는 것을 깨닫는다. 불필요한 중복 커넥션을 없애고, 쿼리문을 최적화하고, 필요하다면 DB 스키마를 다시 설계한다.
이것으로 잘하면 1초 이상 응답시간을 줄일 수도 있다.

대개 여기까지 개발자들이 노력하는 부분이다.
헌데 실상, 이런 노력이 다 무의미해지게 만드는 것이 웹환경일진대…
즉 회선 속도가 느리다거나 하면 말짱 도루묵이 된다는 점.

예를 들어 이미지가 많이 쓰이는 경우, 이미지 로딩시간이 앞서의 노력들을 다 잡아먹는다.
이런 경우에는 이미지 서버를 여러대 두고 같은 이미지를 저장해 둔후, 이미지를 불러올 때 로테이션식으로 여러 서버로 로딩부하를 분할해서 분담하게 하는 방법들이 있겠다. 구글 맵 등이 대표적인 케이스.

그런데 구글 맵처럼 늘 갱신되는 이미지가 대용량으로 쓰이는 경우들도 아닌데 페이지가 늦게 열리는 사이트들은 도대체 뭐란 말인가.

대개 그런 경우는 “광고”가 문제. 정확히 말하자면 “광고” 그 자체보다 “광고를 처리하는 방법”의 문제.

결론부터 말하자면, “페이지가 로딩된 후 모든 것을 처리하라.”라고 요약할 수 있겠다.

HTML본문 중에 다음처럼 스크립트 처리를 하는 경우들이 많다.
[html]

[/html]
대개 광고서버는 외부서버인 경우가 많고, 각종 처리를 해야하다보니 스크립트 실행속도가 매우 느리거나, 혹은 무엇인가의 문제로 아예 응답이 없을 수도 있다.
이렇게 되면 브라우저는 여기에서 응답이 올 때까지 멈춰있게 된다. 물론 HTML로딩이 끝나지 않은 상태이므로 화면에는 아무것도 표시가 안되고…

대안은 이렇다.
[html]

window.onload=function() {
addBanner(’sideBanner’, …);
}
function addBanner(divId, …) {
…
}

[/html]

페이지가 로딩된 후에, 광고가 출력되도록 window.onload에 이벤트를 걸어주는 방식. addEvent로 검색해보면 window.onload에 이벤트를 추가하는 좋은 방법을 알 수 있다.

이런 경우도 있다.
[html]


…

[/html]
HTML의 앞부분에 외부 서버의 스크립트를 실행시키는 방식인데, 상기했듯이, 외부로 나갔다오는 처리는 대부분 시간을 많이 소모시키고 응답을 확신할 수 없는 경우가 많다.
따라서 저 부분에서 뭔가 문제가 생기면 차후 진행이 안되고 로딩상태로 멈춰있게 된다.
이런 경우는 스크립트 호출을 body의 가장 끝부분에 놓거나
[html]

…


[/html]
혹은 위에 설명한대로, window.onload 이벤트에 걸어 페이지가 로딩된 후 동적으로 스크립팅이 되도록 만들어주면 된다.

아, 물론 Table이나 시맨틱하지 않은 장식용 img 태그의 남용 역시 페이지의 로딩속도를 떨어뜨리는 나쁜 코딩방법.
external CSS를 잘 활용하는 것도 CSS 캐싱을 이용한 페이지 로딩속도 개선에 좋은 효과를 준다.

페이지 로딩 후에 스크립트를 처리함으로써 얻을 수 있는 기대효과는 브라우저 로딩시간의 단축이외에도,
1) 스크립트 사용이 불가한 환경에서도 스크립트 자체를 제외한 다른 부분은 이용가능하다.(ohpy처럼 완전히 스크립트 스파게티인 사이트들이야 불가능하겠지만.)
2) 그런고로, 접근성이나 machine-feed로의 활용이 나아진다.
3) 물론 당연히 유지보수도 쉽다.

for문 잘못 썼다고 부사수를 타박하기 전에 저런 부분부터 개선해나가는 쪽이 필요하지 않을까? 웹프로그래머라면 말이지.