사이트 속도 최적화 - 어떻게 개선할까요?

이 성능 테스트 웹사이트들에 대해 여러분은 어떻게 생각하시나요? 방금 3가지 테스트를 진행했습니다:
GTmetrix, PageSpeed, 그리고 WebpageTest. 물론 각기 다른 변형이 있지만, 몇 가지 공통점도 있습니다. 어제 GTmetrix에서 C 등급을 받았는데, B 등급은 꽤 좋은 개선입니다 - 다만 어디서 그런 결과가 나왔는지는 모르겠네요.

제가 파악한 바로는, 이 3가지 테스트에서 제 사이트의 가장 공통적인 문제는 JavaScript와 CSS 로딩 시간인 것 같습니다. 그런데 JS는 제 통제 범위 내에 있는 건가요? GTmetrix에서 두 개의 URL을 미사용 JS로 표시하고 있는데, 이건 Discourse에 내장된 것 아닌가요?

https://forums.gonomad.me/assets/chunk.2c7ac65fdfc1f35c61b6.d41d8cd9.js
https://forums.gonomad.me/assets/vendor.47fe1949ff0285dbc995d87a6ae0d449-223fd39128ca149073c28a57e41e969bafdb0a241e1149adab6918b27e7a3265.js

그리고 38.8s의 경로 지연(path latency)으로 표시된 항목을 보고 꽤 흥미를 느꼈습니다. 도대체 어떻게 최적화하거나 수정해야 하는 걸까요?

PageSpeed에서는 JS/CSS 렌더링 차단 리소스 관련해서 비슷한 내용을 지적했습니다. 사이트를 늦추는 가장 큰 JS 파일들은 다음과 같습니다:

https://forums.gonomad.me/assets/chunk.2c7ac65fdfc1f35c61b6.d41d8cd9.js
https://forums.gonomad.me/assets/locales/en-d255b87afa1b13a48418c34b7c45d8aa69fce223261f36c9a101fb022c7cb8e5.js

하지만 역시, 이건 Discourse에 내장된 것 같지 않나요?

마지막으로, Dev Console에서 직접 Lighthouse 테스트를 해보니 63점을 받았습니다:

다른 사용자들이 로딩 문제를 겪었던 다른 주제와 관련이 있나요?

대신 호스팅 환경을 살펴보는 것이 좋을 것 같습니다. :thinking:

결과 자체는 괜찮아 보입니다.

어떤 의미에서는 그렇다고 볼 수 있죠. 그 일 때문에 이런 생각이 들게 되었어요, 하하.

저도 주로 그렇게 생각하고 있었지만, 어쨌든 이 성능 테스트 사이트들의 점수가 마음에 들지 않기도 해요. (아, 이건 호스팅 문제 때문일 수도 있겠네요?)

CDN 설정은 항상 좋은 시작입니다. :rocket:

요즘 이 최적화 여정에서 CDN에 대해 많이 읽었습니다. 한번 확인해 보겠습니다!

음 … 그만한 효과에 비해 불필요한 복잡성이 너무 많습니다.

저는 CDN을 사용하지 않고도 몇 년간 커뮤니티를 성공적으로 운영해 왔습니다.

트래픽이 많나요? 서버 설정을 알려줄 수 있을까요?

트래픽이 많지는 않을 겁니다. 등록한 사용자가 몇 명뿐이니까요. 사이트를 만든 지 겨우 12일 정도밖에 안 됐습니다. 서버가 호스팅된 지역의 피크 시간대에 일부 사용자에게는 느리게 느껴지는 것 같지만, 다른 사용자에게는 문제가 없는 것 같습니다. 서버/VPS 사양은 다음과 같습니다:

3GB RAM
2vCPU
35GB SSD
1Gbps 무제한 대역폭
IPv4 1개
KVM
Ubuntu 22

수정: 제가 답글을 달아야 하는지, 로버트가 답글을 달아야 하는지 확신이 없었네요.

사이트가 항상 매우 반응적으로 유지될 수 있을 정도로 낮습니다.

4GB/3 vcores + 2GB Swap.

글로벌 사용자가 많거나 VPS가 저사양 서버에 위치해 있는 경우, CDN이 일부 도움이 될 수 있습니다. 또한 PHP 기반 사이트는 캐싱 정책을 잘 설정하면 더 큰 효과를 볼 수 있으며, 단순한 개선보다는 캐싱 정책이 더 중요합니다.

Discourse의 특성상 이러한 개선 효과가 무효화될 수 있으며, 다른 표현을 하자면 이러한 도움이 필요하지 않을 수 있습니다.

이러한 메트릭 서비스에는 많은 문제가 있으며, 이러한 팁을 그대로 적용하기는 매우 드뭅니다.

네, 제가 조금 혼란스러운 부분이 바로 그겁니다. 기본적으로 지적받는 항목(긴 JS 로딩 시간/블로킹 등)은 대부분 Discourse에 내장된 것 같고, 제 테마와 결합된 결과일 수도 있습니다. 그렇다면 Discourse 사이트는 이런 점들에서 좋은 점수를 받을 수 없는 건가요, ㅋㅋ? 하지만 포럼, 특히 포럼의 경우엔 그런 건 아닌 것 같기도 하네요.

그렇습니다. 일부(불필요한) 기능, 주로 플러그인을 통해 제거하는 것으로는 크게 도움이 되지 않습니다. 하지만… 실질적인 이점은 전혀 없습니다.

좋은 소식은 이것이 전혀 중요하지 않다는 것입니다. 그리고 사용자의 인터넷 서비스와 디바이스가 더 큰 병목 현상이기 때문입니다.

여유 시간이 너무 많다면 이것저것 개발을 시작해 볼 수 있지만, 얻는 것은 여기에서 2초, 저기에서 1초 정도 절약되는 것일 뿐입니다 — 그리고 이러한 절약은 실험실 테스트로만 측정 가능합니다.

팀과 플러그인/테마 개발자들이 각자의 일을 하도록 두세요. 그것이 충분합니다.

만약 WordPress, Drupal 등의 “진짜” 웹 플랫폼을 사용한다면, 할 수 있는 트릭이 훨씬 더 많을 것입니다. 하지만 지금의 해결책은 근본적으로 다릅니다.

그리고 물론 — 저는 또 다른 가정용 관리자/웹마스터일 뿐이며, 만약 제가 틀렸다면 바로잡아 주십시오. 하지만 저는 틀리지 않았습니다 :rofl:

음, 네, 컴포넌트가 전혀 없는 기본 신규 테마에서 같은 테스트를 돌려보니 다음과 같은 결과가 나왔습니다:

(적어도 제가 이 테스트를 돌릴 때) 차단 시간(blocking time)이 항상 가장 큰 문제인 것 같습니다. 그래서 Discourse 개발팀이 이 부분을 더 잘 최적화해야 하는 건가요? 진심으로 묻는 겁니다, 깎아내리려는 의도는 아닙니다.

이것은 인간이 실제로 보는 것이 아닙니다. 다시 말하지만, Discourse는 웹 앱으로, 먼저 필요한 파일들을 이동한 뒤, 이후에는 거의 전부 JSON 텍스트로만 이루어집니다. 웹사이트가 서버 레벨에서 페이지를 생성하여 클라이언트에 가독 가능한 HTML을 전송하는 경우(예: WordPress가 하는 방식)에는 해당 테스트가 어찌 됐든 작동합니다.

그리고 그 시간은 전혀 나쁘지 않습니다.

지금 제안하시는 내용은 Discourse가 브라우저로 사용 불가능한 완전한 데스크톱 앱이 되어야 한다는 뜻입니다.