일이 지났습니다. 시의성에 유의하세요
서문
GitHub Pages에 정적 블로그를 만들기로 결정했을 때, 가능한 한 빠른 열기 속도를 원했기 때문에 몇 가지 요령을 사용하여 열기 속도를 높이고 사용자 경험을 개선했습니다.
최적화
바이두 CDN 서비스와 치니우 정적 리소스 호스팅 사용
이 블로그는 Bootstrap/jQuery/fontawsome 이 세 가지 라이브러리/폰트 파일을 사용합니다. Bootstrap 실제 상황에 맞게 내용을 약간 수정하여 타이포그래피와 더 잘 맞추기 위해 서드파티 CDN를 사용하지 않고 치니우의 리소스 서버에 배치했습니다. jQuery는 바이두의 정적 공공 리소스 서비스를 사용합니다.
여기서 광고를 하자면, 개인 사용자의 경우 치니우는 알리페이 실명 인증 후 10GB의 무료 저장 공간을 제공합니다. 실제 효과를 보면 속도는 괜찮습니다. 저는 도메인 img.xheldon.com CNAME을 치니우의 리소스 서버로 연결하여 위에서 언급한 맞춤형 Bootstrap 및 이미지와 같은 정적 리소스를 제공합니다. 따라서 사용 시 파일을 업로드하고 경로를 작성한 후 img.xheldon.com/path/filename.ext을 사용하면 됩니다:
2019년 9월 3일 업데이트: 제 도메인을 국내에서 차단될까 봐 국내에 등록하지 않고 Godaddy에 두었는데, 등록되지 않은 도메인은 치니우가 해석할 수 없어 이미지와 글을 함께 배치해야 했습니다. 이 때문에 글을 쓸 때 가능한 한 이미지를 사용하지 않으려 합니다 -_-
솔직히 정적 블로그이기 때문에 요청에 따른 Cookie이 크지 않아 리소스를 다른 서브도메인에 배치하는 최적화 효과는 크지 않지만, 없는 것보다는 나은 정도입니다.
작은 리소스를 직접 페이지에 배치
작은 css와 js을 직접 페이지에 배치했습니다. 예를 들어 highlight.css와 search.js는 style과 script 태그를 통해 직접 페이지에 작성되었습니다. 이렇게 하는 장점은 매우 큽니다. 이 두 파일은 작아 다운로드 시간을 무시할 수 있기 때문입니다. 외부에서 가져오는 경우 이 두 파일을 로드하는 시간은 주로 TTFB (FQ 필요)에 소비됩니다:

설정
젊은 시절 세상을 잘 몰랐기 때문에 이 사이트의 A 기록 www을 Github Pages의 IP 192.30.252.154/192.30.252.153로 직접 지정했습니다. 그리고 최상위 도메인 @을 잘못 사용하여 CNAME를 xheldon.github.io.로 지정했습니다. 사실 MX을 @로 지정하지 않았다면 이렇게 하는 것이 OK입니다. 하지만 이력서를 작성할 때 좀 더 멋지게 보이기 위해 자신의 블로그 도메인을 이메일로 사용하고 싶었고, QQ 이메일에서 제공하는 도메인 이메일 서비스를 사용했습니다. 따라서 MX 해석을 할 때 최상위 도메인 @을 텐센트의 mxdomain.qq.com로 지정해야 했는데, 이때 오류가 발생했습니다. 알리클라우드는 CNAME과 MX가 모두 최상위 도메인 @로 지정될 수 없다고 알렸습니다. 자세한 이유는 여기에서 확인할 수 있습니다. 하지만 지금은 블로그가 이전된 지 몇 달이 지났고 일부 링크는 이미 검색 엔진에 의해 크롤링되었습니다. 이제 링크를 수정하면 손실이 클 수 있습니다.
제가 처음 구성한 설정은 다음과 같습니다:
| 레코드 유형 | 호스트 레코드 | 레코드 값 |
|---|---|---|
| CNAME | @ | xheldon.github.io. |
| A | www | 192.30.252.154 |
| A | www | 192.30.252.153 |
텐센트 도메인 이메일을 사용하기 위해 MX 레코드를 @로 설정해야 했고, MX의 @는 CNAME의 @과 공존할 수 없습니다. 그래서 저는 숨김 URL 전달을 생각해 냈습니다. CNAME을 @로 지정하는 것을 취소하고 MX 레코드를 @로 추가한 후 숨김 URL을 추가했습니다:
| 레코드 유형 | 호스트 레코드 | 레코드 값 |
|---|---|---|
| A | www | 192.30.252.154 |
| A | www | 192.30.252.153 |
| MX | @ | mxdomain.qq.com. |
| CNAME | qqmailhash | mail.qq.com. |
| 숨김 URL | @ | http://www.xheldon.com |
동시에 블로그 분기 디렉토리의 CNAME 파일을 xheldon.com에서 www.xheldon.com로 변경한 후, 검색엔진을 통해 블로그에 접속할 때, 예를 들어 xheldon.com/about/의 경우, 실제로는 이 블로그로 리디렉션되지만 홈페이지만 표시된다는 것을 발견했습니다! 즉, 이전에 검색엔진에 의해 크롤링된 모든 링크는 홈페이지 www.xheldon.com에만 머무르게 됩니다. 이는 숨겨진 전달(forwarding)의 역할이 특정 주소에 대한 리디렉션에 불과하며, 주소 뒤의 경로를 자동으로 추가하지 않는다는 것을 의미합니다. 예를 들어, 제 경우에는 URL 숨김 전달을 설정하여 xheldon.com에서 www.xheldon.com로 전달하도록 했을 때, 모든 xheldon.com/xxxx에 대한 요청도 www.xheldon.com로 전달되었으며, 기대했던 www.xheldon.com/xxxx이 아닙니다.
이때 dig xheldon.com:
1 | |
최상위 도메인이 알리바바 클라우드의 IP을 가리키고 있음을 발견했습니다.
그래서 생각해 본 후, A 레코드의 @를 수정하여 직접 GitHub Pages의 IP 주소를 가리키도록 했습니다. 블로그 루트 디렉토리의 CNAME 파일 내용은 수정된 www.xheldon.com입니다:
| 레코드 유형 | 호스트 레코드 | 레코드 값 |
|---|---|---|
| A | @ | 192.30.252.154 |
| A | @ | 192.30.252.153 |
| MX | @ | mxdomain.qq.com |
| CNAME | qqmailhash | mail.qq.com. |
| CNAME | www | github.xheldon.com. |
이렇게 할 수 있는 이유는 Github Pages 자동 매칭 때문입니다. 구체적으로 설명하면 다음과 같습니다:
CNAME파일 내용이www.xheldon.com이고,xheldon.com에서 요청이 오는 경우(최상위 도메인@의A레코드를GitHub Pages의IP로 설정해야 함),www.xheldon.com로 전달됩니다.CNAME파일 내용이xheldon.com이고,www.xheldon.com에서 요청이 오는 경우(www의 서브도메인A레코드를GitHub Pages의IP로 설정해야 함),xheldon.com로 전달됩니다.
이때 dig www.xheldon.com에서 확인한 내용:
1 | |
dig xheldon.com에서 확인한 내용:
1 | |
저는 인생의 중요한 선택의 기로에 섰을 때, 누군가 최선의 방법을 알려주어 소중한 시간을 헛되이 보내지 않기를 바라곤 합니다. 그런 마음으로 저는 자주 블로그를 쓰며, 광활한 인터넷의 이 작은 구석에 제게는 단 한 번뿐인 인생 경험을 기록하여 도움이 필요한 분들에게 도움이 되기를 바랍니다.