안녕하세요 렛플운영자입니다.

이번달은 전체 웹사이트의 속도 향상이 된 부분이 있어서, 이에 대한 인사이트를 공유해보고자 합니다.

구글 서치 콘솔에서는 빠른 URL을 명시해주고 있습니다.

그만큼 빠르게 로딩되는 웹사이트의 경우 검색에서 노출 순위가 올라가게 해준다는 것을 반증하는 것이죠.

즉 속도(퍼포먼스)를 향상시키면 노출 순위가 올라가게 되니, 속도에 항상 신경을 써야함을 의미합니다.

현재 렛플의 빠른 URL 비중은 99% 수준입니다.

데스크탑웹은 40%에서 99%을 찍었다가 73% 수준으로 내려갔습니다. (가지마.ㅠㅠ)

모바일웹은 2%에서 100%를 찍는 중입니다.

왜 이렇게 속도가 갑자기 한달만에 좋아졌을까? 어떤 업데이트를 했을까요?

데스크탑은 거의 2배이고 모바일은 거의 50배가 좋아졌는데, 이에 대하여 적어보도록 하겠습니다.

Core 프레임워크를 최신 버전으로 업데이트를 하자!

크게 주요한 버전 업데이트가 필요한 부분은 (프론트)리액트와 (백엔드)NEXT.JS/노드.JS가 있습니다.

평상시에 Core 프레임워크의 버전을 올리기에는 부담스러운 사항이기 때문에

이렇게 개선시간이 있을때 버전을 올려주는것이 좋습니다.

리액트, NEXT.JS, 노드가 의존성이 결려있기 때문에, 순차적인 업데이트는 불가능하고

특히 NEXT.JS의 신규버전등이 속도 개선에 있어서 중요한 역할을 하기 때문에,

위의 버전을 수시로 체크해서 시간될때 올려주는것이 좋은방향인것 같습니다.

물론, 기존에 했던것을 다시 작업해야하는 상황이 있긴 한데 그건 어쩔 수 없는 것 같습니다.

서버 용량이나 개수가 속도에 큰 영향을 줄까? 서버는 그렇다. DB는 글쎄?!

렛플은

서버(Web Application Server)가 이중화 구성입니다. 이것을 3중화 서버로 확장하고(서버를 하나더 연결)했구요,

DB 경우 RAM을 8배 증가시켜, 동시접속수를 기존의 8배로 증가시켰습니다.

서버의 경우, 개수늘 늘리면 비용은 많이 지불하더라도 속도는 확실히 올라가게 됩니다.

로드밸런서에서 사용자가 들어올때, 여러 서버에서 리소스를 받을 수 있기 때문에 , 트래픽 요청을 여러군데에서 분산하기 때문에

확실히 하나의 서버에서 응답하는 것보다 , 여러 서버에서 응답하는것이 빠르겠죠.

그러나 DB의 경우 사실 동시접속을 늘리더라도 항상 동시접속만큼 쓰는건 아니어서, 비용대비 효과는 적은 것 같습니다.

DB는 백업 DB를 제외하면, 사실상 하나의 서버가 모든 트랜잭션을 처리하는것이기 때문에,

하나하나의 트랜잭션을 효율화해주는것이 중요합니다.

대부분의 이미지 로딩은 lazy으로 저장장소는 외부에

<img src="image.jpg" alt="..." loading="lazy" />

이미지가 자체 서비스에서 관리가능한 수준이면 모르나,

많은 이미지들이 유저들이 올리시는 이미지일것입니다. 혹은 외부 사이트에서 불러오는 이미지일수 있습니다.

로딩이 어느정도 걸릴지 사실상 판단이 안되는 것이죠

이럴 경우에는 로딩은 좀 천천히 하는 옵션을 걸어주는 것이 좋습니다.

아예 첫번째 나오는 이미지가 아니라면, loading은 모두 "lazy"로 걸어주는 것이 속도를 높이는데 주요합니다.

또한 서버 자체에 이미지를 올리게 작업하시는 경우가 많은데, 이미지/파일 서버는 외부 서버로 별도로 분리하시는것이 좋습니다.

이미지 로딩하다가 서비스 서버가 부하가 걸리거나, 용량이 가득차면 무슨 일어날지 모르기 때문입니다.

S3가 너무 잘되어있어서 요즘엔 모두 S3에 넘기시긴 하지만,

초창기에 내부 폴더를 쓰시는 경우에는 느림의 주요 원인이 될 수 있습니다.

부분 로딩은 속도에 많은 영향을 준다.

렛플은 서버사이드 렌더링을 사용합니다. 클라이언트사이드 렌더링에 비해 속도는 빠를 수 있지만,

초기에 불러들여야하는 정보에 따라 느릴 수도 있습니다.

특히 서버사이드렌더링이라고 해서, 그냥 싹 다 불러오면 속도가 느림을 해결할 수 없습니다.

구글은 초기에 들어오는 로딩속도를 모두 기록하기 때문에, 싹 다 불러오게 되면 속도가 느리다고 체감할 수 밖에 없습니다.

초창기에 이렇게 사용자가 늘어날지 모르고, 한번에 전체를 모두 읽어오는 로딩으로 구성되어있었습니다.

점차 사용자가 늘고, 로그가 쌓이다보니 속도가 느려지는것이 체감되고 있었는데요.

한번 신규 프로젝트 공지를 하고나서, 접속이 안되는것을 보고 이대로 안되겠다 싶어서 효율화 작업을 했습니다.

1) 가장 상단의 컨텐츠를 먼저, 그 다음에 하단 컨텐츠

기존에 한번에 불러왔던 것을 , 4~5번에 걸쳐서 불러옵니다.

처음에 불러오는 것은 상단 컨텐츠 , 그리고 그다음이 하단 컨텐츠입니다.

어차피 유저분들이 접속하자마자 상단에서 하단으로 바로 내리는 경우는 상당히 드뭅니다.

2) 추가로 불러올 애들은 스크롤을 감지해서 불러오자?!

특히 20개가 넘어가는 애들의 경우 , 이전에는 페이징을 많이 적용하고 있었는데,

지금은 페이징으로 처리하는 웹은 별로 없죠.

유저가 더 내리냐를 가지고 스크롤 기준으로 판단해서 새로 불러오는 작업을 해야합니다.

아니면 유저가 별도의 클릭을 하게끔 만들어서 더 불러오게 하는 방법도 나쁘지 않습니다.

합계나 계산 등은 따로 불러오거나, 배치로 돌린다.

1) 합산은 배치로 계산한다.

저희는 유저마다 레벨을 가지고 있는데, 이를 표시하는 부분이 시간이 되게 오래걸립니다.

지금까지 적립된 렛플력을 모두 합산해서 , 그걸 레벨 테이블로 맞추고 하는 작업이 상당히 오래걸립니다.

한명이 아니라, 30명이 되더라도, 부하가 심각해지더군요.

이런것들이 처음에 렛플인에 들어오면, 이미지 로딩이랑 같이 렌더링을 느리게 하는 주범인데요.

현재는 렛플인에 보이는 레벨의 경우, 자정에 한번 업데이트를 하고, 그것을 기준으로 보여줍니다.

정말 무조건 합산이 필요한 영역은 여러명을 다중으로 불러오는게 아니라, 한명만 불러오게 설계되어있습니다.

2) 합산을 하려면 LIMIT을 설정한다.

꼭 모든 것을 합산해야지 정확하게 표현할 수 있는것은 아닙니다.

예를 들면 랭킹같은것은 상대적이기 때문에, 적은 숫자내에서 합산을 해도 정확한 판별이 가능합니다.

전체 뷰를 불러오는것이 아니라 상대적인 500~1000개 정도의 뷰내에서만 점유율만 보더라도, 랭킹 등은 합산이 가능하기 때문에

각각 어떤 상태에서 합산을 해야하는지 정의를 해보는것이 좋습니다.

3) 그게 아니라면, 합산은 따로 불러온다.

프로젝트 뷰 수의 경우, 로그의 뷰를 모두 합치는 방향으로 작업하고 있습니다.

그러나 만약에 프로젝트 상세페이지를 불러올 때, 로그를 같이 불러오면 전체 속도가 느려지게 됩니다.

그래서 현재 프로젝트를 불러오면, 내용은 빨리 불러오고, 그다음에 합산을 별도로 불러옵니다.

퀘스트와 같은 영역도 동일하게 구성되어있습니다.

스니펫의 오류에 민감하게 반응하자.

렛플은 다음과 같은 구조화 스니펫을 사용하고 있습니다.

- Article

- 탐색경로

- 고용주 누계 평점

- 이벤트

- FAQ

- 로고

- Product

- Review

- 사이트링크 검색창

- 소프트웨어 앱

이렇게 많이 사용하고 있고, 한번 개발해놓고 안 고치고 있었는데, 문법이 안맞는지 자꾸만 오류가 발생한다고 뜹니다.

이런 오류는 구글에서 해당 페이지가 제대로 개발이 되어있지 않다고 판단하는 주범입니다.

이 오류를 7월부터 고치고, 다시 패치를 했을때 , 위의 전반적인 개선과 함께 속도가 높다고 평가가 되고 있습니다

이제 빠른 URL이 100%잖아요, 검색결과에서 얼마나 노출이 증대 되는지 추후에 다시 써보겠습니다.