티비몬 무한 스크롤/리스트 페이지가 느릴 때

티비몬에서 작품 목록이나 회차 리스트를 스크롤하다 보면, 처음에는 비교적 부드럽게 내려가다가 어느 순간부터 스크롤이 끊기고 화면이 따라오지 않는 느낌을 받는 경우가 많다. 이 현상은 단순히 “사이트가 느리다”거나 “인터넷이 문제다”라고 보기 어렵다. 특히 새로고침을 하면 잠깐 괜찮아졌다가 다시 같은 증상이 반복된다면, 그 원인은 네트워크가 아니라 브라우저가 화면을 처리하는 방식 자체에 있다.

무한 스크롤 구조는 사용성 면에서는 편리하지만, 그만큼 브라우저에게는 많은 계산 부담을 주는 방식이다. 티비몬처럼 이미지와 텍스트가 혼합된 리스트에서는 이 부담이 더 빠르게 누적되고, 일정 지점을 넘으면 체감 성능이 급격히 떨어진다.

티비몬은 주소가 수시로 변경될 수 있으므로, 항상 티비몬 최신주소 안내 페이지를 기준으로 접속하는 것이 안전합니다.

티비몬 처음엔 빠른데 2~3시간 뒤 느려짐

티비몬 느릴 때 체감 개선 TOP 7(순서대로 따라 하기)

이미지 디코딩이 누적되면서 발생하는 성능 저하

무한 스크롤 페이지에서 가장 큰 부하는 실제로는 텍스트가 아니라 이미지다. 썸네일이나 포스터 이미지는 단순히 내려받는 것으로 끝나는 것이 아니라, 브라우저 내부에서 압축을 해제하고 화면 크기에 맞게 다시 계산되는 과정을 거친다. 이 이미지 디코딩 과정은 CPU 사용량을 크게 올리며, 한 번에 여러 이미지가 동시에 처리되면 스크롤이 눈에 띄게 끊기기 시작한다.

문제는 무한 스크롤 구조에서는 화면에 보이지 않는 영역의 이미지까지 미리 처리되는 경우가 많다는 점이다. 사용자는 아직 보지도 않은 이미지 때문에 이미 브라우저 자원이 소모되고, 스크롤을 계속할수록 이 부담이 누적된다. 그래서 처음 몇 화면은 부드럽지만, 어느 순간부터 갑자기 “스크롤이 무거워진 느낌”이 들게 된다.

레이아웃 스래싱이 스크롤을 끊어 놓는다

이미지 문제와 함께 자주 발생하는 것이 레이아웃 스래싱이다. 이는 브라우저가 요소의 위치와 크기를 계산했다가, 이미지나 콘텐츠가 로딩되면서 다시 계산해야 하는 상황이 반복되는 현상을 말한다. 예를 들어 이미지의 높이가 사전에 고정되어 있지 않으면, 로딩 전과 후에 레이아웃이 달라지고 브라우저는 이미 그린 화면을 다시 정렬해야 한다.

이 과정이 스크롤 중에 계속 발생하면, 브라우저는 스크롤 입력을 처리하는 동시에 레이아웃 재계산을 반복하게 된다. 그 결과 사용자는 마우스 휠이나 터치 입력이 즉각 반응하지 않고, 화면이 한 박자 늦게 따라오는 느낌을 받게 된다. 이 현상은 네트워크 상태와 무관하게 발생하며, 페이지 구조가 복잡할수록 더 심해진다.

브라우저 줌과 폰트 설정이 체감 성능에 미치는 영향

의외로 많은 사용자가 놓치는 요소가 브라우저 확대 비율과 폰트 렌더링이다. 브라우저를 110%나 125%로 확대해 사용하는 경우, 단순히 글자만 커지는 것이 아니라 모든 레이아웃 계산이 다시 이루어진다. 특히 이미지와 텍스트가 혼합된 리스트에서는, 확대 비율이 높을수록 요소 간 간격과 줄바꿈 위치 계산이 복잡해진다.

웹폰트가 사용되는 페이지라면 상황은 더 악화된다. 스크롤 중에도 폰트 렌더링과 안티앨리어싱이 반복적으로 발생하면서, 이미지 디코딩·레이아웃 계산과 동시에 처리된다. 이 상태에서는 네트워크가 아무리 빨라도 스크롤 체감은 개선되지 않는다.

티비몬 무한 스크롤·리스트 페이지가 느릴 때 주요 원인 정리

원인 요소	내부에서 발생하는 동작	사용자 체감	흔한 오해	실제로 효과 있었던 대응
이미지 디코딩	대량 이미지 압축 해제	스크롤 끊김	서버 문제	이미지 로딩 최소화
레이아웃 스래싱	반복적인 화면 재배치	화면 밀림	캐시 문제	구조 초기화
브라우저 줌	계산 단위 증가	전반적 둔함	기기 성능 탓	100% 유지
폰트 렌더링	텍스트 재계산	미세한 렉	탭 수 문제	기본 폰트

왜 새로고침은 근본적인 해결이 되지 않는가

무한 스크롤이 느려질 때 새로고침을 하면 잠시 부드러워지는 경우가 많다. 하지만 이는 문제를 해결한 것이 아니라, 단지 계산이 다시 처음부터 시작되었을 뿐이다. 스크롤을 계속 내리면 같은 구조의 계산이 다시 반복되고, 결국 동일한 지점에서 또다시 느려진다.

이 유형의 문제는 캐시 삭제나 네트워크 변경으로 해결되지 않는다. 핵심은 브라우저가 한 세션 안에서 처리해야 할 화면 요소의 수와 계산 복잡도이기 때문이다.

체감을 실제로 개선하는 사용 방식

무한 스크롤 페이지에서는 “계속 내려보는 것”이 오히려 가장 큰 부담이 된다. 일정 지점까지 탐색한 뒤, 탭을 닫았다가 다시 여는 것만으로도 체감 성능이 크게 회복되는 이유는, 브라우저의 레이아웃 계산 상태가 초기화되기 때문이다. 이는 메모리 부족 때문이 아니라, 누적된 렌더링 상태를 정리하는 효과에 가깝다.

또한 브라우저 확대 비율을 100%로 유지하고, 시스템 기본 폰트를 사용하는 환경이 가장 안정적이다. 무한 스크롤에서는 한 번에 많은 항목을 빠르게 훑기보다는, 중간중간 멈추는 방식이 오히려 부드럽게 느껴질 수 있다.

다른 느려짐 문제와의 차이

무한 스크롤 느려짐은 영상 재생 끊김이나 접속 지연과 성격이 다르다. 영상 문제는 디코딩 성능이나 네트워크가 중심이고, 접속 문제는 서버나 차단 이슈가 원인인 경우가 많다. 반면 리스트 스크롤 문제는 렌더링과 계산 구조가 핵심이기 때문에, 특정 페이지에서만 반복적으로 나타난다.

이 차이를 이해하지 못하면, 계속 엉뚱한 해결책을 시도하게 된다.

티비몬 무한 스크롤·리스트 페이지가 느려지는 현상은 우연도 아니고, 단순한 서버 문제도 아니다. 이미지 디코딩, 레이아웃 스래싱, 브라우저 줌과 폰트 설정이 겹치면서 브라우저가 감당해야 할 계산량이 한계에 도달할 때 나타나는 구조적 결과다.

이 구조를 이해하면, 왜 네트워크를 바꿔도 소용이 없고, 왜 탭을 재오픈하면 체감이 즉시 회복되는지 자연스럽게 연결된다. 이 글을 기준으로, 이후에는 브라우저별 차이와 모바일 환경에서 더 빨리 느려지는 이유까지 확장해 다룰 수 있다.

티비몬 무한 스크롤·리스트 페이지가 느릴 때 (심화 분석)

무한 스크롤이 느려지는 문제를 단순히 “이미지가 많아서”라고만 이해하면 절반만 본 셈이다. 실제로 체감 성능이 급격히 떨어지는 시점은 이미지 개수보다는 브라우저 내부 상태가 한계에 가까워졌을 때 발생한다. 특히 리스트를 오래 내려본 뒤 스크롤 입력이 늦게 반응하거나, 마우스 휠을 돌렸는데 화면이 한 박자 뒤에 따라오는 현상은 렌더링 파이프라인 전체가 밀리고 있다는 신호다.

이 단계의 문제는 네트워크·서버·차단 이슈와 완전히 다른 층위에 있으며, 브라우저가 “지금 이 화면을 어떻게 처리하고 있는가”를 기준으로 봐야 정확히 이해할 수 있다.

DOM 노드 누적이 성능을 잠식하는 방식

무한 스크롤 페이지의 핵심 구조는 간단하다. 스크롤이 내려갈수록 새로운 항목을 추가하고, 기존 항목은 거의 제거하지 않는다. 이때 각 작품 카드, 썸네일, 텍스트 블록 하나하나가 DOM 노드로 남는다. 사용자는 화면에 보이지 않는다고 느끼지만, 브라우저 내부에서는 이 노드들이 계속 유지된다.

DOM 노드가 늘어날수록 브라우저는 스크롤 입력을 받을 때마다 더 많은 요소의 위치와 상태를 고려해야 한다. 특히 “현재 보이는 영역이 어디인가”를 판단하는 과정에서, DOM 트리 전체를 기준으로 계산이 이루어진다. 이 계산 비용은 선형적으로 증가하지 않고, 일정 규모를 넘으면 체감상 급격히 튄다.

그래서 같은 페이지라도 짧게 훑어볼 때는 부드럽고, 오래 내려본 뒤에는 갑자기 무거워지는 것이다.

자바스크립트 힙과 GC 압력이 만드는 입력 지연

DOM 누적과 함께 반드시 따라오는 문제가 자바스크립트 힙 사용량 증가다. 무한 스크롤에서는 스크롤 이벤트, 이미지 로딩 이벤트, 관찰자(observer) 객체 등이 지속적으로 생성된다. 이 객체들이 즉시 정리되지 않으면, 힙 메모리에 남아 브라우저는 결국 가비지 컬렉션(GC)을 실행하게 된다.

GC는 메모리를 정리하는 과정이지만, 실행 중에는 메인 스레드가 잠시 멈춘다. 이 순간 사용자는 스크롤이 먹지 않거나, 클릭이 무시되는 느낌을 받는다. 특히 스크롤 중간중간 “툭툭 끊기는 느낌”이 반복된다면, 이는 네트워크 지연이 아니라 GC 사이클이 간헐적으로 발생하고 있다는 신호다.

이 문제는 탭을 오래 열어둘수록, 그리고 리스트를 많이 펼칠수록 더 자주 나타난다.

입력 이벤트가 밀리는 구조적 이유

브라우저에서 스크롤, 클릭, 터치는 모두 메인 스레드에서 처리된다. 동시에 이 스레드는 레이아웃 계산, 스타일 재적용, 페인팅 작업도 담당한다. 무한 스크롤 페이지에서는 스크롤 입력이 발생할 때마다 다음 작업이 연쇄적으로 일어난다.

1. 첫째, 스크롤 위치 변경
2. 둘째, 새 항목 로딩 여부 판단
3. 셋째, 레이아웃 재계산
4. 넷째, 이미지·텍스트 페인팅

이 중 어느 하나라도 지연되면, 입력 이벤트는 큐에 쌓인다. 사용자는 “휠은 돌렸는데 화면이 안 움직인다”고 느끼지만, 실제로는 입력이 무시된 것이 아니라 아직 처리되지 못한 상태다. 이 현상이 반복되면 체감상 사이트 전체가 느려진 것처럼 느껴진다.

왜 특정 리스트 페이지에서만 유독 체감 저하가 심해지는가

무한 스크롤 구조라고 해서 모든 페이지가 동일한 방식으로 느려지는 것은 아니다. 티비몬에서도 유독 특정 장르 페이지나 회차 수가 많은 작품 목록에서 체감 저하가 빠르게 나타나는 이유는, 단순히 “아이템 수가 많아서”가 아니라 페이지 내부 구조의 밀도 차이 때문이다. 회차 버튼이 많고 썸네일·메타 정보·클릭 이벤트가 촘촘하게 배치된 리스트일수록, 브라우저는 화면에 보이지 않는 영역까지 포함해 훨씬 많은 DOM 노드와 이벤트 핸들러를 동시에 관리해야 한다. 여기에 스크롤 위치를 기준으로 레이아웃을 재계산하는 로직이 반복적으로 실행되면, 스크롤 자체가 단순한 화면 이동이 아니라 지속적인 계산 작업으로 변질된다.

특히 광고 요소나 추적 스크립트가 함께 삽입된 리스트 페이지에서는 상황이 더 복잡해진다. 이 경우 스크롤 이벤트 하나에 반응하는 자바스크립트 로직이 여러 갈래로 분기되며, DOM 변경 감지, 가시 영역 계산, 광고 노출 조건 판단 등이 동시에 실행된다. 사용자는 단순히 “스크롤이 버벅인다”고 느끼지만, 내부적으로는 하나의 입력에 대해 여러 연산이 겹쳐 수행되고 있는 상태다. 그래서 같은 무한 스크롤이라도, 구조가 단순한 페이지는 오래 버티고 구조가 복잡한 페이지는 빠르게 한계에 도달하게 된다.

단순 설정 변경이 반복해서 실패하는 구조적인 이유

이 문제를 처음 겪는 사용자들은 광고 차단, 캐시 삭제, DNS 변경 같은 익숙한 해결책부터 시도하게 된다. 하지만 무한 스크롤 리스트의 체감 저하는 대부분 이런 방법으로는 거의 개선되지 않는다. 이유는 명확하다. 이 현상의 핵심은 네트워크 지연이나 외부 통신 문제가 아니라, 페이지 내부 상태가 누적되는 방식 자체에 있다. 캐시를 삭제해도 페이지는 다시 동일한 구조로 생성되고, 광고를 차단해도 리스트 항목과 이벤트는 계속 쌓인다.

즉, 사용자가 건드리는 설정은 대부분 “외부 조건”에 가깝고, 실제 문제는 “이미 생성된 내부 상태”에 남아 있다. 그래서 사용자는 설정을 바꿨음에도 체감이 거의 달라지지 않는 상황을 반복적으로 겪게 되고, 이 과정에서 “이상하게 이것만은 안 고쳐진다”는 인상을 받게 된다. 이는 해결을 못 해서가 아니라, 문제의 층위를 잘못 짚고 있기 때문이다.

실제로 체감 개선이 분명했던 대응 방식의 공통 구조

체감 개선이 명확하게 느껴졌던 대응 방식들을 묶어 보면, 공통점은 매우 분명하다. 모두 누적된 상태를 끊어내는 행동이라는 점이다. 탭을 닫았다가 다시 여는 것, 브라우저 자체를 재시작하는 것, 혹은 동일한 페이지를 완전히 새로운 세션에서 다시 여는 방식은 겉으로 보면 단순한 조치처럼 보이지만, 내부적으로는 DOM 트리, 자바스크립트 힙, 이벤트 큐 상태를 한 번에 초기화한다.

이 초기화 효과는 어떤 설정 변경보다도 직접적이다. 스크롤을 아무리 줄이고 옵션을 만져도 남아 있던 내부 상태가, 세션을 끊는 순간 완전히 사라지기 때문이다. 그래서 사용자 입장에서는 “다른 건 다 소용없었는데, 탭을 닫고 다시 여니까 바로 낫는다”는 경험을 하게 된다. 이는 우연이 아니라, 문제의 원인과 조치가 정확히 맞아떨어진 결과다.

모바일 환경에서 이 문제가 더 빨리 드러나는 이유

모바일 브라우저에서는 이 현상이 더 빠르고, 더 강하게 나타난다. 이는 기기 성능이 낮아서라기보다는, 모바일 환경의 세션 관리 정책과 메모리 한계 때문이다. 모바일 브라우저는 데스크톱보다 훨씬 적은 메모리 안에서 동작하며, 백그라운드로 밀려난 탭을 적극적으로 중단하거나 복원한다. 이 과정에서 무한 스크롤 페이지는 중간 상태를 유지한 채 다시 살아나면서, 오히려 내부 상태가 더 불안정해지는 경우도 많다.

특히 오래 스크롤한 뒤 홈 화면으로 나갔다가 다시 돌아왔을 때 체감이 급격히 나빠지는 이유는, 브라우저가 “이전 상태를 복구하려다 실패한 상태”로 돌아오기 때문이다. 사용자는 아무것도 하지 않았다고 느끼지만, 내부적으로는 이미 누적된 구조 위에 복원 작업이 겹쳐진 상태다. 그래서 모바일에서는 오래 보는 습관 자체가 성능 저하를 가속시킨다.

이 문제를 다른 ‘느림’ 유형과 구분해야 하는 결정적 이유

무한 스크롤 리스트에서 발생하는 체감 저하는 흔히 말하는 접속 느림, 영상 끊김, 페이지 로딩 실패와는 성격이 완전히 다르다. 네트워크를 바꾸거나 주소를 다시 찾을 문제가 아니라, 사용 방식과 세션 관리 전략을 바꿔야 해결되는 문제다. 이 구분이 되지 않으면 사용자는 계속 캐시 삭제나 설정 변경 같은 엉뚱한 해결책을 반복하게 된다.

반대로 이 유형을 정확히 인식하면, “이건 환경을 만질 문제가 아니라, 지금 세션을 끝내야 할 타이밍이구나”라는 판단이 가능해진다. 이 차이가 바로, 같은 문제를 겪고도 어떤 사용자는 계속 불편해하고 어떤 사용자는 빠르게 체감을 회복하는 갈림길이 된다.

마무리

티비몬 무한 스크롤·리스트 페이지가 느려지는 현상은 브라우저가 일을 못해서가 아니라, 너무 많은 일을 동시에 하도록 강요받고 있기 때문이다. DOM 누적, 자바스크립트 힙 증가, GC 압력, 입력 이벤트 지연이 겹치면서 일정 지점을 넘으면 체감 성능이 급격히 무너진다.

이 구조를 이해하면, 왜 “잠깐 봤을 땐 괜찮은데 오래 보면 못 쓰겠다”는 말이 나오는지 명확해진다. 그리고 왜 가장 효과적인 해결책이 설정 몇 개가 아니라 세션을 끊는 행동인지도 자연스럽게 연결된다.

다음 글에서는 이 구조를 기준으로, 브라우저별로 한계가 어디서 갈리는지와 모바일·PC 간 체감 차이가 왜 이렇게 큰지를 더 깊게 풀어갈 수 있다.

속도·버퍼링·렉 문제를 체감 기준으로 정리한 내용은
티비몬 느림 개선 가이드 허브에서 한 번에 확인할 수 있습니다.