(최종 프로젝트 진행중)
할 일:
- 3번씩 HTTP 요청 보내던 것 시간차 조사하기
※ 이하는 스스로 공부하며 적어둔 노트이며 불확실한 내용이 있을 수 있습니다. 학습용으로 적합하지 않음을 유념해주세요. ※
문제 상황:
페이지를 호출할 때 첫 번째 GET 요청 후 마지막에 2번의 똑같은 요청이 더 생긴다.
다른 팀들에도 물어봤는데 다들 이런 현상은 없다고 한다.
튜터님과 함께 고민해봤지만 이유를 알 수 없어 일단 물러나왔다.
저녁이 되고 우리 팀원 중 한 명의 로컬 환경(localhost)에서는 이런 현상이 없다는 점에 방점을 두고 조사를 이어나갔다.
어떤 페이지에 들어가든 이런 현상이 발생한다는 것도 힌트가 될 수 있을 것 같았다. 우리 프로젝트는 테두리 템플릿을 두고 가운데 내용물을 바꿔 끼워가며 페이지를 렌더링 하는 방식이었으므로…
그래서 혼자만 다른(2번의 추가 렌더링이 없는) 팀원의 index.ejs를 옆에 띄워두고 내 것과 비교해보기로 하였다. 그러다 발견하게 된 것이다.
내 코드엔 저게 있었고 팀원의 코드엔 저게 없었다. 그 팀원이 우리 프론트 기초를 만든 팀원이었기 때문에 말이 되었다. 그 팀원만이 계속해서 <head> 태그 내용물과 파비콘을 손보았던 것이다. 그래서 그 코드에서만 문제되는 임시 파비콘 코드 <link> 태그가 지워진 상태였던 것 같다.
항상 ‘마지막’에 두 번의 추가 호출이 이어지던 것도 이해가 됐다. 이 에러를 고치기 위해 여러 번 실험하면서 알게 된 건데, <head> 태그에 있는 <link>가 (파비콘이든 잘못된 리렌더링이든) 가장 나중에 실행된다.
그리고 저 태그가 똑같이 두 개라는 점도.
href가 “#”로 지정되어 있으니 계속 제 자신을 호출했겠구나 싶은 것도.
저 모든 정황이 맞아떨어지면서, 정말 저 링크 두 개를 지우니 추가 렌더링 2개도 없어지는 것을 보고 어찌나 소름과 허탈이 밀려오던지. 말그대로 하루 종일 붙잡고 있던 문제가 다 포기하고 들어가려던 시점에 풀ㄹ게 되었던 점이 소름이었고 생각보다 거창한 이유가 아니었다는 점, 그래서 ‘속도 개선 사항’에 당당히 이름을 올리지 못할 것 같다는 점에 허탈했다.
다음은 페이지 호출 시간이 얼마나 나아졌나를 비교해보려 애쓴 스샷이다.
3번씩 보낼 때 (고치기 전):
1번만 보낼 때 (고친 후):
onload 이벤트 이후로 제 2, 3 호출이 이루어지는 터라 ‘(사용자에게 보여지는) 로딩 속도 개선’이라는 점에 있어서는 별 도움이 안 된 것 같다는 슬픈 소식
그래도 불필요한 리렌더링을 막음으로써 리소스 낭비를 줄였다는 점이 고무할 만한 점이었다.
배운 점:
- <link> 태그의 href에 “#”를 지정하면 마치 새로운 GET 요청이 만들어지는 것처럼 HTTP 요청을 보내고 렌더링까지 하게 된다는 점.
- 이번에 한 것처럼 에러 현상의 작은 차이점을 기반으로 차근차근 물고 늘어지다 보면 해결되기 마련이라는 경험적 사실.
- 크롬 개발자 도구의 네트워크 탭과 함께 성능 탭에 발을 담가봤다는 점
- 덤으로 복습하게 된 DCL(DomContentLoaded)와 onload 이벤트 (발생 시점).
Uploaded by N2T