# Google 5월 4일 코어 업데이트가 Discourse 포럼에 미치는 영향
**URL:** https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369
**Category:** Community Building
**Created:** [8월 19, 2020, 12:35오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369 "2020-08-19T12:35:50Z")
**Posts on this page:** 20
**Page:** 5
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [11월 23, 2020, 1:25오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/91 "2020-11-23T13:25:06Z")
> [@Jonathan5](#):
>
> 이 내용들은 LCP에 대해 아무것도 말해주지 않으며, 증명하지도 않습니다. 흥미로운 주제였고, 계속 이어지기를 기대합니다. 개인적으로 Discourse의 속도에 만족하고 있습니다.
전적으로 동의합니다. 제가 빠르게 검색한 결과는 그 본질이 아니었으며, 결코 권위 있는 테스트로 의도된 것이 아닙니다. 그리고 제가 그 내용을 게시할 때에도 그러한 주장을 하지 않았습니다. 저는 단지 제 검색 결과에 기반하여 질문을 한 것뿐입니다. 검색을 수행하기 전에 로그아웃을 했어야 했는데, 로그아웃 상태에서도 동일한 '결핍’된 결과를 얻게 되더군요, 하하.
제가 실제로 제기한 유일한 '구체적인 기술적 포인트’는 Google이 2021년 5월부터 LCP(그리고 기타 웹 바이탈)를 사용할 것이라고 공개적으로 발표한 것이라는 점입니다.
또한 Google이 이러한 성명을 발표하고 사람들을 속일 수는 없다는 비즈니스 관점의 논리도 제시했습니다. 이는 대규모 상장 기업에게 엄청난 실수가 될 것입니다. 제 추측으로는 그들은 그러한 실수를 저지르지 않을 것이며, Google이 아직 LCP를 시그널로 사용하지 않는다고 말할 때 저는 그들을 믿지 않을 이유가 없습니다.
LCP가 SEO에 영향을 미친다고 주장하며, 자신들의 '조사 결과’에 확신을 가지고, 그 ‘조사 결과’ 때문에 Discourse가 코드에 구조적 변경을 해야 한다고 옹호했던 선의의 게시자들이 만약 코드를 검토할 수 있도록 오픈 소스로 공개했다면, 그들의 '증거’는 동료 검토(peer review)를 통해 설득력이 있을 수 있었을 것입니다.
이것은 전혀 개인적이거나 적대적인 것이 아닙니다. 사실, 우리는 몇몇 그래프만 보았고 코드는 보지 못했으며, Google은 현재 LCP를 SEO 시그널로 사용하지 않는다고 공개적으로 발표한 상태입니다.
모든 '기술적 공정성’을 따져볼 때, 우리는 Google이 현재 LCP를 시그널로 사용하고 있다는 '증거’를 실제로 본 적이 없습니다. 그것은 단지 추측일 뿐이며, 이를 뒷받침하기 위해 동료 검토를 받을 수 있는 코드가 없습니다.
여기 있는 모든 사람은 SEO를 최적화하고 수익을 증가시키는 데 필요한 변경 사항이 무엇인지 알고 싶어 합니다. 그러나 우리는 Google이 실제로 LCP를 시그널로 사용하고 있다고 확신할 수 있는 구체적 사실과 검토할 수 있는 코드가 필요합니다.
Google은 현재 LCP를 시그널로 사용하지 않고 있으며, 2021년 5월부터 LCP를 SEO 시그널로 사용하기 시작할 것이라고 주장합니다. 지금까지 우리는 Google이 공개적으로 한 진술을 의심할 만한 이유를 찾지 못했으며, 반대를 입증하는 '동료 검토를 거친 확실한 증거’도 보지 못했습니다.
도움이 되기를 바랍니다.
---
### Author:  [@Mevo](https://meta.discourse.org/u/Mevo)
#### Post date: [11월 23, 2020, 1:37오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/92 "2020-11-23T13:37:34Z")
> [@neounix](#):
>
> 2021년 5월부터 LCP를 SEO 신호로 사용하게 됩니다.
그러니까 2020년 5월에 불만을 제기했던 모든 사람들에게 말하자면, 2021년 5월에 올 수 있는 것(들)에 비하면 아무것도 아니었나요? 😉 즉, Discourse 커뮤니티들이 내년 검색 결과 측면에서 타격을 입을 수 있다고도 말하고 계시잖아요(무슨 일이 일어날지는 지켜봐야 할 것 같습니다).
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [11월 23, 2020, 2:00오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/93 "2020-11-23T14:00:18Z")
> [@Mevo](#):
>
> 자, 2020년 5월 문제를 불평했던 분들을 위해 말씀드리자면, 2021년 5월에 닥칠지도 모를 것에 비하면 아무것도 아니었나요?
네, 저도 LCP와 구글의 코어 웹 바이탈(Core Web Vitals)이 가져올 영향에 대해 우려하시는 여기 모든 분들과 완전히 공감합니다.
또한, 이 다가오는 문제에 맞서 답과 해결책을 찾으려 애쓰고 계신 모든 분들을 높이 평가합니다.
2020년 5월 SEO 급락에 관해서는, 이 문제가 LAMP 서버에서도 발생했으므로, 본질적으로 Discourse의 문제는 아닙니다. 그리고 만약 우리가 무엇을 수정해야 하는지 높은 확신을 가지고 알고 있다면, 우리 모두가 "수정"하고 "조절"할 수 있을 것입니다. 그러나 우리는 여전히 이 2020년 5월 문제를 해결하기 위한 정확한 단계를 모르고 있습니다.
수년간 우리는 구글의 AI가 콘텐츠를 어떻게 분류하고 검색 결과(SERP)를 어떻게 조작하는지 보여주는 매우 기이한 결과들을 목격해 왔습니다.
제 이전 논점은, 검토 가능한 코드에 기반한 단단한 사실 대신 가정과 추측에 근거하여 Discourse 메타 팀에게 전체 생태계에 대한 매우 실질적인 구조적 변경을 강요하는 것이 근거가 부족해 보였다는 것이었습니다.
그럼에도 불구하고, LCP는 어쨌든 순식간에 매우 중요해질 것입니다.
감사합니다.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [11월 23, 2020, 5:06오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/94 "2020-11-23T17:06:09Z")
> [@Mevo](#):
>
> 이전에 이미 언급된 내용인 걸 알지만, 포럼의 빠르고 정적인 HTML 전용 버전을 생성해서 검색 엔진에 제공하도록 할 수는 없나요?
Discourse는 예전부터 이미 그렇게 작동하고 있습니다 😆
새로운 점은 LCP가 사람들의 안드로이드 폰에서 측정된다는 것입니다. 안드로이드는 우리가 지원하는 플랫폼 중 가장 느린 플랫폼이며, 이로 인해 우리에게 불균형한 영향을 미치고 있습니다.
@sam이 제안했던 것은 플러그인을 통해 일부 익명 사용자에게도 해당 뷰를 제공하는 것이었지만, 이는 당분간 진행되지 않을 예정입니다.
---
### Author:  [@Mevo](https://meta.discourse.org/u/Mevo)
#### Post date: [11월 23, 2020, 7:10오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/95 "2020-11-23T19:10:31Z")
> [@Falco](#):
>
> Discourse는 예전부터 그렇게 작동해 왔어요 😆
알겠습니다. 정확히 어떻게 작동하는지에 대한 지식이 부족합니다(하지만 처음에 로딩할 부분이 여전히 남아 있고, 더 빨라질 수 있을 것 같습니다. 그래서 이 전체 주제가 생긴 것입니다). 이 논의는 이미 10월 14일에 위에서 이루어졌습니다. Jeff 본인이 실제로 그 아이디어를 제기했습니다:
> [@codinghorror](#):
>
> 정말 이 지표에서 이기고 싶다면, Google AMP와 같은 정적 사전 생성 사이트를 사용해야 합니다.
>
> 왜냐하면 정적 페이지를 가진 사이트에는 _항상_ 질 수 있기 때문입니다.
> [@awesomerobot](#):
>
> 네, 상당한 엔지니어링 없이는 그 초기 로딩을 줄이는 방법이 없습니다. 왜냐하면 당신은 Discourse 앱 전체를 다운로드하고 있기 때문입니다.
> [@sam](#):
>
> 이 변경 사항을 수행하는 것(모든 익명 사용자에게 HTML 뷰 제공)은 분명히 가능하지만, 익명 사용자의 사용성에 큰 영향을 미칠 것입니다. 네, 그들은 콘텐츠를 더 빠르게 볼 수 있지만, 익명 사용자에게 작동하는 엄청난 양의 기능이 작동하지 않을 것이며, 익명 사용자에게 사이트가 “제대로” 보이지 않을 것입니다.
왜 콘텐츠를 가져와서 완전히 사전 생성된 정적 사이트를 만들지 않습니까? **최대한 빠르게** 작동하는 사이트입니다. 그리고 실제 포럼 대신 이 사이트를 검색 엔진에 제출하십시오. 아이디어는 여기에서 가장 중요한 것이 경험보다는 콘텐츠라는 것입니다. 그리고 검색 엔진에 중요한 것으로 보이는 전달의 속도에 집중하십시오.
무한 스크롤은 최근에 비난을 받지 않았지만, 무한 스크롤 없이 정적 사전 생성 _페이지_를 만들 것입니다. 그리고 **랠리 카처럼 디자인하십시오** : 엄격하게 필요하지 않은 모든 무게를 제거하십시오. 햄버거 메뉴도, 로고도, 게시자의 아바타도 없습니다. 오직 콘텐츠와 속도에만 집중하십시오.
이것은 좋은 식당(=Discourse 포럼)에서 테이크아웃 주문을 위한 드라이브-인(차량 이용 주문)을 설정하는 것과 같습니다. 같은 훌륭한 음식(=콘텐츠)이지만 경험은 없습니다. 검색 엔진에서 검색을 할 때(=차량으로 들어오면서) 스피커에 주문하고, 포장된 음식을 창문으로 받아 갑니다. 전체 아이디어는 그것이 요구되는 것이며, 음식(=콘텐츠)과 전달 속도만이 중요하다는 것입니다. 사람들이 음식을 좋아하면, 아마도 다시 와서 내부의 전체 경험을 즐길 것입니다.
그 후, 각 소유자(=관리자)의 선택에 달려 있습니다: 드라이브-인이 브랜드에 나쁘다고 생각하고 거절할 것인가, 아니면 많은 사람들이 내부에서 식사하러 오지 않을 것임을 알면서도(이미 많은 사람들이 그렇지 않으며, 더 나빠질 수 있습니다. 그리고 당신의 식당은 그렇게 제시되면 훨씬 덜 멋져 보일 수 있습니다) 더 많은 사람들을 끌어들이기 위해 그 길을 갈 것인가? 하지만 아마도 식당을 추천하는 그 유명한 웹사이트가 당신에게 더 많은 사람들을 보내줄 것입니다(효과적인지는 지켜봐야 합니다).
필요한 것은 포럼에 콘텐츠가 추가될 때 **이러한 정적 페이지를 생성하는 플러그인 또는 모듈** 일 것입니다(너무 복잡하지는 않을 것 같습니다). 실제 포럼(검색 엔진을 위해 “크롤링 금지”로 설정)에 여기저기 링크를 추가하기만 하면 됩니다. 이 솔루션을 사용할지 말지는 각 관리자의 몫입니다.
위에서 말한 것이 원칙적으로 맞고, 이 문제가 미래에 더 나빠질 수 있다면, 이것은 나에게 수용 가능한 해결책으로 보입니다. 아니면 제가 잘 이해하지 못한 것일 수도 있습니다. (참고: 물론 모든 것은 **읽기 전용** 일 것입니다)
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [11월 23, 2020, 7:15오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/96 "2020-11-23T19:15:58Z")
> [@Mevo](#):
>
> 알겠습니다. 정확히 어떻게 작동하는지에 대한 지식이 부족합니다(하지만 처음에 여전히 로딩이 이루어지는 것 같고, 더 빨라질 수 있을 것입니다. 그래서 이 전체 토론이 시작된 것입니다). 이 토론은 이미 10월 14일에 위에서 언급된 바 있습니다. 제프 본인이 실제로 이 아이디어를 제기했습니다:
> [@Mevo](#):
>
> 실제 포럼 대신 검색 엔진에 이를 제출하는 것은 어떨까요?
우리는 이미 크롤러에게 자바스크립트 없는 순수 HTML을 제공하고 있습니다 🙃
위에서 말했듯이, 문제는 새로운 LCP 점수가 크롤러가 아닌 사용자 브라우저에서 수집된다는 점입니다.
---
### Author:  [@Mevo](https://meta.discourse.org/u/Mevo)
#### Post date: [11월 23, 2020, 7:19오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/97 "2020-11-23T19:19:39Z")
알겠습니다. 그런데 제가 이해가 안 되는 부분은, 이 경우 아무도 더 잘하고 있지 않다는 거잖아요, 맞죠? 그러면 검색 결과에 왜 영향을 미치나요? Discourse 사이트가 다른 사이트만큼 잘 수행된다면(“만큼 잘”이거나 “만큼 나쁘게” 😉 ). 다른 사이트들도 Android에서 열리잖아요?
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [11월 23, 2020, 7:25오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/98 "2020-11-23T19:25:55Z")
Android는 단일 코어 성능에서 평균 이하의 수준을 보여, Discourse와 같은 무거운 단일 페이지 애플리케이션(SPA)의 성능에 영향을 미칩니다. 이 주제는 [2015년 Android의 JavaScript 상태는… 처참합니다](https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889)에서 심층적으로 다루고 있습니다.
최상급 iPhone은 Discourse 렌더링 시 가장 최신 Pixel보다 10배 빠릅니다. Google은 LCP(최대 콘텐츠 페인트) 계산 시 iPhone의 렌더링을 고려하지 않습니다. iOS에는 실제 Chrome이 존재하지 않기 때문에 이를 반영할 수 없기 때문입니다.
---
### Author:  [@Mevo](https://meta.discourse.org/u/Mevo)
#### Post date: [11월 23, 2020, 7:33오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/99 "2020-11-23T19:33:14Z")
> [@Falco](#):
>
> 무거운 단일 페이지 애플리케이션(SPA)에 영향을 미칩니다
그렇다면 검색 엔진에 제출할 목적으로 “소형 페이지” 사이트를 생성하는 것이 실제로는 이점이 있을 수도 있겠네요. 그렇게 하면 가치가 없을까요? (아마도 그렇지 않을 수도 있지만). 아니면 관리자들이 사용자에게 최신 플래그십 스마트폰을 제공해야 하는 건가요? 😉 최신 아이폰을 당첨되었다고 주장하는 모든 광고의 목적이 바로 그것인가요? 🤣
설명해 주셔서 감사합니다, Falco!
---
### Author:  [@Jonathan5](https://meta.discourse.org/u/Jonathan5)
#### Post date: [11월 23, 2020, 7:38오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/100 "2020-11-23T19:38:49Z")
> [@Mevo](#):
>
> 그러므로 검색 엔진에 제출할 대신 “소형 페이지” 사이트를 생성하는 것이 그 측면에서 실제로 이점이 있을 수 있습니다.
[Overview of CrUX | Chrome UX Report | Chrome for Developers](https://developers.google.com/web/tools/chrome-user-experience-report/) 이 링크를 빠르게 훑어본 결과, 구글은 (사용자의 허락을 받아) 사용자 정보를 수집하는 방식으로 데이터를 얻는 것 같습니다. 따라서 많은 사용자들이 여러분의 초라한 디스커스를 사용하도록 설득해야 할 것입니다 🙂
---
### Author:  [@eviltrout](https://meta.discourse.org/u/eviltrout)
#### Post date: [11월 23, 2020, 8:06오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/103 "2020-11-23T20:06:14Z")
> [@Yassine\_Yousfi](#):
>
> 저희 스타트업에서 Ember CLI를 사용하기 시작했는데, 그 이유 중 하나는 discourse에서 사용되고 있다는 것을 알게 되면서(이것이 저희의 관심을 끌었습니다) 테스트해 본 결과, 시작하기 쉽고 작업하기도 쉬웠기 때문이었습니다. 하지만 너무 부풀려져 있었습니다(다른 이유들도 있었지만).
>
> Ember CLI는 최근 업데이트를 도입했는데, 3.0 이전 버전으로 작성된 모든 앱이 다시 작성되어야 합니다. 그때 저희는 이를 완전히 제거하기로 결정했습니다.
Ember와 Ember CLI를 혼동하고 계신 것 같습니다. Ember는 저희가 이미 사용 중인(8년 이상 사용해 온) 프레임워크입니다. Ember CLI는 Rails의 에셋 파이프라인 대신 사용하기로 이주하는 명령줄 도구입니다. 말씀하신 내용 중 일부(3.0 이전 버전은 재작성이 필요하다는 점)는 Ember CLI에는 해당하지 않지만, Ember에는 해당할 수 있기 때문에 이 점을 언급합니다.
> [@Yassine\_Yousfi](#):
>
> Ember CLI를 사용하든 아니든, 렌더링 시간이 항상 나쁜 편이기도 합니다(여기서 논의 중인 LCP 문제를 해결하는 데 도움이 되지 않습니다).
다시 한번 말하지만, 렌더링을 수행하는 것은 Ember CLI가 아니라 Ember입니다. 그리고 때로는 성능 문제가 발생합니다. 참고로 이것은 Ember에 특화된 문제가 아닙니다. 현재 모든 프레임워크에는 주의해야 할 성능 함정이 있습니다. Ember를 몇 년간 사용하면서, 더 나은 성능이 필요한 두 가지 핫스팟(헤드와 토픽 뷰)을 식별했고, 가상 DOM 기반 접근 방식으로 전환했습니다.
Glimmer/Ember Octane이 어떻게 작동하느냐에 따라 항상 이렇게 해야 하는 것은 아닐 수 있지만, 코드는 상당히 안정적이며 이제 구형 모바일 기기에서도 빠르게 실행됩니다.
> [@Yassine\_Yousfi](#):
>
> 하지만 Ember CLI로 업그레이드하면 더 많은 문제가 발생할 수 있습니다. 왜냐하면 아직 안정화되지도 않은 Ember Octane으로 다시 업그레이드해야 하기 때문입니다.
Ember Octane은 3.15에서 소개되었고, 이후 두 번의 LTS 릴리스(3.16과 3.21)가 있었습니다. 저희는 이를 단계적으로 업그레이드할 예정입니다. 다행히도 Ember 팀은 어떤 형식을 사용하고자 하는지(파일별로도!) 선택할 수 있도록 허용합니다.
* * *
이 모든 것을 고려할 때, Ember에 대해 비판할 수 있는 부분이 적지 않습니다. 과거에 성능이 Discourse에 더 큰 문제가 되었을 때, 약속된 몇 가지 릴리스가 오히려 저희를 돕기보다는 해를 끼쳤습니다. 그것은 힘든 일이었습니다. 저희의 요구 사항을 충족시키기 위해 오랫동안 매우 주의를 기울여야 했습니다.
오늘날, Ember는 React와 같은 새로운 프레임워크에 비해 인기가 훨씬 낮습니다. 하지만 8년 전에는 React가 존재하지 않았습니다! 당시 저희의 선택지는 Angular, Ember, Knockout뿐이었습니다. Ember 업그레이드가 어렵다고 생각하신다면, Angular가 1버전에서 2버전으로 겪은 과정을 보시면 될 것입니다(게다가 Dart와의 부수적인 시도까지!).
수년간 Ember를 업그레이드하는 것은 많은 노력이 필요했지만, 적어도 그것이 하나의 옵션은 아니겠습니까! 다른 어떤 프레임워크도 이러한 종류의 업그레이드 경로를 제공하지 않았습니다.
Vue/Next/React로 재작성하는 것에 대해서는, 사람들이 저희가 가지고 있는 잘 작동하는 코드량이 얼마나 많은지 심각하게 과소평가하고 있다고 생각합니다. 그것은 감히 상상할 수 없는 양의 작업이 될 것입니다.
---
### Author:  [@guidoleenders](https://meta.discourse.org/u/guidoleenders)
#### Post date: [11월 23, 2020, 8:14오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/104 "2020-11-23T20:14:13Z")
네, 맞습니다. 사용자 대다수가 구형 기기를 사용하는 경우, 사이트의 평가가 낮게 나올 수 있습니다.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [11월 23, 2020, 8:57오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/105 "2020-11-23T20:57:09Z")
저는 @justin님과 @awesomerobot님을 고려하고 있지만, 먼저 Robin이 Ember CLI의 세부 사항에 대해 의견을 들어보고 싶었습니다.
핵심적으로, 여기에는 ["멈출 수 없는 힘이 움직일 수 없는 물체에 부딪히면 어떻게 될까?"](https://en.wikipedia.org/wiki/Irresistible_force_paradox)라는 역설이 조금 있습니다. 우리는 의도적으로 JavaScript 앱(또는 SPA)으로 만들어졌으며, 이는 2012/2013년에 2022/2023년의 미래가 어떻게 보일지에 대한 우리의 최선의 추측을 바탕으로 결정한 트레이드오프가 포함됩니다. 저는 분명히 편향되어 있지만, "음, 모바일 기기의 브라우저 성능이 데스크톱 브라우저 성능과 구별할 수 없을 정도로 좋아질 것이다"라는 우리의 예측은 정확히 적중했다고 생각합니다.
사실 적중을 넘어선 수준입니다. 최근 대부분의 Apple 폰은 랩톱과 데스크톱보다 \_더 빠르\_기 때문입니다. 😲 그건.. 제가 \_예상하지 못\_한 일이었습니다!
>
🎯
우리는 첫 로딩 속도 – 그리고 전반적인 속도 --를 개선할 수 있는 부분은 계속 개선해 나갈 것입니다. 하지만 이 부분에서 우리의 전적은 칭찬할 만하다고 생각합니다. 한 가지 예로, 2015년에 우리가 많은 주목을 받자 Google이 내부적으로 V8, Chrome, Android에서 약한 Qualcomm SoC의 JavaScript 성능 문제를 해결하기 위해 상당한 개선을 했습니다.
우리의 아킬레스건은 .. \_Qualcomm\_이었습니다. 안타깝게도 Qualcomm은 지금까지 성능 측면에서 매우 좋은 성과를 내지 못했으며, "최고"의 성능을 내는 Android 기기는 대략 iPhone 7 수준에 불과합니다. 오래된 Android 기기가 시장에서 완전히 사라지는 데는 오랜 시간이 걸리지만, 855와 865는 모두 대략 iPhone 7 수준의 괜찮은 성능을 보였습니다:
가장 빠른 Android 기기만큼 느린 Apple 기기를 찾으려면 더 아래로 스크롤해야 하지만, 그렇게 하면 가장 가까운 매치는 Geekbench에서 약 910점을 기록한 iPhone X / iPhone 8입니다. 불행히도 865는 제가 완전히 이해하지 못하는 이유로 웹 측면에서 약간 낮은 성능을 보이므로, Speedometer에서는 여전히 iPhone 7 성능 수준에 머물러 있습니다:
다양한 회사의 다양한 SoC를 탑재한 Android 기기가 출시되어, 모두 가장 빠르고 강력한 SoC를 만들기 위해 경쟁하는 세계에 살고 싶다. 😿 긍정적인 측면에서, **iPhone 7의 성능은 Discourse에 있어 안정적** 이며, _결국_ 모든 Android 기기, 심지어 오래된 기기들도 "iPhone 7만큼은 빠를 것"이라는 점에서 기쁩니다. 또한 다가오는 Snapdragon 875를 위해 손가락을 꼬아 들고 있습니다. 향후 몇 달 내에 이에 대한 더 자세한 정보가 나올 것입니다. 🤞
> Geekbench 5 결과에 따르면, Xiaomi Mi 11은 5nm Snapdragon 875로 구동되는 것으로 확인되었습니다(이것은 Xiaomi 임원 루 웨이빙이 암시한 바와 같습니다). 곧 출시될 Xiaomi Mi 11은 싱글코어 벤치마크에서 1,102점, 멀티코어 테스트에서 4,113점을 기록했습니다.
만약 이것이 사실이라면, 이는 A12 수준에 해당할 것이며,hopefully 웹 측면에서도 그 효과가 나타날 것입니다!
어쨌든, Discourse에는 \_JavaScript 앱이 되자\_는 핵심 아키텍처 결정이 있습니다 … 그리고 우리는 가시적인 미래까지 이 경로에 전적으로 헌신하고 있습니다.
---
### Author:  [@Jumanji](https://meta.discourse.org/u/Jumanji)
#### Post date: [12월 8, 2020, 7:04오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/109 "2020-12-08T19:04:28Z")
통계를 주시하고 계신 분들을 위해, 또 다른 날짜를 기록해 두시기 바랍니다. 2020년 12월 구글의 최신 코어 업데이트와 관련하여 앞으로 몇 주 동안 어떤 일이 벌어질지 지켜보는 것이 흥미로울 것입니다.
> **[Google's December 2020 core update was big, even bigger than May 2020, say...](https://searchengineland.com/googles-december-2020-core-update-was-big-even-bigger-than-may-2020-says-data-providers-344429)**
>
> The update rolled out on Dec 3, but the impact was mostly felt on Dec. 4.
---
### Author:  [@anon82467725](https://meta.discourse.org/u/anon82467725)
#### Post date: [12월 8, 2020, 7:26오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/110 "2020-12-08T19:26:54Z")
> [@codinghorror](#):
>
> 놀랍게도, 목표치를 넘어서서 말이죠. 최근 Apple 스마트폰들은 노트북과 데스크톱보다 _더 빠르니까요_. 😲 그건… 내가 _예상하지 못한_ 일이었습니다!
최근 발표된 Apple Silicon Mac을 잊을 수 없죠! 😀
> [@codinghorror](#):
>
> 2015년에 정말 많은 주목을 받았죠
호기심이 생겨서요, 그 주목은 어디에서 왔던 건가요?
> [@codinghorror](#):
>
> iPhone 7의 성능은 Discourse에 대해 꽤 안정적입니다
A10 칩은 아직 간신히 버티고 있는 수준입니다.
> [@codinghorror](#):
>
> 만약 사실이라면, 그건 A12 수준이 되겠네요
혹시 모를 상황에 대비해 기대치를 낮게 잡고 있습니다. Apple은 _항상_ 한 발 앞서 있었으니까요.
그럼에도 불구하고, Android 스마트폰은 아직 따라잡기 위해 노력하고 있습니다. 정말 터무니없는 일이죠. Apple은 이미 A14 칩을 보유하고 있으며, 아마도 내년용 A15 칩 개발에 착수했을 겁니다.
---
### Author:  [@justin](https://meta.discourse.org/u/justin)
#### Post date: [12월 8, 2020, 9:40오후 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/111 "2020-12-08T21:40:34Z")
공유해 주셔서 감사합니다. 해당 기사에서 이 토론과 관련된 몇 가지 항목을 발췌해 보겠습니다.
> **코어 업데이트로 인해 피해를 입었을 때 해야 할 일.** Google은 과거에 코어 업데이트로 인해 부정적인 영향을 받았을 때 고려해야 할 사항에 대한 조언을 제시한 바 있습니다. 검색 순위를 회복하기 위한 구체적인 조치는 없으며, 실제로 순위가 하락했다고 해서 페이지에 문제가 있다는 신호는 아닙니다. 그러나 Google은 [코어 업데이트로 인해 사이트가 피해를 입었을 때 고려해야 할 질문 목록](https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184)을 제공했습니다. Google은 코어 업데이트 사이에 [일定的한 회복을 볼 수 있다고](https://searchengineland.com/google-says-you-can-recover-from-core-updates-without-a-new-core-update-340396) 언급했지만, 가장 큰 변화는 다음 코어 업데이트 후에야 나타날 것이라고 했습니다.
이 부분도 도움이 됩니다.
> **[Google advice on improving your site's ranking for future core ranking update](https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184)**
>
> Google has finally given us something we can point to after a core updates negatively impacts a site's ranking in Google search.
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [12월 9, 2020, 12:13오전 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/112 "2020-12-09T00:13:09Z")
> [@anon82467725](#):
>
> 그럼에도 불구하고, 안드로이드 스마트폰은 여전히 추격하는 단계입니다. 정말 터무니없는 일입니다. 애플은 이미 A14 칩을 가지고 있으며, 아마도 내년용 A15 칩을 개발하고 있을 것입니다.
제 생각에는 SEO(검색 엔진 최적화)를 이야기할 때, 이는 다른 사이트들과 비교했을 때 검색 엔진 결과의 최적화를 의미하며, 사용자 하드웨어에 대한 논의는 대부분 관련이 없습니다.
왜일까요?
사실 꽤 단순합니다.
한 사용자와 그 사용자의 휴대용 기기에서의 검색 결과를 생각해 봅시다.
기기의 속도나 칩셋이 무엇이든, 최종 사용자 경험(성능)은 네트워크에서 단일 사용자 기기의 경우, 유사한 성능을 가진 모든 웹사이트에서 대부분 동일할 것입니다. 더 빠른 웹사이트는 빠르고, 느린 웹사이트는 느립니다. 최종 사용자 기기의 칩셋 등과는 무관하게요. 물이 차오르면 모든 배가 함께 오르고, 물이 빠지면 모든 배가 함께 가라앉는 것과 같습니다. SEO에서 최종 사용자 기기는 최적화되는 대상인 서빙 애플리케이션(서버 측)에 비해 SEO 신호로서의 “노이즈”(간섭)에 불과합니다.
따라서 모바일 폰이 우주 전체에서 가장 빠른 폰이라고 해도, 모든 웹사이트는 네트워크 속도와 웹사이트 디자인에 따라 빠르거나 느릴 것입니다. SEO의 초점은 최종 사용자 기기가 아니라 웹 애플리케이션의 최적화와 그 애플리케이션의 전달에 있습니다. 웹 앱이 특정 칩셋에서 “놀라울 정도로 훌륭하게” 작동한다면, 유사한 디자인을 가진 다른 모든 웹사이트도 마찬가지입니다. SEO의 초점은 최종 사용자 기기가 아니라, 웹 애플리케이션, 콘텐츠, 서버 기반 로딩 시간의 최적화에 있습니다. 클라이언트 기기가 아닙니다. 클라이언트 기기는 이론적으로 모든 웹사이트를 방문하므로, SEO의 신호 대 노이즈 비율에서 이는 모두 "노이즈"입니다.
웹사이트 SEO 관점에서 보면, 사용자 경험 기반의 검색 엔진 최적화는 모든 최종 사용자 모바일 기기의 동일한 클래스(성능 특성)를 가진 모든 사용자에게 네트워크 전체에서 동일할 것입니다. 한 웹사이트가 다른 웹사이트보다 SEO 우위를 점하는 유일한 요인은 최종 사용자 기기가 아니라 웹사이트의 성능(그리고 그 네트워크)입니다.
왜일까요?
일반적으로 최종 사용자 기기는 모든 웹사이트에서 동일한 성능을 발휘하기 때문입니다. 사용자의 모바일 기기가 메모리나 칩셋 때문에 느리다면, 그것은 사이버버스의 모든 웹사이트에서 느릴 것입니다. 다시 말해, 최종 사용자 기기가 SEO에 어떻게 영향을 미치는지에 대한 논의는 무의미합니다. 검색 엔진 최적화는 클라이언트 측 작업이 아니라 서버 측 작업입니다.
중요한 것은 콘텐츠, 표현, 성능이며, 구글의 AI가 이러한 요소들을 사이버버스 전체에서 어떻게 평가하느냐입니다. 예를 들어, 전 세계 모든 사람이 양자 컴퓨팅 모바일 폰으로 업그레이드한다고 해도, 모든 최종 사용자가 동일한 "최종 사용자 기기 성능 곡선"을 가지므로 SEO는 동일할 것입니다. 최적화는 제공자(웹사이트)에서 발생합니다. 마찬가지로, 사이버버스 전체가 느린 칩셋의 모바일 폰으로 퇴보한다고 해도, 웹 콘텐츠를 서빙하는 서버에서 최적화가 일어나므로 검색 엔진 랭킹은 대부분 동일할 것입니다.
물론 자바스크립트 기반의 SPA인 Discourse는 모바일 기기가 빠를수록 로드 후 더 잘 작동할 것입니다. 다른 모든 웹사이트도 마찬가지입니다! 일반적으로 SEO 측면에서 중요한 것은 최종 사용자 기기가 아니라 네트워크 성능과 서버 성능입니다. 이것은 제 의견이 아니라 과학적, 공학적 사실입니다. 제 의견이나 자바스크립트 또는 EmberJS에 대한 정서적 연결은 SEO가 작동하는 방식을 바꾸지 않습니다. SEO에 효과적인 것은 콘텐츠와 웹 애플리케이션의 성능입니다.
마무리하며, 구글은 고급 AI, 주로 인공 신경망을 사용하여 웹 콘텐츠를 어떻게 랭킹하고 색인하는지 결정합니다. 검색 엔진 최적화는 구글의 AI가 사이트를 어떻게 랭킹하는지, 사이트의 성능, 그리고 사이트의 "구글 AI에 대한 매력"에 기반합니다. 우리가 자바스크립트나 루비, 파이썬을 얼마나 좋아하든, 또는 최종 사용자에게 제공하는 웹 애플리케이션의 우아함과 메커니즘을 얼마나 좋아하거나 숭배하든 그것은 관련이 없습니다. 우리의 애플리케이션에 대한 열정이 구글의 AI에 호소하고, 구글의 AI가 잘 표현된 고유한 콘텐츠를 생성하며, 구글의 AI가 성능을 어떻게 지각하는지에 초점을 맞추는 경우를 제외하면 말입니다. 우리가 성능과 콘텐츠를 어떻게 지각하는지가 아닙니다.
우리는 우리의 웹사이트를 랭킹하지 않습니다. 구글의 AI가 랭킹합니다.
구글이 공개적으로 발표한 바에 따르면:
> "코어 업데이트가 어떻게 작동하는지 이해하는 한 가지 방법은 2015년 최고의 영화 100편 목록을 작성했다고 상상하는 것입니다. 몇 년 후인 2019년에 목록을 새로 고치면, 자연스럽게 변경될 것입니다. 이전에 존재하지 않았던 새로운 놀라운 영화들이 이제 포함될 후보가 될 것입니다. 또한 일부 영화들을 재평가하여 이전에 있던 것보다 목록에서 더 높은 자리가 마땅하다고 깨달을 수도 있습니다. 목록은 변경되며, 목록에서 더 높은 곳에 있다가 아래로 내려간 영화들이 나쁜 것은 아닙니다. 단순히 그들보다 더 자격이 있는 영화들이 앞서고 있는 것뿐입니다."라고 구글은 썼습니다.
> 이 회사는 콘텐츠를 평가할 때 고려해야 할 다음과 같은 질문 목록을 제시했습니다:
> - 콘텐츠가 고유한 정보, 보도, 연구 또는 분석을 제공합니까?
> - 콘텐츠가 주제의 실질적이고 완전하거나 포괄적인 설명을 제공합니까?
> - 콘텐츠가 명백한 것 이상의 통찰력 있는 분석이나 흥미로운 정보를 제공합니까?
> - 콘텐츠가 다른 출처를 참조하는 경우, 단순히 그 출처를 복사하거나 다시 쓰는 것을 피하고 대신 실질적인 추가 가치와 독창성을 제공합니까?
> - 헤드라인 및/또는 페이지 제목이 콘텐츠에 대한 설명적이고 유용한 요약을 제공합니까?
> - 헤드라인 및/또는 페이지 제목이 과장되거나 충격적인 성격을 피합니까?
> - 이 페이지를 북마크하고 싶거나, 친구와 공유하거나, 추천하고 싶은 종류의 페이지입니까?
> - 인쇄 잡지, 백과사전, 또는 책에서 이 콘텐츠를 보거나 참조하는 것을 기대합니까?
이것이 SEO이며, 구글의 핵심 사업은 기계가 웹사이트를 점수화하고 분류할 수 있도록 알고리즘을 만드는 것입니다.
> **[Google advice on improving your site's ranking for future core ranking update](https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184)**
>
> Google has finally given us something we can point to after a core updates negatively impacts a site's ranking in Google search.
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [12월 9, 2020, 12:43오전 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/113 "2020-12-09T00:43:42Z")
> [@neounix](#):
>
> 제 생각에 SEO는 다른 사이트들과 비교했을 때 검색 엔진 결과를 최적화하는 것을 의미하므로, 사용자 하드웨어에 대한 논의는 대부분 관련이 없습니다.
이것은 기록과 일치하지 않습니다. 구글이 안드로이드 기기에서 실제 페이지 로드 시간을 수집하여 페이지 랭킹에 사용하고 있다는 것을 알고 있기 때문입니다.
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [12월 9, 2020, 1:06오전 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/114 "2020-12-09T01:06:25Z")
> [@riking](#):
>
> 이것은 기록과 일치하지 않습니다. 구글이 안드로이드 기기에서 실제 웹페이지 로드 시간을 수집하고 이를 페이지 랭킹에 사용하고 있다는 것은 잘 알려져 있습니다.
네, 하지만 모든 안드로이드 기기(동일한 유형)는 모든 웹사이트(동일한 유형)에서 기본적으로 동일한 성능을 보입니다. 다시 말해, webpacker와 bundler를 사용하는 자바스크립트 기반 웹사이트를 최적화한다면, SEO 관점에서 webpacker와 bundler 등을 사용하는 다른 모든 자바스크립트 SPA 사이트와 경쟁하는 것입니다.
제가 구글이 이 정보를 수집하지 않는다고 말한 적은 없습니다. 저는 클라이언트 기기에 초점을 맞추는 것이 SPA SEO 성능 문제를 해결하지 못한다는 점을 설명하려는 것입니다. "물살이 높아지면 모든 배가 함께 뜹니다"라는 말처럼, 압축된 JS를 잘 처리하는(빠르고, 최적화된 등) 더 빠른 CPU는 모든 유사한 웹사이트에서 뛰어난 성능을 발휘할 것입니다.
즉, SEO는 클라이언트 측이 아니라 서버 측에 있습니다(위에서 상당히 시간과 분량을 들여서 입력했듯이).
참고로, 이는 잘 문서화되어 있습니다.
아무튼 :). 저는 meta에서 이 문제를 논쟁하고 싶지 않습니다. 감사합니다.
구글은 현재 및 2021년 이후로 어떤 것이 중요한 SEO 신호로 간주하는지에 대해 매우 명확하게 입장을 밝혀왔습니다. 그들은 사이버 공간의 사건과 상황에 따라 AI를 지속적으로 재설계할 것입니다.
---
### Author:  [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [12월 9, 2020, 7:03오전 UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/115 "2020-12-09T07:03:37Z")
> [@neounix](#):
>
> , webpacker와 bundler를 사용하는 JavaScript 기반 웹사이트를 최적화한다면, SEO 관점에서 webpacker와 bundler를 사용하는 다른 모든 JavaScript SPA 사이트와 경쟁하게 됩니다.
SEO 관점에서 보면, 기술적으로 유사한 사이트들과 경쟁하는 것이 맞습니다.
하지만 비즈니스 관점에서는 기술과 관계없이 해당 시장 내 다른 사이트들과 경쟁합니다. 그리고 이는 SEO 관점에서 “더 나은” 것으로 인식되는 기술로의 전환을 고려하게 만들 수 있습니다. 일부 사람들은 바로 그런 상황에 놓여 있습니다.
[Previous page](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369.md?page=4)
[Next page](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369.md?page=6)