프론트엔드 코드 최적화

2023년 8월, 원티드 프리온보딩 프론트엔드 챌린지 요약

 

복습

Lighthouse

Production Build에서 확인이 가능하며, Production Build 시 나름 최적화가 진행되어 Web Vital이 상당 부분 개선된다.

• Minification
• Tree Shaking

 

Performance

Runtime 성능 측정

1. 렌더링 성능
2. 자바스크립트 성능
3. 메모리 관리
4. 반응성 (First Input Delay)
5. 네트워크 성능

주요 정보

1. Loading
2. Scripting
3. Rendering
4. Painting

 

Profiler

• Provider부터 렌더링을 하는가?
• 변화가 감지된 페이지만 렌더링하는가?

 

최적화, Code Splitting

1. Bundle Size 줄이는 방법
   • 전체 용량이 줄어드는 것이 아닌 하나의 번들을 여러 개로 잘게 쪼개는 방법이다.
   • React Lazy + Suspense의 조합을 사용한다.
2. 최초 로딩 시간이 단축되는 이점이 있다.
   • FCP, LCP, FID 개선이 가능하다.
3. 브라우저 Cache

 

Lazy Loading

• Lighthouse가 100점이라고 해도 최적화가 완료된 것이 아니다.
• Intersection Observer로 최적화를 고려할 필요가 있다.

 

Cache 활용법

• 운영체제 안 캐시가 들어있는데, 자주 사용하는 데이터를 저장한다.
  • 계속 불러오지 않고 이미 불러진 기록이 있으면 거기서 꺼내와 성능 향상에 도움을 준다.
  • 예. 가방
• 두 가지 종류
  • Memory Cache
  • Disk Cache
    • 느린 속도
  • 브라우저가 알아서 선택
    • 사용빈도
    • 파일 크기
    • 크기나 너무 크면 메모리에 저장할 수 없고, 디스크에 저장
• Cache-Controll을 설정해야 사용이 가능하다.

 

Font 최적화

CSS 파일에서 url로 바로 불러오면 자바스크립트에서 할 수 있는 것이 없기 때문에 캐시를 할 수 없다.

캐시를 잘 해두면 최적화를 할 수 있다.

 

WOFF2를 사용하는 것이 좋다. 왜냐하면, 용량이 작기 때문이다.

아래의 사이트에서 폰트 포맷을 변경할 수 있다.

Online @font-face generator

 

Fontsource를 활용하여 폰트 최적화를 할 수도 있다.

 

GitHub - fontsource/fontsource: Self-host Open Source fonts in neatly bundled NPM packages.

 

직접 파일을 가져와서 사용하는 것보다는 웹 폰트를 가져와서 사용하는 것이 최적화에 효율적이다.

 

CSS 최적화

사용하고 있지 않은 CSS 파일의 사용을 줄이는 것이 최적화에 도움이 된다.

FontSource 사이트를 이용하는 것도 하나의 방법이다.

 

PurgeCSS 사이트를 이용해서 CSS 정리를 할 수 있다.

PurgeCSS - Remove unused CSS | PurgeCSS

 

특히, CLI 버전을 사용하는 것이 낫다. Production 부분의 CSS를 정리하는 데 좋기 때문이다.

CLI | PurgeCSS

 

최적화는 아닌 패키지 세팅, Lock Files

• "Package.json" vs "Package-lock.json" or "yarn.lock"

Dependency를 정확하게 관리해야 많은 개발자들이 같은 환경에서 개발할 수 있다.

여기서, 주의해야 할 것은 패키지는 하나만 사용해야 한다는 것이다.

 

최적화는 아니지만, TypeScript

타입스크립트를 사용할 때, 인터페이스 또는 타입을 선언해야 할 경우가 많다.

이 때, 알고있으면 좋은 정보들이 있다.

 

interface Props {
	filter: {
    	age: string;
        mbti: string;
        gender: string;
    }
};

onChangeFilter: (e: React.ChangeEvent<HTMLSelectElement>) => void;
onDeleteFilter: (name: string) => void;

위 코드는 에러 표시 없이 정상적으로 작동하는 코드이다.

그러나, "filter"의 "key"만 "onChangeFilter"와 "onDeleteFilter"에서 사용되는 것이 더 안정적이다.

 

interface IFilter {
	name: string;
    age: string;
    gender: string;
}

interface IUser {
	name: string;
    age: string;
    gender: string;
    Number: string
}

만약, 위 처럼 인터페이스를 구현했다고 생각해보자.

중복이 보이지 않는가? 이를 코드를 줄이면서 개선시킬 수 있다.

 

interface IFilter {
	name: string;
    age: string;
    gender: string;
}

interface IUser extend IFilter {
    Number: string
}

위 처럼 수정하면, 이전과 같이 사용할 수 있으면서 코드의 수는 줄일 수 있다.

타입도 마찬가지이다. 그러나, 타입은 단점이 있기 때문에 잘 생각해서 사용해야 한다.

 

type IFilter = {
	name: string;
    age: string;
    gender: string;
}

type IUser = Pick<IFilter, "name" | "age">

위 코드는 "IFilter"의 name과 age만 선택해서 사용하겠다는 의미이다.

"Pick" 대신 "Omit"을 사용할 수 있다.

 

Optional prop은 Default prop을 넣어주자

type ButtonProps = {
	children: JSX.Element;
    onClick?: (e: React.MouseEvent<HTMLButtonElement>) => void;
    info?: string;
    className?: string;
    infoPlace?: "top" | "bottom" | "left" | "right";
};

const CircleButton = ({
	children,
    onClick,
    info,
    className,
    infoPlace,
}: ButtonProps) => {
	...
}

참조: eslint-plugin-react/docs/rules/require-default-props.md at master · jsx-eslint/eslint-plugin-react (github.com)

 

Type, Interface는 언제 사용할까?

"extends" 등의 기능이 필요할 때를 제외하고, 일반적으로 타입(Type)을 사용한다.

 

인터페이스는 Unions, Mapped Types, Conditional Types 등을 표현할 수 없다. 반대로 타입은 모든 타입을 표현할 수 있다.

인터페이스는 ","를 사용할 수 있지만, 타입은 그러하지 못하다.

Interface Person, Animal {
	...
}

 

객체들이 상속 관계에 있는 경우에 인터페이스를 사용해야 한다. 인터페이스를 사용하면 TypeScript의 타입 체커가 더 빨리 동작한다.

 

동일한 이름의 인터페이스가 같은 범위에서 선언된다면, 이는 병합되어 예상하지 못한 버그를 발생시킬 수 있다.

타입은 암묵적으로 인덱스 시그니처(Index Signature)가 있으며, 때로는 Record<PropertyKey, unknown>이 필요하다.

 

인터페이스

다른 객체에서 확장되는 객체를 정의하는 데 사용되는 일급 원시 요소를 제공한다. 상속을 사용하여 타입을 생성하는 데 사용된다.

interface WithId {
  id: string;
}
 
interface User extends WithId {
  name: string;
}
 
const user: User = {
  id: "123",
  name: "Karl",
  wrongProperty: 123,

"Type '{ id: string; name: string; wrongProperty: number; }' is not assignable to type 'User'"

위의 코드에서는 에러가 난다. 왜? 당연히 "wrongProperty"가 "User" 인터페이스에 선언되어 있지 않기 때문이다.

 

객체 간 상속 관계가 필요할 때는 "인터페이스"를 사용하면 좋다.

","을 사용한 것은 타입을 사용하여 교차 타입을 만들어 표현할 수도 있다.

 

객체 간의 상속 관계를 다룰 때는 인터페이스를 사용하세요. 위의 예시에서 ,를 사용하여 표현한 것은 타입 별칭을 사용하여 교차 타입(intersection type)을 만들어 표현할 수 있습니다.

 

타입

그러나, 이는 내장된 대안을 함께 제공한다. 바로 키워드를 사용하여 선언된 "타입"이다. 이는 객체 타입뿐만 아니라 타입스크립트에서 모든 종류의 타입을 표현하는 데 사용될 수 있다.

예를 들면, 문자열 또는 숫자 중 하나를 나타내는 타입을 표현하려고 할 때, 인터페이스보다 타입을 사용하여 가능하게 할 수 있다.

 

type StringOrNumber = string | number;
 
const func = (arg: StringOrNumber) => {};
 
func("hello");
func(123);
 
func(true);

위 코드처럼 타입을 선언할 수 있다. 여기서 맨 아래의 "func(true)"는 에러가 발생한다. 왜냐하면, "string", "number"만 선언되어 있고, "boolean"은 선언되지 않았기 때문이다.

 

물론, 타입은 객체를 나타내는 데 사용될 수 있다. 그렇다면, 객체 타입을 선언할 때 인터페이스를 사용해야 할까? 타입을 사용해야 할까?

 

더 자세한 비교는 아래의 참조글을 확인해보자.

Type vs Interface: Which Should You Use In 2023?

 

 

아하모먼트

• 회사 규모에 따라 회사를 지원하는 이유가 달라야 한다.
• 스타트업일 경우, 대표가 이 일을 왜 하고 싶은지, 사명감을 가지고 있는지 확인할 필요가 있다.
  • 뉴스, 구글 검색 등으로 자료를 조사해보자.

19년 차 개발자가 고찰한 주니어 개발자가 성장하기 좋은 회사 환경

 

• 중견기업과 대기업은 개발팀을 봐야 한다.
  • 개발 팀장이 팀을 무슨 생각으로 이끌고 있고, 팀원을 생각하며 개발하고 있는지 인터뷰를 통해 검증할 필요가 있다.

 

• 만약, 개발팀이 없고 혼자서 개발해야 한다면, 웬만하면 안 가는 것이 좋다.
  • 한 명 이상이라도 개발 팀원이 있어야 한다. 그리고 소통을 원활하게 진행하는지, 코드 리뷰를 진행하고 있는지도 알아보면 좋다.

 

• 만약, 부트캠프를 하겠다면, 교육보다는 팀 프로젝트가 가장 장점이라고 생각하기 때문에 어디든 상관없이 가장 저렴한 곳으로 가는 게 낫다.
  • 그러나, 강사님 기준으로 부트캠프는 굳이 갈 필요없다고 생각한다.