웹드루아 - 웹 개발자 드루아

성능 최적화가 필요한 이유

프론트엔드를 위한 다양한 기술들이 나왔고, 이제는 성능 최적화에 초점을 맞추고 있습니다. 여기서 구글은 ‘성능이 저하되면 사용자가 떠나고 매출이 감소한다.’라고 이야기합니다. 즉 성능 최적화를 통해 사용자를 늘리고 매출 또한 증가한다는 것입니다. 구글이 조사한 페이지 로딩 속도와 이탈률 및 전환율의 관계를 살펴보면 확 이해될 것입니다.

• 페이지 표시 시간 2초 증가 → 사용자 이탈률 32% 증가
• 페이지 표시 시간 4초 증가 → 사용자 이탈률 90% 증가
• 페이지 표시 시간 5초 증가 → 사용자 이탈률 106% 증가
• 페이지 표시 시간 9초 증가 → 사용자 이탈률 123% 증가

더해서 다른 회사들의 사례도 본다면 성능 최적화가 얼마나 중요한지 이해할 수 있습니다.

• 핀터레스트 로딩 시간 40% 단축 → 검색 유입률과 가입자 수 15% 증가
• COOK 페이지 로드 시간 850밀리초 감소 → 세션당 페이지 조회 수 10% 증가/ 이탈률 7% 감소

이러한 성능 최적화는 어떻게 이루어질까?

성능을 결정하는 요소는 크게 두 가지입니다.

• 로딩 성능

서버에 있는 웹 체이지와 웹 페이지에 필요한 기타 리소스를 다운로드 할 떄의 성능

개선하는 방법 :

1. 다룬로드해야하는 리소스 수를 줄이거나 크기를 줄이기
2. 코드를 분할하여 다운로드 하기
3. 리소스의 우선순위를 매겨 중요한 리소스를 먼저 다운 받기

• 렌더링 성능

다운로드한 리소스를 가지고 화면을 그릴 때의 성능이며, 자바스크립트 코드에 크게 영향을 받음

개선하는 방법 :

매우 다양하며 서비스 유형에 따라서도 다릅니다. 그렇기에 자신의 서비스에 필요한 최적화 기법을 적용하기 위해선 브라우저의 동작 원리와 사용하는 프레임워크의 라이프 사이클 등 웹 개발의 기본 지식을 이해함으로써 효율적인 코드를 작성해야합니다.

정말 많은 최적화 기법들이 존재하지만 지금은 우리가 제작하고 있는 옷늘날씨 서비스에 적절한 최적화 기법 위주로 정리하겠습니다.

그 전에 성능을 분석할 수 있도록 도움을 주는 개발자 도구에 대해 알아봅시다.

성능 분석을 위해 사용되는 개발자 도구를 알아보자

• Network 패널

현재 웹 페이지에서 발생하는 모든 네트워크릐 트래픽을 상세하게 알려주는 도구입니다. 이를 통해서 어떤 리소스가 어느 시점에 로드 되는지, 해당 리소스의 크기 등을 확인할 수 있습니다.

• Performance 패널

웹 페이지가 로드될 때 실행되는 모든 작업을 보여 줍니다. Network 패널에서 봤던 리소스가 로드되는 타이밍뿐만 아니라 브라우저의 메인 스레드에서 실행되는 JS를 차트 형태로 볼 수 있습니다. 결론적으로 어떤 JS 코드가 느린지 확인할 수 있습니다.

• LightHouse 패널

웹사이트의 SEO 점수, 접근성 점수, 성능 점수 등을 측정해주고 개선 방향까지 제시해주는 자동화 도구입니다. 성능 관점에서 해당 도구를 사용하기 위해선 알아야하는 지표들이 있습니다.

총 6가지이며 각 지표에 가중치를 적용하여 총점을 알려줍니다.

• 6가지 지표
  • FCP(First Contentful Paint) | 10%
  페이지가 로드될 때 브라우저가 DOM 콘텐츠의 첫 번째 부분을 렌더링 하는 데 걸리는 시간 지표입니다.
  • SI(Speed Index) | 10%
  페이지 로드 중에 콘텐츠가 시각적으로 표시되는 속도 지표입니다. 최대한 빠르게 콘텐츠를 표시하면 높은 점수를 받을 수 있습니다. 즉, 페이지 로딩에 같은 시간이 걸리더라도 콘텐츠를 더 먼저 띄운 페이지의 SI 점수가 더 높습니다.
  • LCP(Largest Contentful Paint) | 25%
  페이지가 로드될 때, 화면 내 가장 큰 이미지나 텍스트 요소가 렌더링 되기까지 걸리는 시간 지표입니다. 즉, 가장 큰 콘텐츠가 나타나는데 걸리는 시간을 기준으로 볼 수 있습니다.
  • TTI(Time to Interactive) | 10%
  페이지과 상호 작용이 가능한 시점까지 걸리는 시간 측정 지표
  • TBT(Total Blocking Time) | 30%
  페이지가 클릭, 키보드 입력 등의 사용자 입력에 응답하지 않도록 차단된 시간 총합 지표 동작 방해 작업을 포함한 FCP → TTI 사이의 시간 동안 측정
  • CLS(Cumulative Layout Shift) | 15%
  페이지 로드 과정에서 발생하는 예기치 못한 레이아웃 이동 측정 지표
  ※ 레이아웃 이동 : 화면상에서 요소의 위치나 크기가 순간적으로 변하는 것

• Opportunities 섹션과 Diagnostics 섹션 : 문제점과 해결 방안, 얻을 수 있는 이점 설명
  • Opportunities 섹션 : 페이지를 더욱 빨리 로드할 수 있는데 도움이 되는 제안
  • Diagnostics 섹션 : 로드 속도와는 관계 없지만 성능 향상에 도움이 되는 제안

그리고 라이트하우스를 이용해 성능을 측정할 때는 기본 네트워크 환경이 아니라 네트워크 속도를 제한하여 어느 정도 고정된 네트워크 환경에서 성능을 측정합니다.

데스크탑은 1x 모바일은 4x로 모바일로 검사할 때 네트워크를 더욱 제한합니다.

이번에 독서 스터디를 하게 됐는데,"소프트웨어장인"이라는 책을 읽게 되었습니다. 해당 책을 읽으며 중요하다고 생각한 부분과 저의 생각을 정리해 보겠습니당 :) 나머지 부분도 읽은 후 차근차근 정리해 블로깅 할 예정입니다!

1장: 21세기의 소프트웨어 개발

중요하다고 생각한 내용과 나의 생각

31p

매일 코드를 작성하는 일은 행복이었다. 그떄 이후로 아침에 눈을 뜰 때마다 오늘 할 일이 하고 싶어 기대되는 일만 하기로 스스로와 약속했다.

→ 자신이 하고 싶어 하는 일을 하는 것은 정말 중요하다고 생각합니다.

→ 여기서 생각난 질문이 있는데 여러분은 ‘자신이 잘하는데 재미가 없는 일’과 ‘자신이 잘하는 것 같지는 않지만 재밌는 일’이 있다면 어떤 것을 선택하실 건가요??

32p

이제 개발자들은 개발뿐만 아니라 다음과 같은 여러가지를 할 수 있어야한다.

• 고객과 대화하기
• 테스트/배포 자동화하기
• 전체 비즈니스에 영향을 미칠 기술 선정하기
• 지리적으로 분산된 팀들과 협업하기
• 고객을 도와 필요한 작업을 정의하기
• 우선순위 선정하기
• 진척 상황 보고하기
• 변경사항과 기대일정 관리하기
• 잠재 고객 및 파트너에세 제품 소개하기
• 사전 영업 활동 지원하기
• 개발 일정과 비용 산출하기
• 채용 면접하기
• 아키텍처 설계하기
• 비기능적 요구사항과 계약 조건 검토하기
• 사업 목쵸 이해하기
• 주어진 여건에서 최적의 결정하기
• 새로운 기술 주시하기
• 더 나은 업무 방식 찾기
• 고객에게 가치 있는 상품이 전달되고 있는지 고민하기

소프트웨어 개발자가 소프트웨어 개발 업무만 하면 되던 시정른 지나갔다.

→ 다양한 역량을 갖춘 개발자가 되어야 계속 발전하는 산업 속에서 살아남을 수 있을거라고 생각합니다.

2장: 애자일

중요하다고 생각한 내용과 나의 생각

38p

애자일은 절자적인 부분과 기술적인 부분 두 종류로 나눌 수 있다.

절차적인 관점에서의 애자일

팀과 조직이 어떻게 구성되고 협업해야 하는지에 대한 것들 규정

• 회의 방식
• 구성원 각각의 역할
• 요구사랑 파악 방법
• 작업 진척 속도 파악 방법
• 점진적/반복적으로 일할 때 취하는 방식
• 진행 상황을 개발팀 밖의 관계자에게 전달하는 방식
• 비즈니스 피드백 방식

⇒ 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중

결론적으로 팀이 올바른 목표를 향해 진행 중인지 확인

기술적인 관점에서의 애자일

개발, 확장, 유지보수, 제품을 출시하면서 겪는 어려움들에 대해 특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드

ex) TDD, 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등

결론적으로 목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게 함

애자일의 의미

• 민첩하다고 해서 애자일을 실행하고 있는 것은 아니다.
• 빠르고 짧은 피드백 루프에 대한 것
  • 더 빨리, 더 짧게 피드백 루프를 만들수록 애자일해진다.
• 애자일은 문제 자체를 해결해주지 않는다 문제를 드러나게 한다.
• 특정 기능의 상용화 가능성을 일찍 알게 된다면 투자에 대한 위험도 줄일 수 있다.

→ 애자일 방식을 채택한 이유에 대해 정확하게 이해하며 이번에 진행하는 밋업 프로젝트에 어떻게 적용하면 좋을지 생각할 수 있게 도움을 주는 내용이었습니다. 문제를 빠르게 찾아내는 것이 목표에 빠르게 다가가는 것에 큰 도움이 될것이라고 생각합니다.

40p

그저 계획에 맞춰서 지시 받은 일만 하는 것이 아니아, 비즈니스와 고객 가치 창출에 개발자들이 직접 함여하는 것도 매우 중요하다고 주장한다.

→ 비즈니스 임팩트를 지닌 코드를 작성하는 것이 정말 중요하다고 생각합니다.

41p

기업들은 단순히 특정 분야만이 아닌 다방면에 걸친 저문가를 찾고 있다. 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다.

42p

애자일의 12가지 법칙

1. 가치 있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다.
2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다.
3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다.
4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다.
5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 자원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다.
6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 바업은 얼굴을 마주보고 대화하는 것이다.
7. 프로젝트 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다.
8. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다.
9. 기술적인 탁월함과 좋은 설게에 대한 지속적인 관심은 기민함을 높인다.
10. 단순함, 즉 하지 않아도 되는 일은 최대한 하지 않아야 한다.
11. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다.
12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방삭을 조율하고 바로잡는다.

44p - 안타깝게도 ‘애자일’이 과거에 일하던 방식의 그저 새로운 이름이 된 듯 싶다.

45p - 이러한 변화에도 불구하고 좋은 소프트웨어를 빠르게 공급하지 못하고 있는 것이 현실이다.

→ 이번에 진행하는 프로젝트에서 TDD 방식을 도입해 애자일 방식으로 개발 및 프로젝트를 진행할 예정인데, 위와 같이 기본 방식의 그러 새로운 이름이 되지 않게 노력해야 겠다는 생각이 들었습니다.

48p

애자일의 모든 절차들에는 기술적 탁월함이 전제되어 있다.

도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다.

→ 기술적 탁월함을 갖추기 위해 노력해야겠다는 생각이 들었습니다.

53p

절차와 결과물 둘 다 중요하다는 점을 강조하기 위함이다.

54p

소프트웨어 장인정신은 여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다. → 일을 올바르게 수행하도록 돕는다.

→ 앞으로 이 책을 읽으면서 소프트웨어 장인정신을 품기위해 꾸준히 노력해야 겠다고 생각했습니다.