IE에서 차트 속도 이슈.

실제로 IE을 고려하며 개발을 시작하는 경우는 없겠지만

이미 IE까지 고려하여 개발된 사이트들은 무수히 널려있고, 이러한 사이트도 꾸준히 유지보수를 해야하며, 이러한 사이트는 이미 IE라는 악마에 걸려있기에, 꾸준히 IE의 지원도 고려해야한다.

IE의 난관은 크게 두가지가 있는데, 모던 브라우저에서 동작되지 않는 문법, 함수, 또는 IE만 존재하는 변수, 같은걸 사용했어도 달리 출력하는 등..(이 부분은 IE만의 문제는 아니다)

보통 스크립트 구조내에서 babel을 때려박으면 대부분 해결되는 일이다.

다만 IE자체가 워낙 오래된 브라우저다 보니 엔진 자체가 구려서, 사이트가 다루는 데이터량이 방대할때 이 속도를 해결할 수 없는경우가 많다.

대부분 큰 테이블 데이터를 다루거나, 차트같은 라이브러리를 활용할 떄이다.
이런 경우는 어쩔 수 없이 IE에서는 동일한 퍼포먼스를 포기해야한다.

특히 앞서 말한 차트 라이브러리의 경우 데이터가 사이트의 서비스 형태에 따라 몇천개 이상 들어가는 것이 기본인 경우가 있고,
이런경우 IE에서 퍼포먼스는 지나치게 떨어진다.

보통 api형태로 제공되는 데이터 값과 차트에서 요구하는 값이 달라 스크립트내에서 변환하여 처리하는경우가 있는데, 이러한 부분을 서버언어인 php나 jsp, 스프링등으로 받아올때 curl형식으로 서버에서 받아와 변환을 하여 바로 데이터를 받아오면 차트에 집어넣을 수 있게 가공하는것이 좋고 ajax, axios, fetch등의 비동기 통신으로 사용자 체감 속도를 최대한 절감 해야 한다

또한 차트 라이브러리의 경우 크게 canvas와 svg를 활용한것이 있는데,
svg가 데이터가 적으면 퍼포먼스가 빠르지만, 데이터가 많아질수록 svg쪽이 느려진다.
IE에서도 많은 데이터를 한꺼번에 보여줄것이라면 cavas형태의 차트 플러그인을 선택하고, 부득이하게 svg 플러그인을 선택했다면, svg에서 일어나는 hover 이벤트, 그리고 기본적인 애니메이션만 제거하면 왠만한 데이터량에도 크롬이나 파이어폭스같은 브라우저에 비하면 아니지만, 불편함을 느끼지 않을 정도의 속도는 확인할 수 있다.