태그
23개의 글
같은 주소를 쳐도 사람마다 다른 서버에 닿을 수 있어요. DNS와 CDN 거점까지, 어디서 갈라지는지만 따라가요.
CDN을 붙였더니 빨라졌는데 왜 빨라졌는지는 막연한 순간이 있어요.
사진 한 장에 .avif, .webp, .jpg를 함께 두라는 가이드, 정말 필요할까요?
preload 만 거는데 LCP 가 그대로면, 5종이 자리를 잘못 잡은 거예요.
onChange 마다 리렌더되는 게 부담일 때, 비제어가 답이 되기도 해요.
state, props, 부모 중 무엇이 트리거였는지 헷갈릴 때 보세요.
offsetWidth를 읽는 순간 브라우저가 멈춰요. 이 문제를 확인해봐요.
HTML을 받은 브라우저는 바이트 덩어리부터 픽셀까지 여섯 단계를 거쳐요.
이미지에 치수만 적어도 레이아웃이 안 밀려요. 웹폰트 교체는 조금 더 까다롭고요.
스트리밍이 켜져 있어도 첫 바이트는 한참 안 와요. 범인은 상위 await 한 줄이에요.
수천 행짜리 리스트가 뻑뻑해질 때, 가상화는 뭘 빼고 뭘 다시 채워야 하는 걸까요
한 줄이면 끝나는 최적화 같지만, 잘못 쓰면 오히려 더 느려집니다.
응답 헤더의 SWR 과 Service Worker 의 SWR 패턴이 헷갈렸다면 두 자리부터 나눠보세요
다섯 포맷 다 올리지 않아도 돼요, WOFF2 한 줄로 끝나거든요.
preload, prefetch, modulepreload 가 비슷해 보이지만 처리 시점이 정말 달라요.
한 객체로 묶어 넘기면 dispatch만 쓰는 컴포넌트까지 리렌더돼요.
아이콘을 매번 요청하는 게 아까워서 인라인했는데, CSS 파일이 더 커졌어요.
정렬 한 줄에 클릭이 멈춰요. 메인 스레드가 한 가닥이거든요.
SSR, SSG, ISR 이름은 익숙한데 막상 프로젝트에서 뭘 고를지 막힐 때가 많아요.
fallback 하나 추가했더니 LCP가 뒤로 밀렸어요. 경계 위치를 다시 재봐야 해요.
Suspense를 fallback 넣는 스위치로 썼다면, 경계 한 번쯤 다시 봐야 해요.
느린 것 같으니까 useMemo 감싸자, 로 시작하면 대부분 빗나갑니다.
top/left는 매 프레임 레이아웃을 다시 계산합니다. transform은 그 과정을 건너뛰죠.
