recursal/MDN huggingface dataset:
보안 컨텍스트
=======

**보안 컨텍스트**는 특정한 최소 인증 및 기밀성 표준이 충족되는 `Window` 또는 `Worker`입니다. 많은 웹 API와 기능들은 보안 컨텍스트에서만 액세스할 수 있습니다. 보안 컨텍스트의 주요 목표는 MITM 공격자가 공격의 피해자를 추가로 손상시킬 수 있는 강력한 API에 접근하지 못하도록 방지하는 것입니다.

왜 일부 기능을 제한해야하나요?
-----------------

웹의 일부 API는 매우 강력하여 공격자가 다음과 같은 작업을 수행할 수 있습니다.

* 사용자의 프라이버시 침해
* 사용자 컴퓨터에 대한 저수준 엑세스 권한을 얻음
* 사용자 자격 증명과 같은 데이터에 대한 액세스 권한을 얻음
컨텍스트는 언제 안전한가요?
---------------

컨텍스트는 보안 컨텍스트 명세서에 정의된 특정한 최소 인증 및 기밀성 표준을 충족할 때 안전하다고 간주됩니다. 특정 문서는 보안 컨텍스트인 최상위 브라우징 컨텍스트(창 또는 탭)의 활성 문서일 때 보안 컨텍스트에 있는 것으로 간주됩니다.

예를 들어 `<iframe>` (en-US) 내에서 TLS를 통해 전달된 문서의 경우에도 TLS를 통해 전달되지 **않은** 상위 항목이 있는 경우 해당 컨텍스트는 안전한 것으로 간주되지 않습니다.

그러나 비(非)보안 컨텍스트로 인해 새 창이 생성되는 경우(noopener (en-US)를 지정하거나 지정하지 않고), 오프너가 안전하지 않다는 사실은 새 창이 안전한 것으로 간주되는것에 영향을 미치지 않는다는 점에 유의해야 합니다. 특정 문서가 보안 컨텍스트에 있는지 여부를 결정하는 것은 비보안 컨텍스트가 문서를 만들었는지가 아니라 연결된 최상위 브라우징 컨텍스트 내에서만 고려하기 때문입니다.

`http://127.0.0.1` URL, `http://localhost` 및 `http://*.localhost` URL(예: `http://dev.whatever.localhost/`) 그리고 `file://`과 같은 로컬에서 제공된 리소스도 안전하게 전달된 것으로 간주됩니다.

**참고:** Firefox 84 이상에서는 `http://localhost`와 `http://*.localhost` URL을 신뢰할 수 있는 원본으로 지원합니다(`localhost`가 로컬/루프백 주소로 매핑되는 것이 보장되지 않았기 때문에 이전 버전에서는 지원하지 않음).

로컬이 아닌 리소스가 안전한 것으로 간주되려면 다음 기준을 충족해야 합니다.

* `https://` 또는 `wss://` URL을 통해 제공되어야 한다.
* 리소스를 전달하는 데 사용되는 네트워크 채널의 보안 속성이 더 이상 사용되지 않는(deprecated) 것이 아니어야 한다.
기능 감지
-----

페이지는 전역 스코프에 있는 `isSecureContext` (en-US) 불리언 값을 사용하여 보안 컨텍스트에 있는지 여부를 확인하기 위해 기능 감지를 사용할 수 있습니다.


```js
if (window.isSecureContext) {
  // 페이지는 보안 컨텍스트이므로 이제 서비스 워커를 사용할 수 있습니다.
  navigator.serviceWorker.register("/offline-worker.js").then(() => {
    // …
  });
}
```

명세서
---

| Specification |
| --- |
| Secure Contexts  |

같이 보기
-----

* 보안 컨텍스트로 제한된 플랫폼 기능 — 보안 컨텍스트에서만 사용할 수 있는 기능 목록
* `isSecureContext` (en-US)
* https://permission.site — HTTP 및 HTTPS를 통해 브라우저가 사용하는 API 권한 검사를 확인할 수 있는 사이트
* Strict-Transport-Security HTTP 헤더
사이트 보안
======

사이트 보안을 위해 할 수 있는 것은 많이 있습니다. 이 문서는 더 유용한 정보를 제공하는 다른 문서의 링크를 포함한 여러 가지 제안 사항을 제공합니다.

**참고:** 이 문서는 작성 중에 있어 완성되지 않았으며, 문서의 제안 사항을 따르더라도 사이트가 완전히 안전하다는 보장은 없습니다.

사용자 정보 보안
---------

양식 자동 완성을 끄는 법

Gecko는 양식 필드의 자동 완성을 지원합니다. 즉, 양식의 값을 기억하고 있다가 다음에 사이트를 방문할 때 자동으로 불러올 수 있습니다. 특정 데이터 유형의 경우, 이 기능을 비활성화할 수 있습니다.

사생활과 :visited 선택자 (en-US)

이 문서에서는 악의적인 사이트가 사용자의 검색 기록을 파악하는 기능을 제거하는 `getComputedStyle()` 메서드의 변경 사항에 대해 설명합니다.

보안 알고리즘을 이용한 해쉬 암호 (OWASP)

암호를 일반 텍스트로 저장하면 공격자가 사이트 사용자의 정확한 암호를 알고 유출하여 잠재적으로 사용자를 위험에 빠뜨릴 수 있습니다. 오래되었거나 안전하지 않은 해쉬 알고리즘(예: md5)을 사용하는 경우에도 동일한 문제가 발생할 수 있습니다. 메시지 다이제스트 알고리즘(예: md5와 sha) 대신 암호별 해쉬 알고리즘(예: Argon2, PBKDF2, scrypt 또는 bcrypt)을 사용해야 합니다. 이 문서는 암호를 저장 사용할 때 사용할 모범 사례를 보여줍니다.

콘텐츠 보안
------

서버 MIME 유형을 올바르게 구성하기 (en-US)

잘못된 MIME 유형이 사이트에 잠재적인 보안 문제를 일으킬 수 있는 몇 가지 상황이 있습니다. 이 문서는 그 중 일부를 설명하고 올바른 MIME 유형으로 파일을 제공하도록 서버를 구성하는 방법을 보여줍니다.

HTTP Strict Transport Security

`Strict-Transport-Security:` HTTP 헤더를 사용하면 웹사이트를 HTTPS를 통해서만 접근할 수 있음을 지정할 수 있습니다.

HTTP 접근 제어

Cross-Origin Resource Sharing 표준은 다른 도메인에서 로드할 수 있는 콘텐츠를 지정하는 방법을 제공합니다. 이를 사용하여 사이트가 부적절하게 사용되는 것을 방지할 수 있습니다. 또한 이를 사용하여 다른 사이트에서 사용하도록 명시적으로 허용된 리소스를 설정할 수 있습니다.

콘텐츠 보안 정책

교차 사이트 스크립팅(XSS)과 데이터 삽입 공격을 포함한 특정 유형의 공격을 감지하고 완화하는 데 도움이 되는 추가 보안 계층입니다. 이러한 공격은 데이터 도용부터 사이트 손상 또는 맬웨어 배포까지, 모든 곳에 사용됩니다. 코드는 피해자에 의해 실행되며 공격자는 접근 제어를 우회하고 사용자를 가장할 수 있습니다.

X-Frame-Options 응답 헤더

`X-Frame-Options:` HTTP 응답 헤더는 브라우저가 `<frame>` (en-US)에서 페이지를 렌더링하도록 허용해야 하는지의 여부를 나타내는 데 사용할 수 있습니다. 사이트는 이를 이용하여 콘텐츠가 다른 사이트에 포함되지 않도록 함으로써 클릭재킹 공격을 피할 수 있습니다.

웹사이트 구성을 통한 접근 제어

사이트를 보호하는 가장 좋은 방법입니다. 특정 IP를 무시하고, 웹사이트의 특정 영역에 대한 접근을 제한하고, 다른 파일을 보호하고, 이미지 핫링크로부터 보호하는 등의 작업을 할 수 있습니다. 예를 들어 .htaccess 파일은 Apache HTTP Server에서 호스팅되는 웹 사이트에 사용됩니다.

같이 보기
-----

* 공개 웹 애플리케이션 보안 프로젝트 (OWASP)
* Mozilla 웹 보안 치트 시트
* OWASP의 교차 사이트 스크립팅
차단된 혼합 콘텐츠가 있는 웹사이트를 고치는 방법
===========================

Firefox 23부터는 기본적으로 액티브 혼합 콘텐츠를 차단합니다. 이는 Chrome에서 채택한 방식을 따른 것입니다.

이 페이지는 웹 개발자로서 알아야 할 사항을 설명합니다.

웹사이트가 고장날 수 있습니다
----------------

웹사이트가 HTTPS 페이지를 제공하는 경우, 이 페이지에서 HTTP를 통해 전달되는 모든 액티브 혼합 콘텐츠는 기본적으로 차단됩니다. 따라서 사용자에겐 웹사이트가 손상된 것처럼 보일 수 있습니다(iframe 또는 플러그인이 로드되지 않는 경우 등). 패시브 혼합 콘텐츠는 기본적으로 표시되긴 하지만, 사용자는 이러한 유형의 콘텐츠도 차단하도록 설정할 수 있습니다.

이미 Chrome부터 혼합 콘텐츠 차단을 시행했기 때문에 웹사이트가 Chrome에서 정상적으로 작동하는 경우, 혼합 콘텐츠 차단 기능이 있는 Firefox에서도 동일하게 작동할 가능성이 높습니다.

어떤 경우든 Firefox에 문제가 있는지 확인하는 가장 좋은 방법은 최신 Firefox 에디션을 다운로드하고, 검사할 여러 페이지에서 웹 콘솔을 열고 ("Security" 메시지 활성화) 웹 사이트에 접속하여 혼합 콘텐츠와 관련된 사항이 보고되는지 확인하는 것입니다. 또는 SSL-check나 Missing Padlock과 같은 무료 온라인 크롤러, HTTPSChecker와 같은 데스크톱 크롤러, 아니면 mcdetect과 같은 CLI 도구를 사용하여 웹사이트를 재귀적으로 검사하고 안전하지 않은 콘텐츠의 링크를 찾을 수 있습니다. 혼합 콘텐츠에 대한 언급이 없다면 웹사이트는 좋은 상태입니다. 계속해서 멋진 웹사이트를 만드세요!

웹사이트를 고치는 방법
------------

혼합 콘텐츠 차단을 피하는 가장 좋은 전략은 모든 콘텐츠를 HTTP가 아닌 HTTPS로 제공하는 것입니다.

**자체 도메인의 경우,** 모든 콘텐츠를 HTTPS로 제공하고 링크를 수정하세요. 콘텐츠의 HTTPS 버전이 이미 존재하는 경우가 많으므로 http://에서 https://로 링크에 "s"를 추가하기만 하면 됩니다.

그러나 경우에 따라서 해당 미디어의 경로가 올바르지 않을 수도 있습니다. linkchecker와 같이 이 문제를 해결하는 데 도움이 되는 온라인 및 오프라인 도구(운영 체제에 따라 다름)가 있습니다.

**다른 도메인의 경우,** 사용 할 수 있다면 사이트를 HTTPS 버전으로 사용하세요. HTTPS를 사용할 수 없는 경우, 해당 도메인에 연락하여 HTTPS를 통해 콘텐츠를 제공할 수 있는지 문의해 보세요.
보안 컨텍스트로 제한된 기능들
================

이 참조는 보안 컨텍스트에서만 사용할 수 있는 웹 플랫폼 기능을 나열합니다. 정의와 자세한 내용은 보안 컨텍스트를 참조하세요.

보안 컨텍스트에서만 사용할 수 있는 현재 기능들
--------------------------

이 섹션에는 명세를 보안 컨텍스트에서만 사용할 수 있는 API가 나열되어 있습니다.

* Async Clipboard API (en-US)
* Background Sync (예시로 `SyncManager` (en-US)를 보세요.)
* `Cache-Control: immutable`
* Credential Management API
* Device Orientation / Device Motion (en-US)
* EyeDropper API (en-US)
* Encrypted Media Extensions (en-US)
* Generic Sensor API
* `Geolocation`
* Notifications API
* Payment Request API (en-US)
* Presentation API (en-US)
* Push API
* Reporting API (en-US)
* Service Workers
* Storage API (en-US)
* Web Authentication API (en-US)
* Web Bluetooth
* Web MIDI (en-US)
* Web Crypto API (en-US)
* WebGPU API (en-US)
* Web Share API (en-US)

추가로, 다음 메서드에는 보안 컨텍스트가 필요합니다(연결된 API가 필요하지 않더라도).

* `MediaDevices.getUserMedia()` (en-US)
* `Navigator.registerProtocolHandler()`
같이 보기
-----

* 보안 컨텍스트
* Chrome Platform Status에서 "secure context" 검색
양식 자동 완성을 끄는 방법
===============

이 문서는 웹사이트에서 양식 필드의 자동 완성을 비활성화하는 방법에 대해 설명합니다.

기본적으로 브라우저는 사용자가 웹사이트의 `<input>` (en-US) 필드를 통해 제출한 정보를 기억합니다. 이를 통해 브라우저는 자동 완성(즉, 사용자가 입력하기 시작한 필드에 대해 가능성 있는 완성을 제안) 또는 자동 채우기(즉, 로드 시 특정 필드를 미리 채움)를 제공할 수 있습니다.

일반적으로 이러한 기능은 기본적으로 활성화되어 있지만, 사용자의 개인 정보 보호에 문제가 될 수 있으므로 사용자는 브라우저에서 이 기능을 비활성화할 수 있습니다. 그러나 양식으로 제출된 데이터 중 일부는 향후에 유용하지 않거나(예: 일회성 핀) 민감한 정보(예: 고유한 정부 식별자 또는 신용 카드 보안 코드)를 포함하기 때문에, 웹 사이트 개발자로서, 브라우저의 자동 완성 기능이 활성화된 경우에도 브라우저가 이러한 필드의 값을 기억하지 않기를 원할 수 있습니다.

실제로 WCAG 2.1 Success Criterion 1.3.5: Identify Input Purpose는 자동 완성/자동 채우기가 작동할 것을 요구하지 않습니다. 단지 특정 개인 사용자 정보와 관련된 양식 필드가 프로그래밍 방식으로 식별되기만 하면 됩니다. 즉, 양식 자체에 대한 자동 완성 기능이 꺼진 경우에도 기준을 통과할 수 있습니다(개별 양식 필드에 관련 `autocomplete` 속성을 추가하여).

자동 완성 비활성화하기
------------

양식에서 자동 완성을 비활성화하려면 `autocomplete` 속성을 "off"로 설정합니다.
```

autocomplete="off"
```


전체 양식 또는 양식의 특정 입력 요소에 대해서도 이 작업을 수행할 수 있습니다.


```html
<form method="post" action="/form" autocomplete="off">
  …
</form>
```



```html
<form method="post" action="/form">
  …
  <div>
    <label for="cc">신용 카드:</label>
    <input type="text" id="cc" name="cc" autocomplete="off" />
  </div>
</form>
```


필드에 `autocomplete="off"`를 설정하면 두 가지 효과가 있습니다.

* 브라우저에 따라 이를 준수하는 휴리스틱이 다르긴 하지만, 나중에 비슷한 양식에서 자동 완성을 위해 사용자가 입력한 데이터를 저장하지 않도록 브라우저에 지시합니다.
* 브라우저가 세션 기록에서 양식 데이터를 캐싱 하는 것을 방지합니다. 양식 데이터가 세션 히스토리에 캐시 되면, 사용자가 양식을 제출하고 원래 양식 페이지로 돌아가기 위해 뒤로 가기 버튼을 클릭했을 때, 사용자가 작성한 정보가 표시됩니다.

자동 완성을 해제한 후에도 브라우저가 계속 자동 완성을 제안하는 경우, 입력 요소의 이름 특성을 변경해야 합니다.

자동 완성의 특성과 로그인 필드
-----------------

최신 브라우저는 통합된 비밀번호 관리를 제공합니다. 사용자가 사이트에 대한 사용자 이름과 암호를 입력하면, 브라우저는 사용자를 위해 이를 기억하는 것을 제안합니다. 사용자가 사이트를 다시 방문하면 브라우저는 저장된 값으로 로그인 필드를 자동으로 채웁니다.

또한, 사용자는 브라우저에서 저장된 로그인 정보를 암호화하는 데 사용할 마스터 암호를 선택할 수 있습니다.

마스터 암호가 없더라도 브라우저 내 암호 관리는 일반적으로 전체적인 보안 향상으로 이어집니다. 사용자는 브라우저가 저장한 암호를 기억할 필요가 없기 때문에 암호를 기억해야 하는 경우보다 더 강력한 암호를 선택할 수 있습니다.

이러한 이유로, 많은 최신 브라우저가 로그인 필드에 대해 `autocomplete="off"`를 지원하지 않습니다.

* 사이트에서 사용자 이름과 암호 입력 필드가 포함된 `<form>`에 `autocomplete="off"`를 설정하면, 브라우저는 여전히 이 로그인을 기억하도록 제안하고, 사용자가 동의하면 다음에 사용자가 페이지를 방문할 때 브라우저가 해당 필드를 자동으로 채웁니다.
* 사이트에서 사용자 이름과 비밀번호 `<input>` (en-US) 필드에 `autocomplete="off"`를 설정하면, 브라우저는 여전히 이 로그인을 기억하도록 제안하고, 사용자가 동의하면 다음에 사용자가 페이지를 방문할 때 브라우저가 해당 필드를 자동으로 채웁니다.
### autocomplete="new-password"를 사용하여 자동 채우기 방지하기

사용자가 다른 사람의 새 암호를 지정할 수 있는 사용자 관리 페이지에서 암호 필드의 자동 채우기를 방지하기 위해 `autocomplete="new-password"`를 사용할 수 있습니다.

브라우저는 이 힌트를 준수할 필요가 없습니다. 그러나, 최신 브라우저는 바로 위와 같은 이유로 `autocomplete="new-password"`가 있는 `<input>` 요소의 자동 채우기를 중단했습니다. 예를 들어, Firefox 버전 67(Firefox bug 1119063 참조)은 이 경우에 대해 자동 채우기를 중지했습니다. 그러나, Firefox 70(Firefox bug 1565407 참조)은 안전하게 생성된 암호를 제안할 수 있지만, 저장된 암호를 자동으로 채우지는 않습니다. 자세한 내용은 `autocomplete` 호환성 표를 참조하세요.
지연 로딩
=====

**지연 로딩**은 리소스를 논 블로킹(중요하지 않음)으로 식별하여 필요할 때만 로드하는 전략입니다. 이는 중요 렌더링 경로의 길이를 단축하는 방법으로, 페이지 로드 시간을 감소시킬 수 있습니다.

지연 로딩은 애플리케이션의 여러 순간에 발생할 수 있지만, 일반적으로 스크롤 및 내비게이션과 같은 일부 사용자의 상호 작용에서 발생합니다.

개요
--

웹이 발전함에 따라 사용자에게 보내지는 에셋의 수와 크기가 크게 증가했습니다. 2011년과 2019년 사이에 리소스 무게의 중앙값은 데스크톱의 경우 **~100KB** 에서 **~400KB**로, 모바일의 경우 **~50KB**에서 **~350KB**로 증가했습니다. 반면 이미지 크기는 테스크톱의 경우 **~250KB** 에서 **~900KB**로, 모바일의 경우 **~100KB** 에서 **~850KB**로 증가했습니다.

이 문제를 해결하기 위해 사용할 수 있는 방법 중 하나는 첫 번째 렌더링이 발생하는데 중요하지 않은 리소스를 지연 로딩하여 중요 렌더링 경로 길이를 단축시키는 것입니다. 실제적인 예제로는 장바구니 페이지/섹션으로 연결하는 링크가 있는 전자 상거래 사이트의 홈페이지에 방문했을 때, **해당 페이지로 이동할 때까지** 장바구니 페이지의 리소스(예를 들어 JavaScript, CSS, 이미지)가 다운로드되지 않는 경우를 들 수 있습니다.

전략
--

지연 로딩은 여러 리소스와 전략을 통해 적용될 수 있습니다.

### 일반적인 사용

#### 코드 분할

JavaScript, CSS, HTML을 더 작은 덩어리로 분할할 수 있습니다. 이렇게 하면 값을 제공하는데 요구되는 최소한의 코드만 미리 보내서 페이지 로드 시간을 개선할 수 있습니다. 나머지는 필요에 따라 로드될 수 있습니다.

* 진입점 분할: 앱의 진입점에 따라 코드를 분리합니다.
* 동적 분할: dynamic import() 문이 사용되는 코드를 분리합니다.
### JavaScript

#### 스크립트 type module

`type="module"`이 있는 모든 스크립트 태그는 JavaScript 모듈로 취급되며 기본적으로 지연됩니다.

### CSS

기본적으로 CSS는 렌더링 렌더링 차단 리소스로 취급되므로 브라우저는 CSSOM이 구성될 때까지 어떠한 처리된 콘텐츠를 렌더링하지 않습니다. CSS는 얇고 가능한 빠르게 전달되어야 하며 사용 미디어 타입 및 쿼리는 렌더링 차단을 해제하는 것이 좋습니다.


```html
<link href="style.css" rel="stylesheet" media="all" />
<link href="portrait.css" rel="stylesheet" media="(orientation:portrait)" />
<link href="print.css" rel="stylesheet" media="print" />
```


이를 달성하기 위해 몇몇 CSS 최적화 (en-US)를 수행할 수 있습니다.

### 폰트

기본적으로 폰트 요청은 렌더 트리가 구성될 때까지 지연되므로 텍스트 렌더링이 지연될 수 있습니다.

기본 동작을 재정의하고 `<link rel="preload">`, CSS 폰트 표시 속성 및 폰트 로딩 API (en-US)를 사용하여 웹 폰트 리소스를 미리 로드할 수 있습니다.

같이 보기: Element Link

### 이미지 및 iframes

웹페이지에는 데이터 사용량과 페이지 로드 속도에 영향을 미치는 많은 이미지가 포함되어 있는 경우가 많습니다. 이러한 이미지의 대부분은 화면 밖(중요하지 않음)에 있으므로 스크롤과 같은 사용자 상호 작용이 있어야 볼 수 있습니다.

#### 로딩 속성

`<img>` 요소의 `loading` 속성 또는 `<iframe>` (en-US)의 `loading` (en-US) 속성을 사용하여 화면 밖에 있는 이미지/iframe의 로딩을 사용자가 가까이 스크롤할 때까지 지연시키도록 브라우저에 지시할 수 있습니다. 이렇게 하면 중요하지 않은 리소스가 필요한 경우에만 로드되어 초기 페이지 로드 속도가 빨라지고 네트워크 사용량이 감소할 수 있습니다.


```html
<img src="image.jpg" alt="..." loading="lazy" />
<iframe src="video-player.html" title="..." loading="lazy"></iframe>
```


`load` 이벤트는 열심히 로드된 콘텐츠가 모두 로드되었을 때 발생합니다. 이때 visual viewport 내에 아직 로드되지 않은 느리게 로드된 이미지나 iframe이 있을 수 있습니다. (또는 그럴 가능성이 높습니다.)

지정된 이미지의 불리언 `complete` (en-US) 속성 값을 검사하여 로딩이 완료되었는지 확인할 수 있습니다.

#### Intersection Observer API

Intersection Observers는 관찰된 요소가 브라우저의 뷰포트에 들어오고 나가는 시점을 사용자가 알 수 있도록 해줍니다.

#### 이벤트 처리기

브라우저 호환성이 중요한 경우 몇 가지 옵션이 있습니다.

* polyfill intersection observer
* 특정 요소가 뷰포트에 있는지 확인하기 위해 스크롤, 크기 조정 또는 방향 변경 이벤트 처리기로 대체합니다.
명세서
---

| Specification |
| --- |
| HTML Standard # lazy-loading-attributes |

같이 보기
-----

* Render blocking CSS
* Optimizing loading and rendering
* Lazy loading images and video
대기 시간(Latency) 이해하기
===================

**대기 시간(Latency)** 이란 하나의 데이터 패킷이 출발지에서 도착지까지 가는 데 걸리는 시간을 뜻합니다. 성능 최적화에 있어서 대기 시간의 원인을 줄이는 것과 연결 상태가 좋지 않은 사용자를 고려하여 대기 시간이 긴 환경에서 사이트 성능을 테스트하는 것은 중요합니다. 이 글에서 대기 시간이 무엇인지, 대기 시간이 성능에 어떤 영향을 주는지, 이를 어떻게 측정하고 어떤 방법으로 줄일 수 있을지에 관해 설명합니다.

대기 시간이란?
--------

대기 시간이란 일반적으로 사용자가 요청을 한 시점부터 해당 사용자에게 요청에 대한 응답을 받기까지 걸리는 시간을 말합니다. 첫 번째 요청에서 14KB 만큼의 DNS 조회, TCP handshake, 보안 TLS 협상 등의 과정을 거치기 때문에 대기 시간이 깁니다. 이후의 후속 요청은 서버에 대한 연결이 이미 설정되어 있으므로 대기 시간이 줄어듭니다.

대기 시간은 네트워크나 인터넷 연결의 지연 시간을 나타냅니다. 대기 시간이 짧다는 것은 지연이 없거나 거의 없음을 의미합니다. 대기 시간이 길다는 것은 지연이 많다는 것을 의미합니다. 성능 향상의 주요 목표 중 하나는 대기 시간을 줄이는 것입니다.

기본적인 HTML 페이지와 같이 한 개의 자원에 대한 대기 시간은 사소해 보일 수 있습니다. 하지만 웹사이트는 일반적으로 여러 개의 요청을 포함합니다. HTML은 여러 개의 CSS, 스크립트, 미디어 파일에 대한 요청으로 이루어져 있기 때문입니다. 이런 요청의 개수와 크기가 커질수록 높은 대기 시간이 사용자 경험에 미치는 영향 또한 커집니다.

대기 시간이 짧은 연결에서는 요청된 자원이 거의 즉시 보입니다. 대기 시간이 긴 연결에서는 요청을 보낸 시점과 자원을 받은 시점 사이에 눈에 띄는 지연이 있습니다. 대기 시간은 데이터가 네트워크의 한 지점에서 다른 지점으로 이동하는 속도를 측정하여 얻을 수 있습니다.

대기 시간은 한 가지 방법으로 측정할 수 있는데, 예를 들면 자원에 대한 요청을 보내는 데 걸리는 시간 혹은 자원에 대한 브라우저의 요청이 다시 브라우저로 돌아오기까지 왕복 시간을 측정합니다.

네트워크 스로틀링
---------

개발자 도구를 사용하여 저대역폭 네트워크 연결로 전환하면 저대역폭 네트워크의 대기 시간을 모방할 수 있습니다.

![스로틀링을 모방하여 대기 시간을 모방하기](/ko/docs/Web/Performance/Understanding_latency/emulate_latency.png)

개발자 도구에서 network 테이블의 스로틀링 옵션을 통해 2G, 3G 혹은 다른 대역폭으로 전환할 수 있습니다. 다양한 브라우저의 개발자 도구에는 서로 다른 사전 설정 옵션이 있으며, 모방되는 특성에는 다운로드 속도, 업로드 속도, 최소 대기 시간 또는 데이터 패킷을 보내는 데 필요한 최소 타입이 포함됩니다. 일부 사전 설정의 대략적인 값은 다음과 같습니다.

| 선택 | 다운로드 속도 | 업로드 속도 | 최소 대기 시간 (ms) |
| --- | --- | --- | --- |
| GPRS | 50 Kbps | 20 Kbps | 500 |
| 일반적인 2G | 250 Kbps | 50 Kbps | 300 |
| 좋은 2G | 450 Kbps | 150 Kbps | 150 |
| 일반적인 3G | 750 Kbps | 250 Kbps | 100 |
| 좋은 3G | 1.5 Mbps | 750 Kbps | 40 |
| 일반적인 4G/LTE | 4 Mbps | 3 Mbps | 20 |
| DSL | 2 Mbps | 1 Mbps | 5 |
| Wi-Fi | 30 Mbps | 15 Mbps | 2 |

네트워크 시간 측정
----------

네트워크 탭에서 각 요청이 완료되는데 소요된 시간도 확인할 수 있습니다. 아래 사진처럼 크기가 267.5Kb인 SVG 이미지를 다운로드 받는 데 얼마나 걸렸는지 볼 수 있습니다.

![크기가 큰 SVG 이미지를 로드하는데 걸린 시간](/ko/docs/Web/Performance/Understanding_latency/latencymlw.png)

요청이 대기열에 있으면 네트워크 연결을 기다리는 동안 **blocked(차단)** 된 것으로 간주합니다. 차단은 하나의 서버에 동시에 너무 많은 HTTP 연결을 맺으려 할 때 발생합니다. 모든 연결이 사용 중이면 브라우저는 다른 연결이 해제될 때까지 자원을 다운로드하지 못하는데 이를 두고 요청과 자원이 차단되었다고 말합니다.

**DNS resolution** 항목은 DNS lookup 을 수행하는 데 걸린 시간을 뜻합니다. hostname 의 개수가 많을수록 DNS lookup 의 수행 횟수 또한 늘어납니다.

**Connecting** 항목은 TCP handshake 을 완료하는 데 걸린 시간을 뜻합니다. 위의 DNS처럼 필요로 하는 서버 연결의 개수가 많을수록 서버와의 연결을 생성하는데 걸리는 시간 또한 늘어납니다.

**TLS handshake** 항목은 보안 연결을 수립하는 데 걸린 시간을 뜻합니다. 물론 TLS handshake 는 안전하지 않은 연결보다 연결하는데 오래 걸리지만 그만큼의 시간은 안전한 연결을 위해 투자할 가치가 있습니다.

**Sending** 항목은 HTTP 요청을 서버로 전송하는데 걸린 시간을 뜻합니다.

**Waiting** 항목은 디스크 대기 시간으로, 서버가 응답을 완료하는데 걸린 시간을 뜻합니다. 디스크 대기 시간은 성능 문제의 주요 원인이었지만 컴퓨터 메모리와 CPU의 발전에 따라 서버의 성능 또한 개선되었습니다. 서버가 수행해야 하는 일의 복잡도에 따라 이 항목은 여전히 문제가 될 수도 있습니다.

**Receiving** 항목은 자원을 다운로드 받는 데 걸린 시간을 뜻합니다. Receiving 시간은 네트워크 용량과 자원 파일의 크기에 따라 결정됩니다. 이미지가 캐싱되었다면 즉각적으로 완료되었을 수 있고, 스로틀링이 걸렸다면 43초가 걸렸을 수도 있습니다!

대기 시간 측정
--------

**Network latency** 란 데이터 요청이 요청을 작성하는 컴퓨터에서 응답하는 컴퓨터에 도달하는 데 걸리는 시간을 말합니다. 이는 데이터가 응답하는 컴퓨터에서 요청한 컴퓨터로 다시 돌아오는 시간을 포함합니다. 일반적으로 왕복 지연으로 측정됩니다.

**Disk latency** 란 컴퓨터(일반적으로 서버)가 요청을 수신한 시점부터 응답을 반환하기까지 걸린 시간을 말합니다.
Axes
====

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축
 XPath 명세에는 축이 13가지가 있습니다. 축은 문맥 노드와의 관계를 나타내고 트리 위에 문맥 노드에 대응하여 노드를 위치시킬 때 씁니다. 다음은 이용가능한 축 13가지와 Gecko에서 가능한 지원 정도에 대한 매우 짧은 설명입니다.
XPath 식 사용에 관한 추가 정보는, Transforming XML with XSLT 문서 끝 For Further Reading 절을 보세요.

ancestor

부모 노드부터 시작하여 루트 노드까지 항해하는 문맥 노드의 모든 조상을 나타냅니다.

ancestor-or-self

문맥 노드와 루트 노드를 포함하는 문맥 노드의 조상 모두를 나타냅니다.

attribute

문맥 노드의 속성을 나타냅니다. 오직 요소만 속성이 있습니다. 이 축은 at sign(`@`)으로 줄여 쓸 수 있습니다.

child

문맥 노드의 자식을 나타냅니다. XPath 식이 축을 지정하지 않으면 기본값으로 이해합니다. 오직 루트 노드나 요소 노드만 자식이 있기 때문에, 다른 경우에는 아무것도 선택하지 않습니다.

descendant

문맥 노드의 모든 자식과 자식의 자식 따위를 나타냅니다. 속성과 이름공간 노드는 포함하지 **않습니다**. `속성` 노드의 `parent` 축이 요소 노드이지만 `속성` 노드는 그 부모의 자식이 아닙니다.

descendant-or-self

문맥 노드와 문맥 노드의 모든 자손을 나타냅니다. 속성과 이름공간 노드는 포함하지 **않습니다**. `속성` 노드의 `parent` 축이 요소 노드이지만 `속성` 노드는 그 부모의 자식이 아닙니다.

following

`자손`, `속성`, `이름공간` 노드를 제외한 문맥 노드 다음에 나오는 모든 노드를 나타냅니다.

following-sibling

문맥 노드와 부모가 같고 소스 문서에서 문맥 노드 다음에 보이는 모든 노드를 나타냅니다.

namespace
*(지원 안 함)*

문맥 노드 범위(scope) 안에 있는 모든 노드를 나타냅니다. 이 경우에, 문맥 노드는 요소 노드이어야 합니다.

parent

문맥 노드의 부모 노드만을 나타냅니다. 마침표 둘(`..`)로 줄여 쓸 수 있습니다.

preceding

`조상`, `속성`, `이름공간` 노드를 제외한 문서 안에서 문맥 노드를 앞선 모든 노드를 나타냅니다.

preceding-sibling

문맥 노드와 부모가 같고 소스 문서에서 문맥 노드 앞에 나오는 모든 노드를 나타냅니다.

self

문맥 노드 자신를 나타냅니다. 마침표 하나(`.`)로 줄여 쓸 수 있습니다.
Functions
=========

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축
 다음은 설명, 문법, 인수 목록, 결과형, 해당 W3C 권고안 소스, 현 Gecko 지원 정도를 포함하는 기본 XPath 함수와 XPath에 더해진 XSLT 고유의 추가분에 주석을 단 목록입니다. XPath/XSLT 함수 사용에 관한 추가 정보는, For Further Reading 페이지를 봐 주세요.
* boolean()
* ceiling()
* concat()
* contains()
* count()
* current()
*XSLT 고유*
* document()
*XSLT 고유*
* element-available()
* false()
* floor()
* format-number()
*XSLT 고유*
* function-available()
* generate-id()
*XSLT 고유*
* id()
*(부분 지원함)*
* key()
*XSLT 고유*
* lang()
* last()
* local-name()
* name()
* namespace-uri()
* normalize-space()
* not()
* number()
* position()
* round()
* starts-with()
* string()
* string-length()
* substring()
* substring-after()
* substring-before()
* sum()
* system-property()
*XSLT 고유*
* translate()
* true()
* unparsed-entity-url()
*XSLT 고유*
*(지원 안 함)*
element-available
=================

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`element-available` 함수는 요소가 이용 가능한 지를 결정하고 true나 false를 반환합니다.

### 구문
```

element-available(QName )
```

### 인수

`QName`

유효한 QName으로 평가해야 합니다. QName은 식 범위(scope)에서 이름공간 선언을 써서 확장 이름으로 확장됩니다.

### 반환

만약 확장 이름이 명령 이름이면 true를 반환합니다. 만약 확장 이름에 XSLT 이름공간 URI와 같은 이름공간 URI이 있으면, XSLT로 정의된 요소를 참조합니다. 그렇지 않으면, extension 요소를 참조합니다. 만약 확장 이름에 null 이름공간 URI가 있으면, element-available 함수는 false를 반환합니다.

### 정의

XSLT 1.0 15

### Gecko 지원

지원함.
true
====

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`true` 함수는 불린값 true를 반환합니다.

### 구문
```

true()
```

### 반환

불린 `true`.

### 정의

XPath 1.0 4.3

### Gecko 지원

지원함.
starts-with
===========

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`starts-with` 함수는 첫 번째 문자열이 두 번째 문자열로 시작하는 지를 확인한 뒤 true나 false를 반환합니다.

### 구문
```

starts-with(haystack ,needle)
```

### 인수

`haystack`

들여다볼(look in) 문자열.

`needle`

찾을(look for) 문자열.

### 반환

 만약
 `haystack`
 이
 `needle`
 로 시작하면 `true`. 그렇지 않으면, `false`.

### 정의

XPath 1.0 4.2

### Gecko 지원

지원함.
unparsed-entity-url
===================

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`unparsed-entity-url()` 함수는 구문해석되지 않은 엔티티의 URI를 반환합니다. 이는 소스 문서의 DTD에서 참조하는 비 XML 데이터입니다.

### 문법
```

string unparsed-entity-url(string)
```

### 인수

구문해석되지 않은 엔티티의 이름. 인수가 문자열이 아니면, string() 함수의 규칙을 써서 변환합니다. 이름은 XML 이름입니다.

### 반환

엔티티가 있으면, DTD에서 찾은 구문해석되지 않은 엔티티의 URI. 그렇지 않으면 빈 문자열.

### 정의

XSLT 1.0 12.4

### Gecko 지원

지원 안 함.
local-name
==========

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`local-name` 함수는 인수로 준 노드 집합 안 첫 노드의 지역 이름을 나타내는 문자열을 반환합니다.

### 구문
```

local-name( [node-set] )
```

### 인수

`node-set`(선택사항)

이 노드 집합 안 첫 노드의 지역 이름이 반환됩니다. 이 인수를 빼면, 현재 문맥 노드를 씁니다.

### 반환

문자열.

### 주의

* 지역 이름은 expanded-name의 지역 부분입니다.
### 정의

XPath 1.0 4.1

### Gecko 지원

지원함.
number
======

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`number` 함수는 개체를 숫자로 변환하고 그 숫자를 반환합니다.

### 구문
```

number( [object] )
```

### 인수

`object`
 (optional)


숫자로 변환할 개체.

### 반환

개체를 변환한 뒤 결과 숫자.

### 주의

* 문자열은 숫자 앞 문자열의 앞 공백 문자를 떼고(strip) 숫자 뒤의 것을 무시하여 숫자로 변환됩니다. 문자열이 패턴과 일치하지 않으면, 그 문자열은 NaN으로 변환됩니다.
* Boolean true는 1로 false는 0으로 변환됩니다.
* 노드 집합은 먼저 as if by a call to the string function 문자열로 변환되고 나서 같은 식으로 문자열 인수로 변환됩니다.
* 네 가지 기본 타입 말고 다른 타입의 개체는 그 타입에 의존하는 방법으로 숫자로 변환됩니다.
### 정의

XPath 1.0 4.4

### Gecko 지원

지원함.
round
=====

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`round` 함수는 인수로 준 수에 가장 가까운 정수를 반환합니다.

### 구문
```

round(decimal )
```

### 인수

`decimal`

정수 처리(round)될 10진수.

### 반환

 인수
 *`decimal`*
 보다 작거나 크거나 같은 가장 가까운 정수.

### 주의

* -0.5는 음수 0으로 0.4는 양수 0으로 정수 처리됩니다.
### 정의

XPath 1.0 4.4

### Gecko 지원

지원함.
sum
===

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`sum` 함수는 인수로 준 노드 집합의 각 노드의 숫자값의 합을 반환합니다.

### 구문
```

sum(node-set )
```

### 인수

`node-set`

평가될 노드 집합. 이 노드 집합의 각 노드는 마치 `number` 함수에 넘겨준 것처럼 평가되고 결과 수의 합이 반환됩니다.

### 반환

숫자.

### 주의

*없음.*

### 정의

XPath 1.0 4.3

### Gecko 지원

지원함.
position
========

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`position` 함수는 식 평가 문맥(expression evaluation context)와 위치가 같은 숫자를 반환합니다.

### 구문
```

position()
```

### 반환

식 평가 문맥과 위치가 같은 정수.

### 주의

* 문맥 안 노드의 위치는 0 기반이 아님을 주의하세요. 첫 노드는 위치가 1입니다.
* 문맥은 경로의 나머지로 결정됩니다.
```

<xsl:template match="//a[position() = 5">
 <!-- 이 템플릿은 문서 안 다섯 번째 a 요소와 일치합니다. -->
</xsl:template>
```


```
<xsl:template match="//div[@class='foo']/bar[position() = 1]">
 <!-- 이 템플릿은 class 속성이 "foo"이고 div 요소의 자식인 첫 번째 bar 요소와 일치합니다 -->
</xsl:template>
```

### 정의

XPath 1.0 4.1

### Gecko 지원

지원함.
id
==

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`id` 함수는 인수로 준 id와 일치하는 노드를 찾아 그 식별된 노드를 포함하는 노드 집합을 반환합니다.

### 구문
```

id(expression )
```

### 인수

`expression`

만약 `expression`이 노드 집합이면, 노드 집합 안 각 노드의 문자열 값은 개별 id로 다룹니다. 반환하는 노드 집합은 그 id와 대응하는 노드입니다.

만약 `expression`

이 문자열이나, 노드 집합이 아닌 어떤 거라면, `expression` 은 공백으로 구분된 id 목록으로 다룹니다. 반환하는 노드 집합은 그 id와 대응하는 노드입니다.

### 반환

그 노드를 포함하는 노드 집합이나 인수로 준 id로 식별된 노드.

### 주의

* XML 문서의 DTD가 어떤 속성이 ID인지를 결정합니다. XPath 1.0 5.2.1를 보세요.
### 정의

XPath 1.0 4.1

### Gecko 지원

부분 지원함.
false
=====

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`false` 함수는 boolean false를 반환합니다.

### 구문
```

false()
```

### 반환

Boolean `false`.

### 주의

이 함수는 비교(comparison)하는 부분에 쓸모가 있습니다.
```

<xsl:if test="boolean((1 &gt; 2) = false())">
 The expression evaluates as true
</xsl:if>
```

### 정의

XPath 1.0 4.3

### Gecko 지원

지원함.
substring-before
================

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`substring-before` 함수는 첫 번째 인수에서 두 번째 인수가 나타난 앞의 나머지를 반환합니다.

### 구문
```

substring-before(haystack ,needle )
```

### 인수

`haystack`

평가할 문자열. 이 문자열의 부분이 반환됩니다.

`needle`

 찾을 부분 문자열.
 `haystack`
 에서
 `needle`
 의 첫 출현 앞의 문자열이 반환됩니다.


### 반환

문자열.

### 주의

XSL 예:
```

<xsl:value-of select="substring-before('1999/04/01','/')" />
```


출력
```

1999
```

### 정의

XPath 1.0 4.2

### Gecko 지원

지원함.
string-length
=============

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`string-length` 함수는 인수로 준 문자열의 문자수를 반환합니다.

### 구문
```

string-length( [string] )
```

### 인수

`string`
 (선택사항)


평가할 문자열. 빼면, 쓰는 문자열은 문자열로 변환된 문맥 노드와 같습니다.

### 반환

문자열의 문자수와 같은 정수.

### 정의

XPath 1.0 4.2

### Gecko 지원

지원함.
contains
========

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`contains` 함수는 첫 번째 인수 문자열이 두 번째 인수 문자열을 포함하는지 결정하고 부울값 true 또는 false를 반환합니다.

### 문법
```

contains(haystack ,needle )
```

### 인수

`haystack`

찾을 문자열

`needle`

첫 번째 인수(`haystack`)에서 찾을 부분 문자열

### 반환

첫 번째 인수(`haystack`)가 두 번째 인수(`needle`)를 포함하면 `true`. 그렇지 않으면, `false`.

### 정의

XPath 1.0 4.2

### Gecko 지원

지원함.
count
=====

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`count` 함수는 노드 집합의 노드 수를 세고 나서 정수로 반환합니다.

### 문법
```

count(node-set )
```

### 인수

`node-set`

셀 노드 집합.

### 반환

노드 집합의 노드 수를 나타내는 정수.

### 정의

1.0 4.1

### Gecko 지원

지원함.
namespace-uri
=============

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`namespace-uri` 함수는 인수로 준 노드 집합 안 첫 노드의 이름공간 URI를 나타내는 문자열을 반환합니다.

### 구문
```

namespace-uri( [node-set] )
```

### 인수

`node-set`(선택사항)

이 노드 집합 안 첫 노드의 이름공간 URI가 반환됩니다. 이 인수를 빼면, 현재 문맥 노드를 씁니다.

### 반환

제공한 노드가 있는 이름공간 URI를 나타내는 문자열.

### 주의

* 만약 제공한 노드가 지정된 이름공간이 없으면, 반환되는 문자열은 빈 문자열입니다.
* 요소와 속성 노드 말고 다른 노드는, 반환되는 문자열이 항상 빈 문자열입니다.
### 정의

XPath 1.0 4.1

### Gecko 지원

지원함.
system-property
===============

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`system-property` 함수는 인수로 준 시스템 속성을 나타내는 개체를 반환합니다.

### 문법
```

system-property(name )
```

### 인수

*`name`*
 (선택사항)


시스템 속성의 이름. 인수는 QName인 문자열로 평가해야 합니다. QName은 식의 범위에서 이름공간 선언을 써 이름으로 확장합니다. system-property 함수는 이름으로 식별하는 시스템 속성값을 나타내는 개체를 반환합니다. 그러한 시스템 속성이 없으면, 빈 문자열을 반환합니다.

### 반환

인수 system-property를 나타내는 개체

### 주의

* xsl:version, 처리기가 구현한 XSLT 버전을 제공하는 숫자. 이 문서에서 지정한 XSLT 버전을 구현하는 XSLT 처리기에는, 이 숫자가 1.0입니다.
* xsl:vendor, XSLT 처리기의 공급자(vendor)를 식별하는 문자열
* xsl:vendor-url, XSLT 처리기의 공급자를 식별하는 URL을 포함하는 문자열. 보통 이는 공급자 웹 사이트의 홈 페이지입니다.
### 정의

XSLT 1.0 12.4

### Gecko 지원

지원함.
generate-id
===========

**XSLT/XPath 참고 문서**: XSLT 요소, XPath 함수, XPath 축

`generate-id` 함수는 제공한 노드 집합의 첫 노드를 위한 유일한 id를 만들고 그 id를 포함하는 문자열을 반환합니다.

### 문법
```

generate-id( [node-set] )
```

### 인수

`node-set`(선택사항)

id는 이 노드 집합의 첫 노드를 위해 만듭니다. 빼면, 현재 문맥 노드를 씁니다.

### 반환

만든 id를 포함하는 문자열.

### 주의

* 현재 변환에서 현재 문서의 같은 노드에는 매번 같은 id를 만들어야 합니다.
* 만든 id는 그 뒤 변환에서는 같지 않을 지도 모릅니다.

이 함수는 XPath에 더한 XSLT 고유 추가분입니다. 기본 XPath 함수 라이브러리의 일부가 아닙니다.

### 정의

XSLT 1.0 12.4

### Gecko 지원

지원함.