Long Task란? 브라우저가 오래 멈춘 것처럼 느껴지는 이유 쉽게 이해하기
Long Task는 메인 스레드를 50ms 넘게 점유해 클릭·화면 업데이트를 늦출 수 있는 긴 작업입니다. TBT·INP·Yield·Web Worker·제3자 JS·Performance 점검까지 초보 기준으로 정리합니다.
버튼이 안 먹는 것처럼 느껴질 때
화면·메뉴는 보이는데 버튼을 눌러도 잠깐 반응이 없다면, 브라우저가 한 작업을 너무 오래 처리 중일 수 있습니다. Long Task(롱 태스크)는 메인 스레드에서 오래 실행되어 클릭·키보드·화면 갱신 같은 다른 일을 바로 처리하기 어렵게 만드는 작업입니다. 웹 성능 분석에서는 보통 50ms를 초과해 메인 스레드를 점유하면 Long Task로 봅니다. 계산대 직원이 한 손님의 복잡한 환불에 5분 붙잡히면 뒤 손님이 기다리는 것과 같습니다. 60ms는 클릭이 없으면 못 느낄 수도 있고, 500ms 순간에 메뉴를 누르면 크게 느낄 수 있습니다 — 「입력을 지연시킬 가능성」을 찾는 개념입니다.
메인 스레드 · 동기 · TBT·INP
브라우저 전체가 무조건 멈추는 것은 아니지만, JS·DOM·Style·Layout·Paint·이벤트 처리가 메인 스레드에서 줄을 섭니다. 하나의 동기(Synchronous) 작업이 실행 중이면 보통 그 중간에 클릭을 끼워 넣지 못합니다. Long Task는 개별 원인, TBT는 각 Long Task의 50ms 초과분(Blocking)을 합친 결과입니다. 실행 중 클릭하면 INP가 나빠질 수 있고, 그 순간에 안 누르면 Lab Long Task와 Field INP가 어긋날 수도 있습니다. FCP 이전 Long Task는 첫 콘텐츠를, LCP는 Paint 지연으로, 끝난 뒤 대량 DOM이면 CLS까지 이어질 수 있습니다. Speed Index·TTFB와도 축이 다릅니다.
Long Task 180ms → Blocking 130ms → TBT에 합산 정렬 800ms 중 200ms에 클릭 → 끝날 때까지 메뉴 대기 가능 PC 45ms / 모바일 220ms — 같은 코드도 기기마다 Long Task 여부 다름
흔한 원인 · 줄이는 방법
대표 원인: 대량 데이터 정렬·필터, 수천~수만 DOM 생성, 초기화 폭주(슬라이더·채팅·지도·광고), 제3자 JS, 큰 JSON.parse, Canvas/차트, 스크롤마다 무거운 계산, Layout Thrashing, 광범위 리렌더. 삭제만이 답은 아닙니다 — 「꼭?」「지금?」「전원에게?」「이만큼 데이터?」를 먼저 묻습니다. 양 줄이기(Pagination·서버 필터)·잘게 나누기(Yield)·지연(Intersection Observer·클릭 후 로드·Prefetch 균형)·Web Worker(DOM 불가·전송 비용 있음)·Throttle/Debounce·알고리즘·자료구조 개선을 검토합니다. 작업을 나눠도 총 계산은 비슷할 수 있지만 반응성이 좋아질 수 있습니다. 프레임·60fps·Jank는 애니메이션·스크롤 버벅임의 다른 얼굴입니다. SEO 전용 점수가 아니라 메인 스레드·반응성 진단 개념입니다.
점검 순서 · Lab·모바일
Performance로 Long Task → 파일(자체/제3자) → Flame Chart·Self/Total Time → 양 줄이기·분할·지연·Worker → 모바일·CPU Throttling·실기기·RUM. Lighthouse의 Main-thread work·JS execution·Unused JS·Third-party도 힌트입니다. 태그 매니저·죽은 스크립트를 정리합니다. Performance Budget·CI/CD로 회귀(Regression)를 추적하되 한 번 측정만으로 배포를 막지 않도록 합니다. Long Task 0개여도 서버·이미지·API 문제는 남습니다.
자주 묻는 질문
Long Task란?
메인 스레드를 오래 점유해 입력·화면 업데이트를 지연시킬 수 있는 긴 작업입니다. 보통 50ms 초과를 기준으로 봅니다.
TBT와의 차이는?
Long Task는 개별 긴 작업, TBT는 여러 Long Task의 50ms 초과 Blocking을 합산한 값입니다.
INP와의 관계는?
Long Task 중 클릭하면 처리가 밀려 실제 사용자 INP가 나빠질 수 있습니다.
작업을 나누면 더 빨라지나요?
총 시간은 비슷할 수 있어도, 중간에 입력·Paint를 처리할 기회가 생겨 반응성이 나아질 수 있습니다.
제3자 JS도 원인이 되나요?
네. 광고·채팅·분석 등도 같은 메인 스레드를 쓰며, 필요 여부·로딩 시점을 조정할 수 있습니다.
모바일에서 더 생기나요?
같은 코드라도 CPU가 약한 기기에서는 실행이 길어져 PC에선 짧던 작업이 Long Task가 될 수 있습니다.
정리
Long Task는 메인 스레드를 오래 점유해 입력·화면 업데이트를 기다리게 할 수 있는 긴 작업입니다. 불필요 JS·대량 데이터·과도한 DOM·제3자·무거운 이벤트·비효율 알고리즘을 점검하고, 양을 줄이고·나누고·미루고·Worker로 분리하는 방향을 함께 봅니다. 그런데 JS가 「한 번에 하나씩」이면서도 setTimeout·Promise·async/await를 쓸 수 있는 이유는, 작업·입력·타이머·네트워크 완료를 어떤 순서로 처리하는지에 있습니다. 그 핵심 개념이 이벤트 루프(Event Loop)입니다.