안녕하세요. 먼저 말씀드리고 싶은 것은, 저는 SEO를 추격하거나 구글이 제 사이트가 어떻게 생기고 작동해야 한다고 생각하는 요구사항 선호도에 맞추기 위해 별다른 노력을 기울이는 사람이 아니라는 점입니다. 하지만 구글이 곧 랭킹에 매우 큰 비중으로 반영될 새로운 "Core Web Vitals 지표"에서 사이트 개선이 필요하다는 이메일을 보내왔다는 점은 알아두는 것이 좋습니다:
Discourse Meta에 대한 보고서는 제 사이트보다 INP가 다소 나쁜 상태입니다(372ms 대 208ms):
Discourse가 기본적으로 JavaScript 웹 앱이므로, 이러한 지표를 개선하는 것이 쉽지는 않을 것 같습니다. 하지만 구글은 Moto G Power 폰을 에뮬레이션한다고 주장하면서도, 웹 크롤러가 보는 JavaScript가 없는 버전을 기반으로 랭킹을 매기는 것으로 보입니다…
Hi @rahim123 - INP 개선은 Discourse의 페이지 내비게이션 애니메이션을 전체 페이지 '스피너’에서 슬라이더로 전환하는 주요 동기 중 하나입니다. 해당 변경 사항은 지난주에 Meta에만 배포되었기 때문에, Google의 웹 비탈스 조사 데이터에 그 변화가 반영되기에는 아직 이릅니다.
저는 Google의 실시간 URL 테스트기(https://pagespeed.web.dev)를 사용했는데, 그러면 이미 랭킹에 포함되지 않나요? 그리고 Google이 JavaScript가 없는 버전을 보고 있으므로, 스피너와 슬라이더를 어떻게 고려하는지 모르겠습니다. INP(입력 지연)는 같은 웹사이트 내에서 한 페이지에서 다른 페이지로 이동하는 것과 관련이 있는 것 아닌가요? 그렇다면 단일 URL에 대해 해당 메트릭을 어떻게 측정하는지 정말로 이해가 되지 않습니다. 죄송합니다. 페이지 아키텍처와 Google의 최신 정책 변화와 관련된 이러한 세부 사항에 대해 저는 전문가가 아니기 때문입니다.
meta.discourse.org와 같은 자체 도메인의 데이터의 경우, Google Search Console의 ‘경험(Experience)’ → ‘핵심 웹 바이탈(Core Web Vitals)’ → ‘모바일(보고서 열기)’ 섹션에 항상 최신 보고서가 숨겨져 있습니다. 여기서 아래로 스크롤하여 ‘INP 문제: 200ms 초과(모바일)’ 항목을 확인하세요.
INP는 Matomo 코어나 플러그인의 게시글 ?조리(cooking)? 과정(로드 시 JS를 통한 기능 강화)에 의해 영향을 받을 수 있습니다. 이러한 과정은 '렌더링 차단 시간(render blocking time)'이 큰 ‘무거운’ JS 작업을 수행합니다.
특히 사용자가 다른 스레드로 전환할 때, 10~20개의 게시글이 동시에 "조리(cooked)"됩니다.
이 경우 개별 게시글에 대한 작업을 별도의 setTimeouts()로 나누어 브라우저가 개별 작업 사이에 페인팅(painting)을 수행할 수 있도록 하고, 전체 프로세스가 완료될 때까지 기다리지 않도록 하는 것이 항상 좋습니다.
예를 들어 다음과 같은 코드가 있습니다:
var initializeSliderSlickItem = function (item) {
/* 실제 초기화 작업을 여기에 수행 */
var $this = $(item);
[…]
};
$('.slider-slick').each(function () {
var item = this;
setTimeout(initializeSliderSlickItem, 0, item);
});
