(performance_overview)=

# 성능

Wagtail은 편집기 인터페이스와 프론트엔드 모두에서 속도를 고려하여 설계되었습니다. 하지만 더 나은 성능을 원하거나 매우 많은 양의 트래픽을 처리해야 하는 경우, 설치 환경에서 최대한의 성능을 끌어내는 몇 가지 팁을 소개합니다.

Wagtail의 작동하는 설치를 위해 외부 종속성을 최소화하여 가능한 한 간단하게 시작할 수 있도록 노력했습니다. 그러나 더 나은 성능을 위해 구성할 수 있는 여러 기본 설정이 있습니다:

## 캐시

빠르고 영속적인 캐시로 [Redis](https://redis.io/)를 권장합니다. 패키지 관리자를 통해 Redis를 설치하고(Debian 또는 Ubuntu: `sudo apt-get install redis-server`), `requirements.txt` 에 `django-redis` 를 추가한 다음, 캐시 백엔드로 활성화하세요:

```python
CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/dbname',
        # for django-redis < 3.8.0, use:
        # 'LOCATION': '127.0.0.1:6379',
        'OPTIONS': {
            'CLIENT_CLASS': 'django_redis.client.DefaultClient',
        }
    }
}
```

(custom_image_renditions_cache)=

[이미지 렌디션 캐싱](caching_image_renditions)을 위해 다른 캐시 백엔드를 사용하려면 "renditions" 백엔드를 구성하세요:

```python
CACHES = {
    'default': {...},
    'renditions': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211',
        'TIMEOUT': 600,
        'OPTIONS': {
            'MAX_ENTRIES': 1000
        }
    }
}
```

## 이미지 URL

메타 태그나 다른 태그 속성에서 사용하기 위해 이미지 URL만 필요한 경우, 이미지 제공 뷰와 `{% image_url %}` 태그를 사용하는 것이 더 효율적일 수 있습니다:

```html+django
<meta property="og:image" content="{% image_url page.hero_image width-600 %}" />
```

페이지 요청 시 렌디션을 찾거나 생성하는 대신, 이미지 제공 뷰는 이 작업을 별도의 뷰로 오프로드합니다. 이 뷰는 사용자가 이미지를 요청할 때만 렌디션을 생성합니다(또는 이미 존재하는 경우 기존 렌디션을 반환). 이를 통해 이미지가 많은 페이지의 로딩 속도를 크게 향상시킬 수 있습니다. 외부 스토리지 백엔드(예: Amazon S3)를 사용하는 경우 Wagtail이 처리하는 요청 수가 증가할 수 있습니다.

또 다른 부수적인 이점은 변환 중 발생하는 오류로 인해 페이지 오류가 발생하는 것을 방지한다는 것입니다. 이미지가 너무 커서 Willow가 처리할 수 없는 경우([`WAGTAILIMAGES_MAX_IMAGE_PIXELS`](wagtailimages_max_image_pixels)로 이미지 크기를 제한할 수 있음), Willow가 충돌할 수 있습니다. 리사이즈가 페이지 로드 외부에서 수행되므로 이미지는 누락되지만 나머지 페이지 콘텐츠는 그대로 유지됩니다.

Python에서는 [`generate_image_url`](dynamic_image_urls)을 사용하여 동일한 결과를 얻을 수 있습니다.

## 이미지 렌디션 프리페치

쿼리셋을 사용하여 이미지 목록이나 이미지가 포함된 객체 목록을 렌더링할 때, 단일 추가 쿼리로 필요한 [렌디션을 프리페치](prefetching_image_renditions)할 수 있습니다. 항목 목록이 길거나 각 항목에 여러 렌디션이 사용되는 경우, 이는 성능을 크게 향상시킬 수 있습니다.

(performance_frontend_caching)=

## 프론트엔드 캐싱 프록시

많은 웹사이트는 [Varnish](https://varnish-cache.org/), [Squid](http://www.squid-cache.org/), [Cloudflare](https://www.cloudflare.com/) 또는 [CloudFront](https://aws.amazon.com/cloudfront/)와 같은 프론트엔드 캐시를 사용하여 많은 양의 트래픽을 우수한 응답 시간으로 지원합니다. 하지만 프론트엔드 캐시 사용의 단점은 콘텐츠 업데이트에 잘 반응하지 않아 업데이트된 후에도 종종 이전 버전의 페이지를 캐시된 상태로 유지한다는 것입니다.

Wagtail은 많은 CDN과 [통합](frontend_cache_purging)을 지원하므로 페이지가 변경될 때 이를 알려 캐시를 즉시 지우고 사용자가 변경 사항을 더 빨리 볼 수 있도록 할 수 있습니다.

여러 프론트엔드가 구성된 경우(예: 한 사이트에는 Cloudflare, 다른 사이트에는 CloudFront), 불필요한 추가 퍼지 요청을 방지하기 위해 [`HOSTNAMES`](frontendcache_multiple_backends) 키를 백엔드가 퍼지할 수 있는 호스트 이름 목록으로 설정하는 것이 좋습니다.

(performance_page_urls)=

## 페이지 URL

페이지의 URL을 완전히 확인하기 위해 Wagtail은 몇 가지 다른 소스의 정보가 필요합니다.

`Page.get_url` 및 `Page.get_full_url` 과 같이 `Page` 의 URL을 가져오는 데 사용되는 메서드는 `request` 및 `current_site` 에 대한 추가 인수를 선택적으로 허용합니다. 이러한 인수를 전달하면 기본 사이트 수준 URL 정보의 상당 부분을 현재 요청에 재사용할 수 있습니다. 탐색 메뉴 생성과 같은 상황이나 페이지 콘텐츠에 나타나는 모든 링크에서 `request` 또는 `current_site` 를 제공하면 사이트가 특정 페이지 로드에 대해 생성하는 캐시 또는 데이터베이스 쿼리 수를 크게 줄일 수 있습니다.

[`{% pageurl %}`](pageurl_tag) 또는 [`{% fullpageurl %}`](fullpageurl_tag) 템플릿 태그를 사용할 때 요청이 자동으로 전달되므로 추가 최적화가 필요하지 않습니다.

## 검색

Wagtail은 편집기 인터페이스와 사이트 사용자 모두를 위해 [Elasticsearch](https://www.elastic.co)를 강력하게 지원하지만, Elasticsearch가 없는 경우 데이터베이스 검색으로 대체할 수 있습니다. Elasticsearch는 텍스트 검색에 있어 Django ORM보다 빠르고 강력하므로 설치하거나 [Searchly](http://www.searchly.com/)와 같은 호스팅 서비스를 사용하는 것이 좋습니다.

Wagtail을 Elasticsearch용으로 구성하는 방법에 대한 자세한 내용은 [](wagtailsearch_backends_elasticsearch)를 참조하세요.

## 데이터베이스

Wagtail은 PostgreSQL, SQLite, MySQL 및 MariaDB에서 테스트되었습니다. 일부 타사 데이터베이스 백엔드에서도 작동할 수 있지만 보장되지는 않습니다.

프로덕션 환경에서는 PostgreSQL을 권장하지만, 데이터베이스 선택은 궁극적으로 개인적 선호도, 팀 전문성, 특정 프로젝트 요구 사항 등 여러 요인의 조합에 따라 달라집니다. 가장 중요한 점은 선택한 데이터베이스가 프로젝트의 성능 및 확장성 요구 사항을 충족할 수 있도록 하는 것입니다.

### 이미지 속성

일부 이미지의 경우, 나머지 페이지가 계속 로드될 수 있도록 이미지를 지연 로딩(lazy load)하는 것이 유용할 수 있습니다. 이는 사이트 전체 [](adding_default_attributes_to_images) 또는 이미지별 [](image_tag_alt)로 구성할 수 있습니다. 자세한 내용은 [`loading='lazy'` 속성](https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading#images_and_iframes) 및 [`'decoding='async'` 속성](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-decoding)에 대한 설명이나 [이미지 지연 로딩에 대한 web.dev 기사](https://web.dev/lazy-loading-images/)를 참조하세요.

이 최적화는 관리자 사이트의 이미지에 대해 이미 처리되어 있습니다.

## 템플릿 조각 캐싱

Django는 템플릿의 일부를 캐싱할 수 있는 [템플릿 조각 캐싱](<inv:django:std:label#topics/cache:template fragment caching>)을 지원합니다. Django의 `{% cache %}` 태그를 Wagtail과 함께 기본적으로 사용하면 미리보기 콘텐츠가 최종 사용자에게 표시될 수 있어 [위험](https://github.com/wagtail/wagtail/issues/5074)할 수 있습니다. 대신, Wagtail은 이러한 문제를 모두 피하는 두 가지 추가 템플릿 태그인 [`{% wagtailcache %}`](wagtailcache)와 [`{% wagtailpagecache %}`](wagtailpagecache)를 제공합니다.

(page_cache_key)=

## 페이지 캐시 키

특정 값이 아닌 전체 페이지를 기반으로 값을 캐시해야 하는 경우가 많습니다. 이를 위해 {attr}`~wagtail.models.Page.cache_key` 를 사용하여 페이지 상태에 대한 고유한 값을 얻을 수 있습니다. 페이지에 대한 무언가가 변경되면 캐시 키도 변경됩니다. Django의 캐싱 프레임워크를 직접 사용할 때 이 값을 사용하여 더 길고 구체적인 캐시 키를 만들 수도 있습니다. 예를 들면 다음과 같습니다.

```python
from django.core.cache import cache

result = page.expensive_operation()
cache.set("expensive_result_" + page.cache_key, result, 3600)

# Later...
cache.get("expensive_result_" + page.cache_key)
```

사용자 정의 모델 필드 값을 포함하는 등 캐시 키를 수정하려면 {attr}`~wagtail.models.Page.get_cache_key_components` 를 재정의할 수 있습니다.

```python
def get_cache_key_components(self):
    components = super().get_cache_key_components()
    components.append(self.external_slug)
    return components
```

기본 구성 요소 필드 값이 직접 수정되지 않는 한, 페이지를 수동으로 업데이트해도 캐시 키가 변경되지 않을 수 있습니다. 캐시 키 값의 변경을 확인하려면 변경 사항을 `Revision` 에 저장한 다음 게시해 보세요.

## Django

Wagtail은 Django를 기반으로 구축되었습니다. Django에서 제시하는 많은 [성능 팁](inv:django#topics/performance)이 Wagtail에도 적용됩니다.