웹페이지 버벅임의 원인이 템플릿리터럴 때문이라고?

템플릿 리터럴

회사에서 채팅 UI개편이 있었다. 얼마 지나지 않아 많은 유저 문의가 올라왔는데. 채팅이 심하게 버벅거린다는 문의였다.  채팅 출력에 부하가 발생했다. 

문제 발생

채팅이 많은 방송에서 부하가 심해지면서 유저들의 문의가 쏟아지기 시작했다. 

비즈니스의 로직의 문제였을까? 개편할때 비즈니스 로직은 건들지 않고 UI만 변경했다.

변경점으로 DOM의 구조, CSS,  + 연산자로 Domstring을 그려준던 것을 ``(템플릿 리터럴)로 변경했다.

 

원인 분석

 

채팅을 출력하는  DOM의 Children을 보면 이상한 점이 없다. 그러나 ChildNodes를 살펴보자. text Node가 사라지지 않고 남아 있는 것을 볼 수 있다.  남아있는 Text Node는 개행문자였다. nodevalue의 값을 보니 "\n            " 으로 들어가고 있었다. 개행 문자가 있어서 영역을 차지할 것도 하지만, 신기하게도 UI 영역에서 개행이 있거나 하는 문제는 없었다.    

도대체 어쩌다가 Text Node 개행이 들어갔을까? 그리고 삭제할 때 Text 노드는 삭제하지 않았는가?

 

템플릿 리터럴

UI 개편 작업하면서 DomString의 길이가 길어지다 보니 가독성을 위해 개행을 한 게 그대로 들어가 버린 것이다. 

createDomString(msg){
  return `  // 개행
    <div> ${mes} </div>
  `// 개행
}

템플릿 리터럴의 경우에는 개행도 같이 포함하기 때문에 이러한 일이 벌어진 것이다.

템플릿 리터럴은 스트링 그대로를 넣어준다는 점을 알아야 한다. ( 융통성이 없는 놈 )

html을 stirng으로 직접 넣어주는 경우에 템플릿 리터럴을 사용한다면 반드시 확인해 봐야 한다. 

createDomString(msg){
  return `<div> ${mes} </div>`
}

이렇게 수정해 주니. 개행 없이 정상 동작한다. 

 

Text Node Remove

그런데 왜 Text Node는 삭제되지 않은 것일까?
remove 로직을 확인해 보니 HTML Dom만 찾아서 삭제하고 있었다.

QA 할 때도 UI는 정상적으로 보이고 Devtool에서도 보이지 않기에 문제가 되지 않았던 것이다. 

하지만 서비스가 크거나, 트래픽이 많은 채팅의 경우에는 Node도 출력해 보자 :)

 

remove 시에  text node를 체크해서 삭제해 주자. 

(좋은 방법은 아닌 것 같다.  나중에 text node가 필요해지는 경우가 생긴다면 복잡해진다.)

해결 방안

근본적인 원인으로는 탬플릿 리터럴 사용하며 개행 NODE가 들어갔는데 Remove시에 Dom만 제거했기 때문이다. 

Remove 시에 text node를 제거하는 방법도 있지만, 애초에 탬플릿 리터럴에서 개행이 들어가지 않도록 수정하자. 

 

마무리

이번 이슈는 쉽지 않았다. 재현되기도 쉽지 않고, 재현되었다고 해도 근본적인 원인을 찾기는 쉽지 않았다. 문제의 원인이 템플릿 리터럴이라는 점에서 앞으로 이 편한 것을 사용하지 못하나 했지만, 제대로 알고 사용하면 문제 되지 않을 것이다.