게이밍 구글 — 완벽한 라이트하우스 스코어

저는 항상 제 코드를 공유하는 것을 망설였습니다.수준 이하라고 믿는 것도 아니고, 사기꾼 증후군에 시달리고 있는 것도 아니에요.코드를 공유하면 제 마음의 광기를 엿볼 수 있고, 다른 사람들한테는 왠지 잔인하게 느껴질 뿐입니다.저를 거의 제정신으로 이끌었던 여정을 안내해 드리겠습니다.이 모든 것은 구글의 라이트하우스 업데이트로 시작되었습니다.

SEO에 입문하지 않은 사용자에게 Google의 Lighthouse 업데이트는 웹 사이트의 실적과 모범 사례 준수에 영향을 미치면서 검색 순위에 상당한 변화를 가져왔습니다.웹사이트를 테스트하려면 데스크톱의 Chrome에서 열고 F12 키를 눌러 Chrome 개발자 도구를 연 다음 'Lighthouse' 탭을 클릭하면 됩니다.데스크톱 또는 모바일을 선택하고 “분석”을 클릭합니다.약 1분 후에 성능, 접근성, 모범 사례, SEO, 프로그레시브 웹 앱 (PWA) 에 대해 각각 0~100점 범위의 5점을 받게 됩니다.

기술적인 세부 사항을 살펴보기 전에 먼저 제 소개를 드리겠습니다.제 이름은 조나단 그랜덤이고 ERP 및 ITSM 소프트웨어를 전문으로 하는 소규모 B2B SaaS 회사인 넥소이드의 자랑스러운 소유주입니다.이 글에서 다루고 있는 웹사이트는 다음과 같습니다. www.nexoid.com. 부담 없이 살펴보시고 소스 코드를 열어보세요.LinkedIn에서 저를 팔로우할 수도 있습니다.제 프로필은 www.linkedin.com/in/jonathongrantham/

Google Chrome Lighthouse 업데이트가 출시되었을 때 저는 양심적인 비즈니스 소유자라면 누구나 할 수 있는 일을 했습니다. 바로 제 웹사이트를 확인하는 것이었죠.실망스럽게도 결과는 만족스럽지 못했습니다.퍼포먼스 점수 21/100, 접근성 점수 30/100, 베스트 프랙티스 점수 45/100, SEO 점수 11/100, PWA에서 실패 점수를 받았는데 정말 놀랐습니다.저는 개인적으로 React.js 를 사용하여 상당히 표준적인 단일 페이지 아키텍처인 웹 사이트를 구축했습니다.점수는 엄청난 타격이었습니다.

초기의 어려움에도 굴하지 않고 MS Code를 출시하고 성능을 첫 번째 목표로 삼아 하나씩 문제를 해결하기 시작했습니다.Lighthouse 도구에서 제공하는 가이드는 매우 유용했습니다.JPEG와 PNG의 모든 이미지를 최신 WebP 파일로 변환하고 레이아웃 변경을 방지하기 위해 모든 img 태그에 너비 및 길이 속성이 포함되도록 했습니다.이러한 수정만으로도 제 점수는 21/100에서 60/100으로 올랐습니다.상당한 개선이었지만 완벽하지는 않았습니다.남은 유일한 제안은 “사용하지 않는 JavaScript를 줄이는 것”이었는데, 이는 특별히 도움이 되지 않았습니다.존재했던 유일한 자바스크립트는 React.js 프레임워크였고, 다른 것들은 모두 제거되었습니다.

AM Digital은 Nexoid를 통해 통합 ITSM 솔루션의 이점을 고객 대면 운영에도 적용할 수 있었습니다.Azure와 통합된 클라이언트 포털은 고객에게 더욱 연결되고 동적이며 원활한 경험을 제공하여 고객 만족도와 참여도를 높였습니다.포털을 통해 고객 데이터와 실시간으로 동기화하여 모든 정보가 업데이트되고 정확한지 확인할 수 있었으며, 이를 통해 서비스 제공을 강화하고 고객-회사 관계를 강화할 수 있었습니다.

이 문제를 해결하기 위한 끈질긴 노력에도 불구하고 저는 끊임없는 장애물에 부딪혔습니다.React.js 일부를 제거하고 “지연 로딩”을 탐색하고 다양한 옵티마이저와 압축을 테스트했습니다.하지만 이 문제는 크기가 약 0.5메가바이트에 달하는 React.js 자체에서 비롯되었습니다.

노련한 웹 개발자들이 이렇게 외치는 소리가 거의 들릴 정도입니다. “웹사이트에 React를 사용하지 마세요!웹 애플리케이션을 구축하기 위한 거잖아!”저도 이제 이 사실을 잘 알고 있습니다.

몇 개의 이미지를 변환하는 것으로 간단해 보였던 것이 이제는 새로운 프레임워크를 사용하여 웹사이트를 완전히 개편하는 것으로 바뀌었습니다.좌절감을 느끼며 몇 마디 선택 단어를 내뱉으며 적절한 대체품을 찾아 나섰습니다.처음에는 Vue를 고려했고 나중에는 React.js 의 가장 큰 경쟁자라고 할 수 있는 Angular를 고려했습니다.그러나 둘 다 같은 문제를 제시했습니다.

작업을 단순화하기 위해 이전 기술을 살펴보기로 결심하고 jQuery를 사용해 보았습니다.하지만 저도 같은 문제에 봉착했습니다.Google의 신들을 달랠 수 있는 기성 단일 페이지 아키텍처 프레임워크가 없다는 것이 분명해졌습니다.

유일하게 남은 옵션은 바닐라 자바스크립트에 의존하는 것뿐인 것 같았습니다.

필자의 일련의 실험은 자바스크립트가 없는 기본 HTML 페이지에서 시작되었습니다.그런 다음 내용을 바꿀 수 있는 div가 있는 HTML 페이지를 사용해 보았습니다.JavaScript를 통해 페이지를 동시에 여러 번 변경하면 Lighthouse에서 페널티가 발생한다는 사실을 금방 깨달았습니다.해결책은 body 태그의 내용을 문자열로 조작한 다음 다시 통합하여 눈에 보이는 단일 DOM 변경만 만드는 것이었습니다.

이제 간단한 HTML 페이지에 빈 body 태그가 있고 head 태그에 작은 onload 함수가 추가되었습니다.이 함수는 URL을 검사하고 HTML GET 요청을 실행하여 페이지 본문 HTML이 포함된 해당 텍스트 파일을 검색했습니다.이것이 적절한 해결책이라고 생각할 것입니다.안타깝게도 JavaScript 기능을 동적으로 로드하려고 시도했을 때 실패했습니다.

다른 태그와 달리 본문 콘텐츠 문자열에 간단한 경고 (“yes this fired”) 가 있는 스크립트 태그를 추가하면 실행되지 않습니다.이상적이지는 않지만 한 가지 해결 방법은 본문 문자열을 구문 분석하고 모든 스크립트 태그 내용을 식별한 다음 JavaScript eval 함수에 배치하는 것이었습니다.이 접근 방식은 어느 정도 효과적이었으나 네임스페이스를 다룰 때 어려움을 겪었고 개발자 콘솔에는 보기 흉한 경고가 넘쳐났습니다.해결책은 HTML에서 스크립트 태그를 추출하여 DOM이 렌더링된 후 스크립트 요소로 추가하는 것이었습니다.Google은 어떤 이유로든 이 조치에 불이익을 주지 않았습니다.

진전이 있었고 기본적인 단일 페이지 아키텍처 솔루션이 생겼습니다.하지만 그렇게 빠르지는 않습니다.Google은 단일 페이지 아키텍처 페이지를 브라우저에서 열고 모든 JavaScript가 실행되도록 한 다음 DOM을 스캔하는 방식으로 인덱싱하는 데 효율적이지만 Bing, Yahoo 및 기타 주요 검색 엔진에서도 비슷하고 간단한 방법을 사용합니다.하지만 페이스북, 레딧, 링크드인, 왓츠앱과 같은 대부분의 다른 플랫폼은 HTML 파일만 가져와서 빈 본문이 있는 작은 HTML 파일을 가져옵니다.내 솔루션은 실행 가능하지 않았습니다.이제 웹사이트의 모든 페이지에 이 개념을 적용하고 사용자가 링크를 클릭할 때 단일 페이지 아키텍처 모드로 전환하도록 JavaScript를 포함해야 했습니다.

솔루션에 따라 각 페이지에 대해 HTML을 생성할 수 있는 도구가 필요했습니다.제가 사용할 수 있는 완벽한 리소스가 있다는 생각이 들었습니다. 바로 저만의 ERP 시스템인 Nexoid였습니다.웹 사이트와 웹 페이지 데이터 객체를 포함하는 Nexoid 모델을 만들었습니다.웹 사이트 기록을 통해 일반 템플릿 웹 페이지를 쉽게 만들 수 있었고 웹 페이지 레코드에는 각 개별 페이지의 내용이 포함되어 있습니다.퍼즐의 마지막 조각은 웹 사이트 레코드와 모든 관련 웹 페이지 레코드를 읽고 HTML 파일을 생성할 수 있는 워크플로우 함수 또는 스크립트였습니다.며칠 후 작동이 시작되었습니다.저는 기본적인 콘텐츠 관리 시스템 (CMS) 을 만들었습니다.이 시점까지 CMS를 개발하는 것은 그리 복잡하지 않습니다. 실제 문제는 다른 CMS 워크플로우, 승인, 현지화, 미리 보기 등을 통합할 때 발생합니다.

새 웹사이트의 주요 요구 사항은 현지화였습니다. 저희는 이 웹사이트를 11개 언어로 출시하는 것을 목표로 삼았습니다.IT 회사라서 자연스럽게 기술 솔루션에 관심을 갖게 되었습니다.페이지마다 번역가를 고용하는 대신 AWS Translate를 선택했습니다.AI 번역가는 괜찮은 편이긴 하지만 완벽하지는 않으며, 오류가 눈에 띄어 사람이 아닌 것을 알 수 있습니다.프랑스어를 구사하는 직원이 AI 번역을 평가한 후 “이해할 수 있지만 적절한 프랑스어는 아니다”라고 설명하며 6/10을 주었습니다.

그러나 우리는 귀중한 트릭을 발견했습니다.ChatGPT를 통해 먼저 영어 텍스트를 입력하고 '정리해 달라'고 요청한 다음 붙여넣으면 텍스트가 여전히 영어이지만 언어 모델과 훨씬 더 호환되는 방식으로 다시 작성된다는 것을 알게 되었습니다.ChatGPT로 개조된 영어를 번역 기반으로 사용하면 번역 품질이 크게 향상되어 10점 만점에 9점, 심지어 10점 만점에 완벽한 수준까지 올라갈 수 있습니다.

웹 사이트 제작을 위한 탄탄한 기술 기반을 마련한 후 저는 진전을 이루고 있었습니다.하지만 더 복잡한 페이지를 만들기 시작하면서 새로운 과제가 생겼습니다.새로운 라이트하우스 가이드라인에 따라 모든 자바스크립트, CSS, HTML을 단일 파일로 통합하는 것이 필요하게 되었습니다.이는 단일 페이지 아키텍처 버전에도 적용되었습니다.

우리는 모든 JavaScript 및 CSS 파일을 인라인 태그로 삽입했습니다.싱글 페이지 아키텍처 버전에도 비슷한 전략이 필요했습니다.모든 스크립트, 스타일 및 HTML을 포함하는 JSON 파일을 만들었습니다.

Lighthouse는 다음 문제를 에셋의 크기라고 파악했습니다. HTML과 JSON 페이지 파일이 너무 커졌기 때문입니다.HTML, CSS 및 자바스크립트 파일을 압축하도록 특별히 설계된 Node.js 라이브러리인 'minify'를 사용하여 이 문제를 해결했습니다.이 솔루션은 텍스트 파일 크기를 40% 이상 줄였습니다.또한 minify는 난독화라는 추가 이점을 제공하여 원시 코드를 더 읽기 어렵게 만들어 보안을 강화했습니다.

호스팅에 대해 자세히 살펴 보겠습니다.일반적으로 CMS (콘텐츠 관리 시스템) 는 사용자의 HTML 요청을 처리하는 애플리케이션 서버를 통해 작동합니다.URL의 페이지 요청을 해석하고, 데이터베이스에서 해당 자산을 찾고, 데이터베이스 레코드 (아마도 다른 레코드와 함께) 를 검색하고, 정보를 처리하여 페이지를 구성한 다음 최종 사용자에게 플랫 HTML 문서로 전달합니다.이 설명은 주로 사용자가 새 웹 사이트를 방문할 때의 초기 HTML 요청과 관련이 있지만 AJAX 및 기타 유사한 기술에 대해서는 알고 있습니다.

그러나 이러한 기존 모델은 새로운 Lighthouse 세계의 맥락에서 몇 가지 단점을 제시합니다.첫째, 애플리케이션 서버와 데이터베이스 서버 간의 양방향 통신과 페이지 컴파일 때문에 지연이 발생합니다.둘째, 가장 간단한 형태로 애플리케이션 서버와 데이터베이스 서버는 물리적으로 단일 위치에서만 사용할 수 있습니다.이 설정은 같은 건물이나 도시에 있는 경우에는 훌륭하지만 지구 반대편에서 사이트에 액세스하려는 경우에는 훨씬 덜 효율적입니다.예를 들어 호주와 영국 간의 평균 핑 대기 시간은 약 250밀리초입니다.

이러한 문제에 대한 우리의 솔루션은 앞서 언급한 게시 스크립트에서 생성된 정적 파일을 호스팅하는 데 AWS S3를 사용하고 글로벌 콘텐츠 배포에 AWS CloudFront를 활용하는 것입니다.이 글을 쓰는 시점에 AWS CloudFront는 47개국 90개 이상의 도시에 콘텐츠를 배포하고 있었습니다.호주 멜버른에서 영국 웹 사이트에 액세스하는 개인의 경우, AWS CloudFront는 핑 지연 시간을 250밀리초에서 단 13밀리초로 줄였습니다 (멜버른과 시드니의 AWS 엣지 서버 간의 시차).

이제 Lighthouse 테스트의 프로그레시브 웹 애플리케이션 (PWA) 구성 요소에 도달했습니다. 이전에는 그다지 고려하지 않았던 부분이었습니다.익숙하지 않은 분들을 위해 설명하자면, PWA에는 웹 애플리케이션으로 웹사이트를 관리하는 JavaScript 서비스 워커가 포함됩니다.좀 복잡하다면 이렇게 생각해 보세요. 기본적으로 자동 다운로드 및 캐싱 도구입니다.사용자가 웹사이트를 방문하면 후속 요청을 최대한 빠르고 원활하게 처리하는 것이 목표입니다.PWA 서비스 워커를 사용하면 다음 자산을 사용자의 로컬 컴퓨터에 이미 다운로드할 수 있으므로 다른 인터넷 GET 요청을 할 필요가 없습니다.

이 기사를 쓰는 시점에서 Nexoid 웹 사이트는 19 페이지에 불과한 비교적 작습니다.하지만 이 19페이지가 11개의 다른 언어로 번역되어 총 209페이지에 달합니다.처음에는 약 5MB에 달하는 모든 자산을 서비스 워커에 다운로드하려고 했습니다.이 크기는 처음 로드하기에는 너무 커서 Lighthouse에서 불이익을 받았습니다.각 페이지를 표시하는 데 필요한 모든 CSS, HTML 및 JavaScript가 포함된 영어 페이지 JSON 파일만 다운로드하기로 했습니다.

최종 구조는 다음과 같습니다. S3 버킷에는.html 확장자 없이 이름이 지정된 컴파일된 HTML 파일이 들어 있습니다.예를 들어, www.nexoid.com/en은 영어 홈페이지 HTML을 나타내고, www.nexoid.com/de는 독일 홈페이지 HTML을 나타내며, www.nexoid.com/en/platform은 영어 플랫폼 HTML을 나타내는 식입니다.또한 https://www.nexoid.com/en.json, https://www.nexoid.com/de.json, https://www.nexoid.com/en/platform.json 등과 같이 페이지 사이를 탐색할 때 변경되는 본문과 머리 부분이 포함된 JSON 파일도 있습니다.

결론적으로, Lighthouse를 이해하는 것은 상당한 도전이었습니다.기존의 기본 CMS 제품이 이 작업을 효과적으로 해결할 수 있을지 회의적입니다.워드프레스 (WordPress) 나 드루팔 (Drupal) 같은 플랫폼에 대한 제 경험을 돌이켜보면, Lighthouse 점수를 완벽하게 받을 수 있도록 최적화될 수 있다는 것이 믿기지 않습니다.전반적으로 이러한 노력은 그만한 가치가 있다고 생각하며 Google은 성능에 더 중점을 두는 것이 정당합니다.그러나 이러한 변화는 웹 디자이너와 에이전시에게 상당한 골칫거리이며 앞으로도 그럴 것입니다.

Lighthouse에 대해 더 자세히 알고 싶거나 Nexoid의 제품 및 서비스에 대해 논의하고 싶다면 언제든지 연락하십시오.LinkedIn을 통해 또는 당사 웹사이트의 '문의하기' 페이지를 통해 연락할 수 있습니다.