오늘早些时候, 저는 구글 검색 결과를 살펴보다가, 5월 4일 이후(약 30%) 검색 결과에서 우리 디스코urs 인스턴스(discourse.julialang.org)로의 유입량이 크게 감소한 것을 확인했습니다. 디스코urs가 전체 페이지뷰의 약 절반을 차지하고, 사이트 나머지 부분에서는 이번 업데이트로 인해 유입량이 증가했기 때문에 전체적으로는 순 감소 폭이 미미하여 지금까지는 인지하지 못했습니다. 하지만 같은 도메인 내에서 디스코urs와 비디스코urs를 분리해서 보면 그 차이가 매우 명확해집니다. 유입량은 서서히 회복되고 있지만, 사이트 나머지 부분의 성장률과 비슷한 수준입니다. LCP 문제와 관련하여 개선할 수 있는 조치가 있을까요? 이는 구글이 패널티를 부과하는 요인으로 보이는 좋은 후보입니다(검색 콘솔에서 수만 건의 LCP 불만 사항도 실제로 확인하고 있습니다). 구글 지표에 따르면, 우리의 많은 디스코urs 페이지에서 모바일 LCP가 약 3초로 보고되고 있는데, 이는 상당히 높은 수치입니다. 이는 디스코urs 전반에 걸친 보편적인 문제인 것 같습니다. 예를 들어, 이 스레드 자체에 대해 보고서를 실행하면 LCP가 3.3초로 나타납니다. 불행히도 저는 웹 개발자가 아니어서 구체적인 제안을 드릴 수는 없지만, 이 분야에 더 잘 아는 누군가가 조언을 해줄 수 있기를 바랍니다. 그 30%의 유입량을 되찾을 수 있다면 정말 좋겠습니다 
.
10개의 좋아요
주 단위 스무딩을 적용한 검색 인프레션 그래프입니다. 디스커스와 도메인의 나머지 부분(동일한 도메인 전체 신뢰도 등급을 가질 것으로 가정)으로 나누어 표시했습니다. 5월 업데이트의 영향이 상당히 뚜렷합니다. 아이러니하게도, 해당 주에 사이트의 나머지 부분에서는 무관한 트래픽 급증이 있었지만, 전반적인 경향은 디스커스의 인프레션이 눈에 띄게 감소하고, 사이트의 나머지 부분은 (무관한 트래픽 급증을 무시하면) 대체로 안정적이라는 것입니다.
5개의 좋아요
수개월간 제가 계속 불만을 제기했던 바로 그 문제인데, 관리자들이 이를 심각하게 받아들이지 않고 있어요. @Keno
우리는 디스코스의 사전 렌더링 성능을 개선하기 위해 일부 콘텐츠를 Nuxt를 통해 서빙하기 위해 Vue.js로도 실험을 시작했어요. 그리고 그 효과가 나타나고 있습니다. 이번 업데이트는 5월 업데이트 이후 한 달도 안 되어 게시되었는데, 지난 2~3일 동안 노출 수가 5월 업데이트 이전 수준으로 정확히 두 배가 되었어요.
이것이 우연인지 아닌지는 모르겠지만 LCP와 관련이 있을 수도 있어요. 결론을 내리기 전에 몇 주 더 모니터링을 계속해 볼 생각입니다.
3개의 좋아요
이 블로그 게시물을 읽어본 결과, 이 조언은… 매우 일반적입니다. 결국 "품질 좋은 콘텐츠를 갖추세요"라고 요약할 수 있죠. 이 블로그 게시물에 기반해서 디스코스에서 구체적으로 변경할 수 있는 것이 무엇인지조차 확실하지 않습니다. 
3개의 좋아요
콘텐츠 품질의 문제인지 확실하지 않지만, 실제로는 높은 LCP(최대 콘텐츠 페인트) 시간과 관련이 있을 수 있으며, 이는 Ember에서 수정할 수 있다고 생각합니다. 다만, 확신은 없으며 다른 솔루션들을 실험해 보며 확인 중입니다…
4개의 좋아요
여기서 한 가지 지표에 조금 지나치게 집착하고 있다고 생각합니다. 구글보다 더 신경 쓰고 있거든요.
그들은 5월 28일에 LCP에 대해 발표하면서 다음과 같이 언급했습니다 “이러한 변경 사항을 적용하기 전에 6개월의 사전 통지를 제공할 것입니다.” 그런데 오늘까지도 그 통지는 아직 내려오지 않았습니다.
7개의 좋아요
앞서 말했듯이, 나는 증거를 가지고 있지 않으며, 그 부분에 집중하고 있지도 않습니다. 여전히 다른 것들을 실험 중이고, 어제부터 인상이 원래 수준으로 급증하는 것을 보고 있습니다. 앞으로 몇 주간 어떻게 진행될지 지켜볼 예정입니다.
2개의 좋아요
솔직히 LCP에 문제가 있는지는 잘 모르겠지만, 검색 콘솔에서 눈에 띄는 유일한 항목이 LCP입니다. 우리 측에서는 LCP가 큰 페이지에서 약 2만 건의 오류가 발생하고 있습니다. SEO 영향 여부와 무관하게, LCP 시간을 개선하는 것은 가치 있는 목표라고 생각합니다. 물론 구글의 지표가 실제 상황을 얼마나 정확히 반영하는지에 대한 의문은 있지만, 만약 그렇다면 초기 로드 시간 5초는 꽤 긴 편이며, 분명히 더 나은 방법이 있을 것입니다. 특히 구글에서 바로 접속한 미로그인 사용자의 경우, CDN에서 미리 렌더링된 페이지를 제공하는 것이 매우 유용할 수 있습니다.
4개의 좋아요
LCP를 지적하고 있지만, 문제는 FCP라고 생각합니다… 동일한 시간을 주목해 주세요
Discourse에서 첫 번째 로딩이 이후 로딩보다 느린 이유는 첫 번째 페이지만 로드하는 것이 아니라 애플리케이션 전체를 로드하기 때문이므로, 모바일에서 Google의 “좋음” 수준(FCP 1초 미만)을 달성하기 위해 초기 로딩 시간을 줄이는 것은 말하기는 쉽지만 실제로는 훨씬 더 어려운 상황이라고 생각합니다.
10개의 좋아요
여러분은 "기술적"인 하드 팩터에 너무 집중한 것 같습니다. 구글이 말하지 않는 사실은, 실제로 웹사이트의 “인지된” 성능도 측정한다는 것입니다.
Discourse는 "인지된 성능"을 개선할 잠재력이 있을 수 있으며, 그래야 합니다.
이를 위한 방법은 많습니다. 예를 들어, 전체 앱이 로드되기 전에 스켈레톤 프리렌더링을 사용하는 것 등이 있습니다.
기본적으로, 앱이 완전히 로드되기 전에 표시되는 모든 것이 인지된 성능 향상에 도움이 됩니다. 전체 앱이 사용 가능하기 전에 헤더(콘텐츠 없이, 올바른 색상만)와 페이지의 로딩 스피너가 포함된 배경을 렌더링하는 것만으로도 초기 페이지 뷰에서 도움이 될 수 있습니다. 사용자가 느린 기기에서도 무언가 진행 중임을 알 수 있도록 단계적으로 구성되는 모든 것이 좋습니다.
예를 들어, Meta의 경우 다음과 같은 것을 즉시 렌더링할 수/해야 합니다(단순한 크리티컬 CSS로 구현 가능). 전체 앱이 브라우저에서 사용 가능해지기 전에 말입니다:
단일 웹 앱의 인지된 성능을 개선하는 수백 개의 기사가 있습니다. @team이 살펴볼 가치가 있는 주제일 수 있습니다.
3개의 좋아요
원하신다면 테마 컴포넌트에서 “로딩” 페이지를 구현할 수 있습니다. 시도해 보시고 사이트에 차이가 있는지 피드백을 남겨주세요.
8개의 좋아요
원하는 결과를 단순한 테마 컴포넌트로만 달성하기는 어렵다고 생각합니다. 이를 위해서는 다른 모든 스크립트와 CSS 메타 태그보다 앞에 배치되는 중요한 인라인 CSS 블록이 헤더에 필요합니다. 또한, 는 전체 앱이 로드된 후에만 렌더링됩니다. 따라서 테마 컴포넌트를 사용하여 원하는 결과를, 예를 들어 헤더에 중요한 CSS 블록을 배치하고 앱이 완전히 로드되기 전에 body에 최소한의
를 렌더링하는 것 등을 달성하는 방법을 찾지 못하고 있습니다.
4개의 좋아요
이것이 있는데, 로더를 조금 더 일찍 추가합니다…
검색 랭킹에 영향을 미치는 인지된 성능(perceived performance)에 대한 출처가 있으신가요, 아니면 FCP/LCP를 말씀하시는 건가요? FCP/LCP는 지각 기반 개념이지만 구체적이고 기술적 요구 사항이 있습니다. 또한 FCP는 Google의 "코어 웹 바이탈(core web vitals)"에 포함되지 않는다는 점도 유의하세요 (LCP는 포함됩니다).
Largest Contentful Paint (LCP) | Articles | web.dev 에서 좀 더 자세한 내용을 확인해 볼 수 있습니다:
Largest Contentful Paint API에서 현재 지정된 바와 같이, Largest Contentful Paint에 고려되는 요소의 유형은 다음과 같습니다:
페이지에서 요소를 DOM에서 제거하면 해당 요소는 더 이상 고려되지 않습니다. 마찬가지로, 요소에 연관된 이미지 리소스가 변경되면(예: JavaScript를 통해
img.src변경), 새 이미지가 로드될 때까지 해당 요소는 고려 대상에서 제외됩니다.
이러한 요구 사항들은 DOM에서 제거하는 대신 다른 방식으로 숨기면 큰 이미지/텍스트가 있는 로딩 요소가 아마도 작동할 수 있을지 약간 어렵게 만듭니다. 위의 스피너는 z-index를 사용하여 자신을 숨기므로, 이것이 작동할 수도 있습니다… 하지만 스피너 자체만으로는 충분하지 않습니다. 왜냐하면 스피너는 이미지나 텍스트가 아니기 때문입니다(CSS입니다).
느린 연결을 사용하는 사용자에게는 어떤 종류의 로더가 좋다는 데 동의하지만, Google의 경우(그리고 이것이 OP가 언급한 문제를 해결할지 알 수 없으므로) 넘어야 할 특정 장벽이 있습니다.
7개의 좋아요
이것은 Discourse의 하향식(바닥부터 시작하는) 재작성을 요구하므로, 이에 대해 기대하지 않는 것이 좋습니다.
4개의 좋아요
해당 컴포넌트를 확인해 봤지만, 대부분의 앱이 이미 부팅된 후에 로드되므로 큰 차이를 만들지 않는다고 생각합니다. 구글은 정확히 어떤 요소를 고려하는지 공개하지 않고 있습니다. 콘텐츠 외에도 주관적인 사용자 경험(UX)은 구글이 측정하는 요소 중 하나일 것입니다. 직접적으로 측정하지 않더라도, 예를 들어 검색 엔진으로 되돌아가는 비율(bounce back) 등을 통해 간접적으로 파악할 수 있겠죠. (인지되는) 로딩 시간이 길면 첫 방문 시 이탈률이 높아집니다. 또한, 구글이 공식적으로 200% SEO와 관련이 있다고 명시하지는 않았더라도, UX와 트래픽 관점에서는 여전히 중요한 요소입니다. 첫 페이지 로딩 시 인지되는 성능이 충분하지 않으면 사용자가 이탈하기 때문입니다.
그 부분을 충분히 이해하고 있습니다. 그리고 아직 앱의 렌더링 프로세스를 완전히 이해하지 못했다는 것도 인정해야 합니다.
1개의 좋아요
정말로 이 지표에서 이기고 싶다면, Google AMP처럼 정적으로 미리 생성된 사이트를 사용하세요.
정적 페이지를 가진 사이트에는 항상 질 수 있기 때문입니다.
7개의 좋아요
나한테 말하는 거야? 아니야, 나는 Discourse에 아주 만족해 
그리고 좋은 UX는 첫 페이지 로딩 속도만으로 결정되는 게 아니야. 처음 로딩에서는 일부 사용자를 잃을 수 있지만, 앱이 완전히 로드된 후에는 지루한 정적 페이지에 비해 사용자가 더 오래 머물고 더 자주 다시 방문하게 돼. 그리고 구글도 이 부분을 어떻게든 반영하고 있을 거라고 확신해.
게다가 Discourse로 전환한 이후로 속도 때문에 불만을 제기한 사용자는 한 명도 없어. 그리고 완전히 HTML 캐싱, Fastly, 그리고 크리티컬 CSS를 통해 라이트스피드급 첫 페이지 응답 시간을 확보한 초최적화 Drupal 페이지와 비교했을 때, 우리의 검색 유입량은 오히려 증가하고 있어.
4개의 좋아요
@codinghorror 네, 제가 가진 두 도메인으로 몇 가지 테스트를 해봤습니다.
두 도메인 모두 5월 4일 업데이트의 영향을 받았습니다:
1번째 사례 연구: 콘텐츠 품질에만 전적으로 집중 (위에서 많은 분들이 제안하신 대로)
첫 번째 사이트에서는 콘텐츠 개선, 키워드 최적화, 불량 링크 제거, 내부 링크 구축, 잠재력이 큰 새로운 양질의 콘텐츠 추가 등에 집중했습니다… 등등.
위 그래프에서 볼 수 있듯이, 새로운 아티클이 잘 인덱싱되고 얇은 콘텐츠는 제거되었으며 기존 아티클도 개선되었음에도 불구하고 모든 노력이 헛수고로 끝났습니다. 거의 개선된 것을 볼 수 없으며, 구글이 웹사이트를 아주 소량의 트래픽만 받을 수 있을 정도로만 인덱싱하는 것처럼 보입니다!
2번째 사례 연구: Vue+Nuxt로 마이그레이션 (구조를 약간 개선 + LCP 및 렌더링 속도 향상)
두 번째 웹사이트에서는 일부 페이지를 자체적인 Vue+Nuxt 앱으로 이동시켰습니다. 이 앱은 API를 통해 동일한 콘텐츠를 구조 변경 없이 또는 아주 약간 변경된 형태로 제공합니다. 이 경우 다른 개선 노력은 없었습니다(사실 이 경우 커뮤니티를 커뮤니티로 이동하는 것, 즉 특정 .com 도메인에서 콘텐츠를 제공하다가 메인 웹사이트에서 제공하는 것으로 바꾸는 것은 일시적으로 해가 더 될 수 있었는데 실제로도 짧은 기간 동안 그런 일이 발생했습니다).
위 내용에서 어떤 결론을 내릴 수 있을지 확실하지 않지만, 테스트를 계속해볼 것입니다. 물론 그 갑작스러운 스파이크는 흥미롭습니다. 그리고 참고로 5월 전후와 최근 스파이크 이후를 비교해봤는데, 모든 경우에서 많은 아티클의 인상을 잃었고 갑자기 거의 동일한 아티클들이 동일한 양의 인상을 되찾는 것을 확인했습니다. 따라서 영향을 받은 것은 1~2개의 아티클/페이지가 아니라, 구글이 웹사이트 전체를 페널티 대상으로 지정하고 콘텐츠 품질 개선 노력과는 무관하게 웹사이트 전체에 페널티를 유지하게 만드는 어떤 요인인 것으로 보입니다.
위 내용이 이해가 되길 바랍니다. 궁금한 점이 있으시면 편하게 말씀해 주세요.
감사합니다!
9개의 좋아요
제가 아는 바로는, Discourse가 크롤러에게 페이지의 정적(static) 버전을 제공하려고 시도하고 있죠? 로그인하지 않은 모든 사용자에게도 이 정적 버전을 제공할 수 있을까요? LCP 페널티를 보면 Google이 우리 포럼의 정적 버전이 아닌 동적 버전을 보고 있는 것 같습니다.
우리는 5월 4일 업데이트 이후 Google에서 LCP 위반으로 인해 포럼이 크게 페널티를 받고 있다는 문제로 몇 달 동안 계속 조사해 왔으며, 외부 컨설턴트를 고용하기도 했습니다. 하지만 결국 결론은 항상 동일합니다.
6개의 좋아요