3hee_11.log

[Typescript] tsconfig.json 설정하기

Thu, 22 Dec 2022 15:13:19 GMT

npm init -y : package.json 초기화
npm install -D typescript: typescript 설치

💡 -D 붙이면 타입스크립트가 devDependencies에 설치됨

✅ tsconfig.json 생성

tsconfig.json은 타입스크립트 컴파일러 설정 파일이다. node.js는 타입스크립트를 이해하지 못하기 때문에 자바스크립트 코드로 컴파일하는 작업이 필요하다.

{
    // 어디에 타입스크립트 파일이 위치하는지
    "include": ["src"],
    "compilerOptions": {
        // 자바스크립트 파일이 생성될 디렉토리 지정
        "outDir": "build",
        // 자바스크립트 몇버전으로 컴파일할지 지정
        "target": "ES6"
        // 어떤 환경에서 코드를 실행하는 지 지정
        "lib": ["ES6", "DOM"],
        //
        "strict": true
    }
}

✅ TS에서 JS로 만들어진 패키지를 설치했을 때 TS에 패키지의 타입을 정의하는 방법

📄 myPackage.d.ts 생성

d.ts 파일은 자바스크립트로 만들어진 패키지나 라이브러리를 타입스크립트에게 어떤 타입인지 설명한다.

임의로 다른 파일에서 아래 코드와 같은 함수를 만들고(설치한 모듈이라고 가정) index.ts로 불러오면 사진과 같은 경고 메세지가 뜬다.

export function init(config){
    return true;
}

export function exit(code){
    return code + 1;
}

타입스크립트에게 새로 만든 함수의 타입을 알려주기 위해 myPackage.d.ts 파일을 생성해서 아래처럼 작성한다( d.ts의 정의 파일에서 구현이 아닌 호출 시그니처, 즉 타입만 써주면 된다 )

interface Config {
    url: string;
}

declare module "myPackage" {
    function init(config: Config): boolean;
}

경고 메세지가 사라지고 잘 불러와지는 걸 볼 수 있다.

✅ 프로젝트 안에 JS와 TS 파일이 같이 들어있는 경우

경로를 "./myPackage"로 변경

// index.ts
import {init, exit} from "./myPackage";

tsconfig.json 파일에 allowJs:true 추가

{
    // 어디에 타입스크립트 파일이 위치하는지
    "include": ["src", "myPackage.js"],
    "compilerOptions": {
        // 자바스크립트 파일이 생성될 디렉토리 지정
        "outDir": "build",
        // 자바스크립트 몇버전으로 컴파일할지 지정
        "target": "ES6",
        // 어떤 환경에서 코드를 실행하는 지 지정
        "lib": ["ES6", "DOM"],
        "strict": true,
        // 타입스크립트 안에서 자바스크립트 허용
        "allowJs": true
    }
}

🤔 JS에서도 타입 검사를 하고 싶다면?

💡 // @ts-check @ts-check를 .js 파일의 첫 번째 줄에 추가하면 자바스크립트도 타입 검사할 수 있다.

💡 // JSDoc 코멘트로 이루어진 문법으로 함수 바로 위에 코멘트를 적으면 된다. 타입스크립트는 이 코멘트를 읽을 수 있다.

// @ts-check
/**
 * Initializes the project
 * @param {object} config 
 * @param {boolean} config.debug
 * @param {string} config.url
 * @returns {boolean}
 */
export function init(config){
    return true;
}

/**
 * Exit the program
 * @param {number} code 
 * @returns {number}
 */
export function exit(code){
    return code + 1;
}

[Typescript] 클래스와 인터페이스

Wed, 21 Dec 2022 14:56:33 GMT

클래스

class Car {
    constructor(public color:string){
        // 이 부분은 생략이 가능하다. 
        // 파라미터들을 써주기만 하면 TS가 알아서 constructor 함수를 만들어준다.
        this.color = color;
    }

    start(){
        console.log("start");
    }
}

const bmw = new Car("red");
bmw.start();

접근제한자

public - 자식 클래스, 클래스 인스턴스 모두 접근가능(default)
private - 해당 클래스 내부에서만 접근 가능(private 키워드 대신 # 사용 가능)
🚨 상속한 클래스에서도 접근할 수 없으므로 주의! 🚨*
protected - 자식 클래스에서 접근 가능

구분	선언한 클래스 내	상속받은 클래스 내	인스턴스
private	⭕	❌	❌
protected	⭕	⭕	❌
public	⭕	⭕	⭕

static

static 을 사용하면 정적 멤버 변수, 메서드를 만들 수 있다. 클래스. 으로 접근이 가능하다.

class Car {
    // color: string;
    static wheels = 4;
    constructor(public color:string){
        this.color = color;
    }
    start(){
        console.log("start");
        console.log(Car.wheels);
    }
}

const bmw = new Car("red");

readonly

readonly 키워드를 클래스 속성 이름 앞에 추가하면 읽기 전용 속성이 되어 속성을 수정할 수 없다.

class Word {
    constructor(
        public readonly term :string,
        public readonly def :string
    ){}
}

추상 클래스

추상 클래스는 클래스 앞에 abstarct 키워드를 사용한다. 추상 클래스는 new를 이용해서 객체를 만들 수 없고 상속을 할 때만 사용할 수 있다. 👉 오로지 상속만을 위한 것
추상 클래스는 공통된 속성과 메소드를 갖도록 해주는 청사진을 만들기 위해 사용한다.
추상 클래스 안에는 추상 메서드를 구현할 수 있다. 추상 메서드 안에 내용은 추상 메서드가 아닌 상속받은 쪽에서 구현 해야한다.

예제

type Words = {
    // property에 대해 모르고 타입만 알 때 유용
    [key:string]: string
}

class Dict {
    private words: Words

    constructor(){
        // 수동으로 초기화
        this.words = {}
    }

      // 클래스를 타입으로 쓸 수 있다!
    add(word:Word){
        // 사전에 단어가 존재하지 않으면 추가
        if(!this.words[word.term]){
            this.words[word.term] = word.def;
        }
    }

    def(term:string){
        return this.words[term];
    }
}

class Word {
    constructor(
        public term :string,
        public def :string
    ){}
}

const dict = new Dict();
const kimchi = new Word("kimchi", "한국의 음식");

dict.add(kimchi);
dict.def("kimchi");

인터페이스

타입

타입은 객체를 설명하는데도 쓸 수 있고 타입 alias를 만드는데도 사용할 수 있고 특정 값을 가지도록 제한할 수도 있다. 👉 타입은 인터페이스에 비해 더 다양하게 활용할 수 있다.

아래처럼 연산자를 이용해서 타입이 특정값을 가지게 할 수 있다.

type Team = "red" | "blue" | "yellow";
type Health = 1 | 5 | 10

type Player = {
    nickname:string,
    team:Team,
    health: Health
}

const nico:Player = {
    nickname: "yuni",
    team: "red",
    health: 5
}

인터페이스

인터페이스는 타입과 달리 객체의 모양을 특정해주는 용도로만 사용한다.

type Team = "red" | "blue" | "yellow";
type Health = 1 | 5 | 10

interface Player {
    nickname:string,
    team:Team,
    health: Health
}

const nico:Player = {
    nickname: "yuni",
    team: "red",
    health: 5
}

extends 키워드를 이용해 인터페이스를 다른 인터페이스에 상속할 수 있다.

interface User{
    name:string
}

interface Player extends User {

}

const yuni:Player = {
    name: "yuni"
}

// 타입으로도 아래와 같이 작성하면 위 코드와 동일하게 사용할 수 있다.
type User = {
    name:string
}

type Player = User & {

}

const yuni:Player = {
    name: "yuni"
}

🤔 인터페이스와 타입의 차이점

✔ 확장하는 방법(상속) : 인터페이스는 extends, 타입은 &

✔ 선언적 확장 : type은 새로운 속성을 추가하기 위해서 다시 같은 이름으로 선언할 수 없지만, interface는 아래 코드처럼 항상 선언적 확장이 가능하다.

interface User {
  name: string
}
interface User {
  lastName: string
}
interface User {
  health: number
}

✔ interface는 객체에만 사용이 가능하다.

implements를 사용해서 인터페이스의 속성과 메소드를 클래스에서 구현하도록 할 수 있다.

interface User {
    firstName:string,
    lastName:string
    sayHi(name:string):string
    fullName():string
}

interface Human {
    health:number,
}

class Player implements User, Human {
    constructor(
        public firstName:string,
        public lastName:string,
        public health:number,
    ){}

    fullName(){
        return `${this.firstName} ${this.lastName}`;
    }

    sayHi(name:string){
        return `Hello ${name} My name is ${this.fullName()}`;
    }
}

인터페이스는 타입스크립트에서만 존재하기 때문에 추상 클래스를 상속하는 것보다 코드가 가볍다.

참고

typescript type과 interface의 차이

다형성

interface SStorage {
    [key:string]: T
}

class LocalStorage {
      // 제네릭을 전달할 수 있다.
    private storage: SStorage = {}

    set(key:string, value:T){
        this.storage[key] = value;
    }

    remove(key:string){
        delete this.storage[key];
    }

    get(key:string): T {
        return this.storage[key];
    }

    clear(){
        this.storage = {};
    }
}

const stringStorage = new LocalStorage();

stringStorage.get("cat");

Proxy 설정하기

Thu, 13 Oct 2022 02:18:49 GMT

CORS란? 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.

출처란? 웹 콘텐츠의 출처(origin)는 접근할 때 사용하는 URL의 스킴(프로토콜), 호스트(도메인), 포트로 정의된다. 두 객체의 스킴, 호스트, 포트가 모두 일치하는 경우 같은 출처를 가졌다고 말한다. 일부 작업은 동일 출처 콘텐츠로 제한되나 CORS를 통해 제한을 해제할 수 있다.

CORS 정책이 필요한 이유

실제 서비스가 사용되는 앱을 운영 중이라면 클라이언트 뒤의 서버와 연결되어 있는 DB에는 라이브 데이터가 쌓일 것이다. 이런 라이브 데이터는 민감한 데이터들 위주이기 때문에 보안이 중요하다. 만약 서비스 및 프로젝트가 모든 출처의 접근을 허락한다면 보안성이 낮아지고 해킹의 위험에 노출될 수 있다.

따라서 모든 도메인을 허용하지않고 특정 도메인을 허용하도록 구현해야한다. 프론트엔드 개발자가 백엔드 개발자에게 프론트엔드 개발 서버 도메인을 허용해달라고 요청해야하고 백엔드 개발자는 응답 헤더에 필요한 값들을 담아서 전달해줘야한다.

Proxy

그러나 위의 과정없이 React 라이브러리 혹은 Webpack Dev Server에서 제공하는 proxy 기능을 사용하면 CORS 정책을 우회할 수 있다. 이는 별도의 응답 헤더를 받을 필요없이 브라우저는 React 앱으로 데이터를 요청하고 해당 요청을 백엔드로 전달하게된다. 여기서 React 앱이 서버로부터 받은 응답 데이터를 다시 브라우저로 전달하는 방법을 쓰기 때문에 출처가 같아져 브라우저는 CORS 정책을 위반한지 모르게된다.

Proxy 사용법

webpack dev server proxy

webpack dev server의 proxy를 사용하게 되면 브라우저 API를 요청할 때 백엔드 서버에 직접적으로 요청을 하지 않고 현재 개발서버의 주소로 우회 요청을 하게 된다. 그러면 웹팩 개발 서버에서 해당 요청을 받아 그대로 백엔드 서버로 전달하고 백엔드 서버에서 응답한 내용을 다시 브라우저로 반환한다.

웹팩 개발서버의 proxy 설정은 원래 웹팩 설정을 통해서 적용을 하지만 CRA 를 통해 만든 리액트 프로젝트에서는 package.json 에서 proxy 값을 설정하여 쉽게 적용할 수 있도록 구성이 되어 있다.

...
"browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
    "proxy" : "우회할 API 주소"
}

그리고 기존의 fetch 혹은 axios를 통해 요청하던 부분에서 도메인 부분을 제거한다.

export async function getAllfetch() {

    const response = await fetch('우회할 api주소/params');
    .then(() => {
            ...
        })
}

export async function getAllfetch() {

    const response = await fetch('/params');
    .then(() => {
            ...
        })
}

React Proxy 사용법

webpack dev server 에서 제공하는 proxy는 전역적인 설정이기 때문에 종종 해당 방법이 충분히 적용되지 않는 경우가 생기기도 한다. 그래서 수동으로 proxy를 적용해줘야 하는 경우가 있는데 이때는 http-proxy-middleware 라이브러리를 사용한다.

http-proxy-middleware 라이브러리 설치 npm install http-proxy-middleware --save
React App의 src 파일 안에서 setupProxy.js 파일을 생성하고 안에서 설치한 라이브러리 파일을 불러온 다음 아래와 같이 작성한다.
```
const { createProxyMiddleware } = require('http-proxy-middleware');
```

module.exports = function(app) { app.use( '/api', //proxy가 필요한 path prameter 입력합 createProxyMiddleware({ target: 'http://localhost:5000', //타겟이 되는 api url 입력 changeOrigin: true, //대상 서버 구성에 따라 호스트 헤더가 변경되도록 설정하는 부분 }) ); };

- 기존의 fetch 혹은 axios를 통해 요청하던 부분에서 도메인 부분을 제거한다.

```js
export async function getAllfetch() {

    const response = await fetch('우회할 api주소/params');
    .then(() => {
            ...
        })
}

export async function getAllfetch() {

    const response = await fetch('/params');
    .then(() => {
            ...
        })
}

[CI/CD] CI/CD&Github Action

Wed, 12 Oct 2022 14:44:56 GMT

CI/CD

CI(Continuous Integration)

CI는 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미하며 Code-Build-Test단계가 있다. 지속적 통합으로 머지 전 빌드 오류나 테스트 오류를 확인하여 보안 이슈, 에러 등을 쉽게 파악할 수 있어 해당 이슈를 빠르게 개선할 수 있다.

Code : 개발자가 코드를 원격 코드 저장소에 push하는 단계
Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정

CD(Continuous Delivery)

CD는 지속적인 서비스 제공 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다.

지속적인 배포의 경우 코드 변경 사항의 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계로 테스트 자동화와 코드 릴리스 자동화가 포함된다.

Release : 배포 가능한 소프트웨어 패키지를 작성
Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출(실질적인 배포)
Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지

CI/CD의 영역

CI/CD는 지속적 통합 및 지속적 제공의 구축 사례만을 지칭할 때도 있고 지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미할 때도 있다. 좀 더 복잡하게 설명하면 지속적인 서비스 제공은 때로 지속적인 배포의 과정까지 포함하는 방식으로 사용되기도 한다.

결과적으로 CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미한다. 이 용어는 사례별로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라진다.

배포 자동화

배포 자동화란 한번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것을 뜻한다.

배포 자동화의 필요성

수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약됨
휴먼 에러(수동 배포 과정 중 생기는 에러)를 방지할 수 있음

CI/CD 파이프라인

배포에서 파이프라인이란 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻한다. 파이프라인은 전체 배포 과정을 여러 단계로 분리한다. 각 단계는 파이프라인 안에서 순차적으로 실행되며 각 단계마다 주어진 작업들을 수행한다.

파이프라인에서 대표적으로 쓰이는 단계

Source: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우 이를 감지하고 다음 단계로 전달하는 작업을 수행한다.
Build: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다. 또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행한다.
Deploy: Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행한다.

CI/CD 파이프라인 구성 요소 및 장점

빌드 (소프트웨어 컴파일)
테스트 (호환성 및 오류 검사)
릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
배포 (개발에서 프로덕션 환경으로의 변환)
규정 준수 및 유효성 검사

Github Action

Github Action이란?

GitHub Actions는 Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼이다.

레포지토리에서 Pull Request나 push같은 이벤트를 트리거로 GitHub 작업 워크플로를 구성할 수 있다. 워크플로는 하나 이상의 작업이 실행되는 자동화 프로세스로 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행된다.

워크플로는 .yml (혹은 .yaml ) 파일에 의해 구성되며 테스트, 배포 등 기능에 따라 여러개의 워크플로도 만들 수 있다. 생성된 워크플로는 .github/workflows 디렉토리 이하에 위치한다.

배포 링크

[최적화] Lighthouse

Fri, 07 Oct 2022 07:55:22 GMT

구글에서 개발한 성능 측정 도구인 Lighthouse를 사용해 Velog의 성능 검사를 해봤다.

Lighthouse 분석 결과 항목

✅ Performance

Performance 항목에서는 웹 성능을 측정한다. 화면에 콘텐츠가 표시되는데 시간이 얼마나 걸리는지, 표시된 후 사용자와 상호작용하기 까진 얼마나 걸리는지, 화면에 불안정한 요소는 없는지 등을 확인한다.

✅ Accessibility

Accessibility 항목에서는 웹 페이지가 웹 접근성을 잘 갖추고 있는지 확인한다. 대체 텍스트를 잘 작성했는지, 배경색과 콘텐츠 색상의 대비가 충분한지, 적절한 WAI-ARIA 속성을 사용했는지 등을 확인한다.

✅ Best Practices

Best Practices 항목에서는 웹 페이지가 웹 표준 모범 사례를 잘 따르고 있는지 확인한다. HTTPS 프로토콜을 사용하는지, 사용자가 확인할 확률은 높지 않지만 콘솔 창에 오류가 표시 되지는 않는지 등을 확인한다.

✅ SEO

SEO 항목에서는 웹 페이지가 검색 엔진 최적화가 잘 되어있는지 확인한다. 애플리케이션의 robots.txt가 유효한지, 요소는 잘 작성되어 있는지, 텍스트 크기가 읽기에 무리가 없는지 등을 확인한다.

✅ PWA (Progressive Web App)

PWA 항목에서는 해당 웹 사이트가 모바일 애플리케이션으로서도 잘 작동하는지 확인한다. 앱 아이콘을 제공하는지, 스플래시 화면이 있는지, 화면 크기에 맞게 콘텐츠를 적절하게 배치했는지 등을 점수가 아닌 체크리스트로 확인한다.

개선 방향

✅ Properly size images(적절한 크기의 이미지)

Lighthouse는 렌더링된 이미지의 크기와 실제 이미지의 크기를 비교하는데, 여기서 렌더링된 이미지의 크기보다 실제 이미지가 크면 바이트가 낭비되고 페이지 로드 시간이 느려진다.

적절한 크기의 이미지를 제공하기 위한 첫번째 방법은 반응형 이미지 사용이다. 반응형 이미지를 사용하면 각 이미지의 여러 버전을 생성한 다음 미디어 쿼리, 뷰포트 크기 등을 사용하여 HTML 또는 CSS에서 사용할 버전을 지정할 수 있다. 두번째 방법은 이미지 CDN 사용이다. 이미지 변환을 위한 웹서비스 API와 같은 이미지 CDN을 사용해서 적절한 크기의 이미지를 제공할 수 있다. 마지막 방법은 SVG와 같은 벡터 기반 이미지 형식을 사용하는 것이다. SVG 이미지는 한정된 양의 코드를 사용해 어떤 크기로든 확장할 수 있다.

✅ Serve images in next-gen formats(최신 형식의 이미지 제공)

PNG 대신 WebP를 사용하면 용량이 26& 감소하고 JPEG의 경우 25~35% 더 감소된다. AVIF는 JPEG와 비교했을 때 무려 용량의 50%가 감소되며 WebP와 비교했을 땐 20% 감소된다. 이처럼 PNG, JPEG 대신 WebP와 AVIF를 사용하여 이미지의 용량을 줄이고 성능을 개선할 수 있다.

✅ Use video formats for animated content(애니메이션 콘텐츠에 비디오 형식 사용)

용량이 큰 GIF는 애니메이션 콘텐츠를 전달하는데 비효율적이다. 따라서 GIF를 동영상으로 변환하면 사용자의 대역폭을 크게 절약할 수 있다. 네트워크 바이트를 절약하기 위해 GIF 대신 MPEG4, WebM을 사용해야한다.

✅ Efficiently encode images(이미지를 효율적으로 인코딩)

Lighthous는 JPEG 또는 BMP 이미지를 수집하고 각 이미지의 압축 수준을 85로 설정한 다음 원본 버전을 압축 버전과 비교한다. 절감 효과가 4KiB 이상인 경우 Lighthouse는 이미지를 최적화 가능한 것으로 본다.

✅ Reduce unused JavaScript(사용하지 않는 자바스크립트 제거)

Lighthouse는 사용되지 않는 코드가 20KB이상인 모든 Javascript 파일을 최적화 대상으로 본다. 사용하지 않는 Javascript 파일은 페이지의 로드 속도를 늦출 수 있으므로 제거하는 것이 좋다.

✅ Minify JavaScript(자바스크립트 축소)

Javascript 파일을 축소하면 페이로드 크기와 스크립트 구문 분석 시간을 줄일 수 있다. Lighthouse 보고서의 기회 섹션에서는 축소되지 않은 모든 Javascript 파일이 나열되며 축소됐을 때 절약할 수 있는 키비바이트가 표시된다.

여기서 축소는 파일 내부에 필요하지 않은 공백과 코드를 제거하는 프로세스이다. Javascript 압축 도구인 Terser를 이용해서 압축할 수 있다.

[최적화] 캐시 관리

Fri, 07 Oct 2022 05:21:27 GMT

김영한 강사님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 참고했습니다.

캐시란?

캐시는 다운로드 받은 데이터나 값을 미리 복사해놓은 임시 저장소를 뜻한다. 데이터에 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다.

💡 브라우저 캐시 활용시 효과

캐시가 유효한 시간동안 네트워크 리소스를 아낄 수 있다.
파일을 다시 받아올 필요가 없기 때문에 브라우저 로딩이 빠르다.
로딩이 빨라진 만큼 빠른 사용자 경험을 제공한다.

캐시 기본 동작

🚨 캐시 없을 때

데이터에 변경이 없어도 매번 네트워크를 통해서 다운로드 해야 함 👉 인터넷 네트워크는 매우 느리고 비쌈 👉 브라우저 로딩 속도 느림

💡 캐시 있을 때

캐시 가능 시간동안 네트워크를 사용하지 않아도 됨 👉 비싼 네트워크 사용량을 줄일 수 있음 👉 브라우저 로딩 속도가 매우 빠름

캐시 동작 과정

클라이언트가 이미지(예시)를 요청했을 때, 서버는 응답으로 이미지와 함께 캐시 유효 시간을 응답으로 줌
클라이언트는 응답 결과를 브라우저 캐시에 저장
똑같은 이미지를 재요청할 때, 클라이언트는 우선 브라우저 캐시의 캐시 유효 시간을 보고 유효하면 캐시에서 조회함
만약 유효 시간이 초과됐다면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신

검증 헤더와 조건부 요청

🤔 캐시 만료후에도 서버에서 데이터를 변경하지 않았다면?

데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있음
대신 클라이언트와 서버의 데이터가 같은지 확인 해야함

캐시 시간 초과

클라이언트가 데이터를 요청하고 서버가 응답할 때, 캐시 유효 시간 외에 최종 수정 시간(Last-Modified)도 함께 보낸다.
클라이언트는 응답 결과를 브라우저에 캐시에 저장한다.
클라이언트가 똑같은 데이터를 다시 요청할 때, 만약 캐시 유효 시간이 초과되었다면 캐시에서 최종 수정 시간을 꺼내서 요청에 if-modified-since에 넣어 보낸다.
만약 서버가 가진 최종 수정일과 요청으로 보낸 수정일이 동일하다면 304 Not Modified로 바디없이 응답한다.
클라이언트는 서버가 보낸 헤더 정보로 캐시 정보를 갱신하고 브라우저 캐시의 데이터를 재사용한다.

📌 정리

캐시 유효 시간이 초과해도 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답(바디X)
클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
클라이언트는 캐시에 저장되어 있는 데이터 재활용
결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드

검증 헤더

캐시 데이터와 서버 데이터가 같은지 검증하는 데이터 예) Last-Modified , ETag

조건부 요청 헤더

검증 헤더로 조건에 따른 분기 예) If-Modified-Since: Last-Modified, If-None-Match: ETag 사용
조건이 만족하면 200 OK, 만족하지 않으면 304 Not Modified

🚨 Last-Modified, If-Modified-Since 단점

1초 미만 단위로 캐시 조정이 불가능하며 날짜 기반의 로직임
데이터를 수정해서 날짜는 다르지만 수정 결과가 똑같은 경우 판별이 안됨
주석처럼 크게 영향이 없는 변경일 경우 캐시를 유지하고 싶을 때도 변경됨

💡 ETag, If-None-Match

ETag(Entity Tag) : 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠 예) ETag: "v1.0", ETag: "a2jiodwjekjl3"
데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성) 예) ETag: "aaaaa" -> ETag: "bbbbb"
** ETag만 보내서 같으면 유지, 다르면 다시 받음** 👉 캐시 제어 로직을 서버에서 완전히 관리

캐시와 조건부 요청 헤더

Cache-Control: 캐시 제어

Cache-Control : max-age
- 캐시 유효 시간, 초 단위
Cache-Control : no-cache
- 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
Cache-Control : no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨 👉 메모리에서 사용하고 최대한 빨리 삭제

Pragma: 캐시 제어(하위 호환)

Pragma: no-cache
- HTTP 1.0 하위 호환

Expires: 캐시 유효 기간(하위 호환)

캐시 만료일을 정확한 날짜로 지정(HTTP 1.0 부터 사용)
현재는 Cache-Control: max-age 권장 👉 Cache-Control: max-age와 함께 사용하면 Expires는 무시

프록시 캐시

Cache-Control

Cache-Control: public
- 응답이 public 캐시에 저장되어도 됨
Cache-Control: private
- 응답을 private 캐시에 저장해야 함(기본값)
Cache-Control: s-maxage
- 프록시 캐시에만 적용되는 max-age
Age: 60 (HTTP 헤더)
- 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

캐시 무효화

Cache-Control

Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: must-revalidate
- 캐시 만료후 최초 조회시 원 서버에 검증해야함
- 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
- must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
Pragma: no-cache

🤔 no-cache과 must-revalidate의 차이점

no-cache는 원서버에 접근할 수 없는 경우, 서버 설정에 따라서 캐시 데이터를 반환할 수 있음(Error or 200 OK)
must-revalidate는 원 서버에 접근할 수 없는 경우, 항상 오류가 발생해야 함(504 Gateway Timeout)

[최적화] 최적화 기법

Fri, 07 Oct 2022 05:18:18 GMT

📌 최적화란? 컴퓨터 공학에서의 최적화는 적은 리소스를 소모하면서 가능한 빠르게 원하는 결과를 얻을 수 있도록 하는 것을 의미한다. 웹 개발에서의 최적화는 주어진 조건 아래에서 최대한 빠르게 화면을 표시하도록 만드는 것이다.

🧐 최적화의 필요성 및 효과

이탈률 감소
전환율 증가
수익 증대
사용자 경험 향상

최적화 기법

📌 HTML, CSS 코드 최적화하기

HTML 최적화 방법

DOM 트리 가볍게 만들기
- 불필요하게 깊이를 증가시키는 요소 삭제
인라인 스타일 사용하지 않기
- 인라인 스타일은 개별 요소에 스타일 속성을 작성해주는 것이기 때문에 클래스로 묶어서 한번에 작성해도 될 스타일 속성을 중복으로 작성하게 되는 경우가 생긴다.
- CSS 파일을 따로 작성하면 한 번의 리플로우만 발생하는 것과 달리 인라인 스타일은 리플로우를 계속해서 발생시켜 렌더링 완료 시점을 늦춘다.

💡 참고 styled components는 인라인 스타일에 포함되지 않는다. styled components는 javascript 파일 내에 작성되지만 렌더링 시 class를 부여해서 css를 적용하기 때문이다.

CSS 최적화 방법

사용하지 않는 CSS 제거
간결한 셀렉터 사용

📌 리소스 로딩 최적화하기

CSS 파일 불러오기

화면을 렌더링할 때 DOM트리는 HTML 코드를 한줄씩 읽으면서 순차적으로 구성할 수 있지만, CSSOM 트리는 CSS 코드를 모두 해석해야 구성할 수 있다. 따라서 CSSOM 트리를 빠르게 구성할 수 있도록 HTML 문서 최상단(head 요소 안)에 배치하는 것이 좋다.

JS 파일 불러오기

Javascript는 DOM트리와 CSSOM트리를 동적으로 변경할 수 있다. HTML 코드 파싱 중에