Discourse에서는 모든 js와 css 파일이 개별적으로 제공됩니다. 수년간 이러한 파일들을 결합하고 최적화하여 제공하는 것이 더 낫다고 생각했습니다. 제가 여기서 중요한 부분을 놓치고 있다면 알려주세요. 불행히도 초기 부팅 속도가 매우 느리며, 이러한 파일의 수를 줄이는 것이 도움이 될까요?
예를 들어, 30개의 css 파일 대신 1~2개의 css 파일만 사용한다면 처리 과정이 더 빨라질 수 있을까요?
주소창에 주소를 입력하고 엔터를 누르면 사이트가 1~2초 만에 열렸다고 상상해 보세요. 음, 그러면 정말 좋겠죠.
동의합니다. 매우 기능적이고, 열린 후에는 매우 빠르며 우리는 Discourse를 사랑하고 있습니다.. 조금 더 개선해서 최고 중의 최고로 만들어 봅시다 
논리적인 것 같습니다.
글쎄요, 저한테는 여기 현실이 2초예요. 그 실험실 테스트는 완전히 다른 세계죠.
그럼에도 불구하고 최소 5~6초의 대기 시간이 있습니다. 외부에서 테스트해 보면 대기 시간이 정말 길 수 있습니다.
느린 연결 속도?
최초의 기회에 이것을 테스트하겠습니다.
그 중 일부는 콜드 스타트를 수행해야 하고 모든 자산을 로드해야 하기 때문일 것입니다. 대부분의 경우 포럼 사용자는 브라우저에 해당 자산이 캐시되어 있을 것입니다.
로드 시간을 개선할 여지가 있다고 생각하며, 이 실험실 테스트에서 나온 팁 중 일부는 후속 조치가 가치가 있을 수 있습니다.
여기서는 증거가 필요합니다. 번들링은 HTTP 1.1 사이트에서 큰 이점을 가져오지만, 2.0 사이트에서는 그렇지 않습니다.
물론 모든 것이 더 빨라지기를 원하지만, JavaScript에서 병목 현상이 eval에 있다면 번들링을 조정하는 것은 올바른 접근 방식이 아닙니다.
이 문제는 HTTP 표준에만 국한되지 않는다고 생각합니다. 어떤 사이트는 2~3초 만에 열리는데, 디스코스의 10초 대기 화면은 좀 불편하네요. 터키에는 "모든 아름다움에는 결점이 있다"는 속담이 있습니다. 디스코스가 시간이 지나면서 이 결점을 수정해 주길 바랍니다.
다시 말하지만 — 이는 포럼 서버와 사용자의 연결 상태, 그리고 사용자의 기기에서 비롯됩니다.
팀이 미국의 모든 지역, 핀란드, 터키 간의 차이를 어떻게 해결할 수 있는지, 혹은 혼잡한 4G 네트워크에서 3M 속도를 더 빠르게 만드는 것이 가능한지, 또는 RAM이 부족하고 저장 공간이 재미있는 고양이 사진으로 가득 찬 저가형 중국산 스마트폰을 사용하는 사용자의 경우를 어떻게 처리할 수 있는지 저는 알지 못합니다.
물론입니다. Discourse가 ‘일반적인’ 웹사이트처럼 빌드된다면 첫 로딩이 더 빠를 수 있습니다. 하지만 그러면 모든 페이지 로딩이 그만큼 또는 더 느려질 것입니다.
솔직히 말씀드리면, Discourse가 당신에게 느리게 느껴지는 것은 안타까운 일입니다. 하지만 저의 경우, 핀란드에서 4G 신호를 받아 마케팅 속도 200M를 제공하는 가정용 Wi-Fi에 연결된 iPhone SE를 사용할 때 대기 시간은 약 2초입니다.
사실 오늘 제 머릿속에 이런 생각이 스쳐 지나갔습니다. 이 앱의 기능은 항상 빠릅니다. 이 기능을 모든 사용자에게 어떻게 소개하고 설치할지 알려드리겠습니다. 이렇게 하면 앱처럼 보이면서도 빠른 인상을 줄 수 있습니다. 저는 디스코스를 정말 좋아합니다. 당분간 떠날 생각이 없습니다. 최대한 활용하기 위해 모든 방법을 시도해 볼 것입니다.