제 forum의 Lighthouse 성능 카테고리 점수가 매우 낮아 구글에서 패널티를 받고 있습니다.
이 속도를 개선할 방법이 있을까요? 제 사이트에는 약 2,000명의 회원, 10만 개의 게시물, 5,000개의 주제가 있습니다. DigitalOcean의 4GB RAM 플랜을 사용하고 있습니다.
Discourse에서는 Cloudflare 템플릿 활성화 외에는 기본 설정만 사용하고 있습니다.
다만 플러그인을 꽤 많이 설치해 두었습니다.
포럼의 속도를 개선하기 위한 팁이 있을까요?
그 때문인가요? 전혀 그렇지 않다고 확신합니다.
구글 서치 콘솔의 성능 섹션에 따르면, 사이트의 로딩 속도가 느리다고 표시됩니다. PageRank가 웹사이트 순위 결정 시 이 요소를 고려한다는 이야기를 들었습니다.
그럼에도 불구하고 사이트가 느린 것은 아니며, 구글도 이에 대해 패널티를 부과하지 않습니다. 외부에는 PageRank에 대한 오해와 잘못된 정보가 넘쳐나는데, 이 주장도 그 범주에 속합니다.
그렇지 않다면, 최적화 문제는 실제로는 매우 쉽습니다. 할 수 있는 일이 많지 않습니다. WordPress라면 PHP와 사이트 작동 방식 때문에 몇 가지 옵션이 있지만, Discourse와 같은 앱의 경우 비슷한 도구가 없습니다.
물론 더 빠른 VPS와/또는 DNS를 찾아볼 수는 있지만, 그것이 전부이며 실제로 돈값을 하는 결과를 얻지는 못할 것입니다.
이것은 정확하지 않습니다. 페이지 속도는 이미 꽤 오래전부터 검색 신호(search signal)로 사용되어 왔으며, 비록 높은 랭킹 요인은 아니지만 그렇습니다. 구글은 크롤러 뷰와 CrUX의 데이터를 모두 사용했는데, 현재에도 여전히 그런지는 확실하지 않습니다.
네, 맞습니다. 다만 PageRank과 진정한 의미의 SEO에 영향을 미친다는 측면에서는 아닙니다.
맞습니다. Evaluating page experience for a better web | Google Search Central Blog | Google for Developers
검색은 페이지가 얼마나 빠르게 로드되는지와 모바일 친화성과 같은 다양한 사용자 경험 기준을 검색 결과 랭킹의 요인으로 추가했습니다.
이 모든 플러그인을 비활성화한 상태에서 속도를 확인할 수 있는 방법이 있다면, 꽤 유용한 정보가 될 수 있습니다. Discourse는 본질적으로 느린 시스템이 아닙니다 - 제 Lighthouse 점수는 100점입니다.
가능하다면, 플러그인의 절반만 활성화하여 측정을 해보시면 성능 문제를 일으키는 특정 플러그인으로 범위를 좁힐 수 있을 것입니다. 하지만 문제의 원인이 단 하나의 플러그인 때문만은 아닐 수도 있습니다.
안녕하세요 
다른 접근 방식에 대해 말씀드릴게요… 저는 항상 이런 유형의 서버를 운영하는 데 문제가 있었습니다. 커뮤니티 활동에는 속도가 느렸거든요. 그래서 서버를 Vultr로 이전했습니다. 이 가격대에서 Vultr의 High Frequency 서버가 가장 좋다고 생각합니다. Discourse는 멀티코어보다 단일 코어 CPU가 더 빠를 때 훨씬 더 잘 동작합니다. 제가 아는 한, 3GHz 이상의 vCPU를 HF 라인에서 제공하는 곳은 Vultr뿐입니다. 이 서버들에서 속도 관련 문제는 한 번도 겪어본 적이 없습니다. 초고속이고 안정적입니다! 
저는 2vCPU, 4GB RAM, 128GB NVMe SSD 구성의 서버를 사용하고 있습니다. 몇 년째 Vultr HF 서버를 이용해 왔습니다. 꼭 한 번 시도해 보시길 강력히 추천합니다.
좋은 정보 감사합니다. Vultr 서버에 대한 측정값을 어딘가에서 찾을 수 있을까요?
DO와 비교하면 아직 재구축을 하지 않았지만, 가능해지면 타이머를 설정하여 재구축을 진행할 예정입니다. 기억이 맞다면 보통 약 5분이 소요되며, 서버의 실제 성능도 확인할 것입니다. 이 게시글을 업데이트하겠습니다. 
CPU 정보:
Intel Core Processor (Skylake, IBRS)
cpu MHz: 3695.998
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 94
model name : Intel Core Processor (Skylake, IBRS)
stepping : 3
microcode : 0x1
cpu MHz : 3695.998
cache size : 16384 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_stale_data retbleed
bogomips : 7391.99
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
---
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 94
model name : Intel Core Processor (Skylake, IBRS)
stepping : 3
microcode : 0x1
cpu MHz : 3695.998
cache size : 16384 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_stale_data retbleed
bogomips : 7391.99
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
13개의 플러그인을 사용하며 s3 객체 저장소와 YJIT를 활성화한 상태에서의 재구축 시간입니다. 따라서 이 기능들을 사용하지 않거나, 새로운 설치 환경에서는 더 빠를 수 있습니다.
time ./launcher rebuild app
real 5m49.787s
Discourse의 온라인 사용자 플러그인은 성능 저하를 유발할 수 있습니다.
유용한 팁들을 많이 주셔서 감사합니다. 꼭 Vultr를 사용해 보겠습니다!
Discourse와 같은 앱에서 이러한 지표는 얼마나 신뢰할 수 있습니까? 이 방법은 더 전통적인 웹 페이지에 대해서는 이미 적용된 바 있습니다. 또한 PHP를 나중에 로드하는 등의 옵션이 없는 상황에서 정확히 어떻게 성능을 개선할 수 있을까요?
우리가 할 수 있는 일은 다음과 같습니다.
사이트에서 여러 문제를 분리하는 데 매우 유용했습니다. 특정 테마 컴포넌트나 플러그인을 켜고 껐을 때 사이트를 비교하는 방식으로 구체적으로 문제를 찾았습니다. 또한 큰 파일을 분리하고 콘텐츠 시프트를 식별하는 데에도 좋습니다.
도움이 되었던 또 다른 옵션은 인스펙터 패널에서 접근할 수 있는 Chrome의 내장 성능 테스트를 사용하는 것이었습니다.
저도 같은 문제가 있었습니다. SAS 디스크(기본 300 IOP, 버스트 시 1000 IOP)를 SSD 디스크(기본 1500 IOP, 버스트 시 3000 IOP)로 변경한 결과 성능이 10배 향상되었습니다. (해당 IOP 값은 제가 사용하는 클라우드 제공사의 제한 값입니다)
오래된 자료이지만, 얼마 전에 실행한 벤치마크를 여기에서 볼 수 있습니다.
테스트는 흥미로워 보이지만, Vultr에서의 Discourse 벤치마크에 대해서는 많은 것을 말해 주지 않습니다.
제 최고의 추천은 Linode입니다. 이 모든 서버로 속도 측정을 해봤는데, DO가 가장 느렸고, 2위는 Vultr, 1위는 Linode(Akamai)였습니다.
