프리플라이트, 요청이 두 번 가는 이유

사전 요청이 생기는 조건이 정해져 있습니다

다른 출처로 보내는 요청이 두 번 가는 이유는 브라우저가 먼저 허락을 묻기 때문입니다. 이 사전 요청은 모든 경우에 생기지 않습니다. 단순한 조회 요청이고 표준적인 헤더만 쓰면 바로 보냅니다. 반면 사용자 지정 헤더를 붙이거나, 본문 형식이 표준 목록에 없거나, 조회가 아닌 변경 요청이면 사전 요청이 먼저 갑니다. 그래서 왕복을 줄이는 첫 방법은 조건을 피하는 것입니다. 인증 토큰을 사용자 지정 헤더가 아니라 다른 방식으로 전달할 수 있는지, 본문 형식을 표준 형식으로 바꿀 수 있는지 검토합니다.

피할 수 없으면 허락을 캐시합니다

사전 요청을 없앨 수 없다면 그 결과를 브라우저가 기억하게 만듭니다. 응답에 허락의 유효 기간을 지정하면, 그 기간 동안 같은 조건의 요청은 사전 요청 없이 바로 갑니다. 기간을 길게 두면 왕복이 크게 줄지만, 허용 정책을 바꿀 때 반영이 늦어집니다. 그래서 정책이 안정된 뒤에 기간을 늘립니다. 또 허용 목록을 와일드카드로 두지 않습니다. 넓게 열면 설정은 간단해지지만 인증 정보를 함께 보내는 요청에서는 쓸 수 없고 보안상 위험합니다. 허용할 출처를 목록으로 적고, 요청의 출처가 그 목록에 있을 때만 허용 응답을 돌려줍니다.

왕복 횟수와 대기 시간을 계산합니다

학습용 가정으로 계산합니다. 가정값은 월 요청이 600,000건이고 그중 30퍼센트가 사전 요청을 유발하며, 사전 요청 한 번이 0.15초를 추가한다고 두겠습니다. 사전 요청은 180,000건이고 추가 대기는 27,000초, 분으로는 450분입니다. 이것이 중간 계산값입니다. 최종 효과는 허락 캐시로 계산합니다. 유효 기간을 지정해 사전 요청이 95퍼센트 줄면 9,000건만 남아 추가 대기도 20분 수준으로 내려갑니다. 조건을 피해 사전 요청 자체를 없애면 0이 되지만, 구조 변경이 필요하므로 캐시 설정을 먼저 적용하는 편이 빠릅니다.

서버가 사전 요청에 답하지 않는 경우

결론을 뒤집는 조건은 서버의 응답입니다. 사전 요청은 조회나 변경이 아닌 별도 방식으로 오므로, 서버가 그 방식을 처리하도록 설정돼 있지 않으면 오류로 응답합니다. 그러면 본 요청은 아예 가지 않고 브라우저 콘솔에만 오류가 남아, 서버 기록에는 실패가 보이지 않습니다. 그래서 진단 순서는 브라우저 쪽 기록을 먼저 보는 것입니다. 두 번째 조건은 중간 캐시입니다. 허용 응답이 출처별로 다른데 중간 캐시가 그 차이를 구분하지 않으면, 한 출처의 허용 응답이 다른 출처에 전달될 수 있습니다. 그래서 응답이 달라지는 조건을 선언합니다.

성능 최적화 실행 전 점검표

• 사전 요청을 유발하는 조건을 피할 수 있는지 검토했다
• 허락의 유효 기간을 지정했다
• 허용 출처를 목록으로 제한했다
• 서버가 사전 요청 방식에 응답하도록 설정했다