프론트엔드 서비스 워커 탐색: 페이지 로드 인터셉션 – 심층 분석

웹 개발 환경이 끊임없이 진화하는 가운데 빠르고 안정적이며 매력적인 사용자 경험을 제공하는 것이 가장 중요합니다. 프로그래밍 가능한 네트워크 프록시 역할을 하는 서비스 워커는 이러한 목표를 달성하기 위한 초석으로 부상했습니다. 가장 강력한 기능 중 하나는 탐색 요청을 가로채서 처리하는 기능으로, 개발자는 페이지 로드 동작을 제어하고 성능을 최적화하며 오프라인 기능을 활성화할 수 있습니다. 이 블로그 게시물에서는 서비스 워커 탐색 인터셉션의 세계를 깊이 파고들어 역학, 사용 사례 및 모범 사례를 글로벌 관점에서 살펴봅니다.

서비스 워커란 무엇입니까?

서비스 워커는 웹 페이지와 별도로 백그라운드에서 실행되는 JavaScript 파일입니다. 캐싱, 푸시 알림, 백그라운드 동기화와 같은 기능을 활성화하여 네트워크 요청을 가로채서 처리하는 프로그래밍 가능한 네트워크 프록시입니다. 웹 페이지 컨텍스트 내에서 실행되는 기존 JavaScript와 달리 서비스 워커는 사용자가 페이지에서 벗어나거나 브라우저를 닫을 때도 독립적으로 작동합니다. 이러한 지속적인 특성으로 인해 캐시된 콘텐츠 관리와 같이 지속적인 실행이 필요한 작업에 이상적입니다.

탐색 인터셉션 이해

탐색 인터셉션은 핵심적으로 서비스 워커가 페이지 탐색(예: 링크 클릭, URL 입력 또는 브라우저의 뒤로/앞으로 버튼 사용)에 의해 트리거된 요청을 가로챌 수 있는 기능입니다. 사용자가 새 페이지로 이동하면 서비스 워커는 네트워크에 도달하기 전에 요청을 가로챕니다. 이 인터셉션을 통해 서비스 워커는 다음을 수행할 수 있습니다.

• 콘텐츠 캐시 및 제공: 캐시에서 콘텐츠를 제공하여 오프라인에서도 즉시 페이지를 로드합니다.
• 요청 조작: 인증을 위한 헤더 추가 또는 URL 수정과 같이 네트워크로 전송되기 전에 요청을 수정합니다.
• 사용자 지정 응답 제공: 사용자를 다른 페이지로 리디렉션하거나 사용자 지정 오류 메시지를 표시하는 등 요청에 따라 사용자 지정 응답을 생성합니다.
• 고급 사전 페치 구현: 사용자가 특정 페이지로 이동할 때 즉시 사용할 수 있도록 리소스를 미리 로드합니다.

탐색 인터셉션의 핵심은 서비스 워커 내의 fetch 이벤트 리스너에 있습니다. 이 이벤트는 탐색 요청을 포함하여 브라우저가 네트워크 요청을 할 때마다 트리거됩니다. 이 이벤트에 이벤트 리스너를 연결하면 요청을 검사하고 처리 방법을 결정하며 응답을 반환할 수 있습니다. 요청에 따라 응답을 제어하는 기능 덕분에 서비스 워커는 매우 강력합니다.

탐색 인터셉션 작동 방식: 실제 예

간단한 예로 탐색 인터셉션을 설명해 보겠습니다. 기사 목록을 표시하는 기본 웹 애플리케이션을 상상해 보세요. 사용자가 오프라인 상태일 때도 애플리케이션을 사용할 수 있도록 하고 싶습니다. 다음은 단순화된 서비스 워커 구현입니다.

            // service-worker.js
const CACHE_NAME = 'my-site-cache-v1';
const urlsToCache = [
  '/',
  '/index.html',
  '/style.css',
  '/script.js'
];

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then((cache) => {
        console.log('Opened cache');
        return cache.addAll(urlsToCache);
      })
  );
});

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then((response) => {
        // Cache hit - return response
        if (response) {
          return response;
        }
        // Clone the request
        const fetchRequest = event.request.clone();

        return fetch(fetchRequest).then(
          (response) => {
            // Check if we received a valid response
            if (!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // Clone the response
            const responseToCache = response.clone();

            caches.open(CACHE_NAME)
              .then((cache) => {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
  );
});

            

              
                Copy
              
            
          

이 예에서:

• install 이벤트는 서비스 워커가 처음 설치될 때 필수 자산(HTML, CSS, JavaScript)을 캐시하는 데 사용됩니다.
• fetch 이벤트는 모든 네트워크 요청을 가로챕니다.
• caches.match(event.request)는 요청된 URL에 대해 캐시된 응답을 찾으려고 시도합니다.
• 캐시된 응답이 발견되면 즉시 반환되어 즉각적인 페이지 로드를 제공합니다.
• 캐시된 응답이 발견되지 않으면 네트워크에 요청이 이루어집니다. 그런 다음 응답은 나중에 사용하기 위해 캐시됩니다.

이 간단한 예는 요청을 가로채고, 캐시를 확인하고, 사용 가능한 경우 캐시된 콘텐츠를 제공하는 핵심 원칙을 보여줍니다. 이것은 오프라인 기능을 활성화하고 성능을 향상시키기 위한 기본적인 구성 요소입니다. 스트림이 소비되는 문제를 방지하기 위해 `event.request.clone()` 및 `response.clone()`이 사용되었는지 확인하십시오. 이는 캐싱이 올바르게 작동하는 데 매우 중요합니다.

고급 탐색 인터셉션 기술

기본 캐싱 전략은 좋은 시작점이지만 보다 정교한 기술은 사용자 경험을 크게 향상시킬 수 있습니다.

1. 캐시 우선, 네트워크 대체 전략

이 전략은 캐시에서 콘텐츠를 제공하는 것을 우선시하고 리소스를 사용할 수 없는 경우 네트워크로 대체합니다. 이는 성능과 데이터 최신성 간의 좋은 균형을 제공합니다. 특히 자주 변경되지 않는 자산에 유용합니다.

            
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then((response) => {
        // Cache hit - return response
        if (response) {
          return response;
        }
        return fetch(event.request)
          .then(response => {
            //Check if we received a valid response
            if (!response || response.status !== 200 || response.type !== 'basic') {
                return response;
            }
            // Clone the response to cache it
            const responseToCache = response.clone();
            caches.open('my-site-cache-v1')
            .then(cache => {
                cache.put(event.request, responseToCache)
            })
            return response;
          })
          .catch(() => {
            // Handle network errors or missing resources here.
            // Perhaps serve a custom offline page or a fallback image.
            return caches.match('/offline.html'); // Example: serve an offline page
          });
      })
  );
});

            

              
                Copy
              
            
          

이 예에서는 먼저 캐시에서 리소스를 검색하려고 시도합니다. 리소스를 찾을 수 없으면 네트워크에서 가져와 캐시하고 반환합니다. 네트워크 요청이 실패하면(예: 사용자가 오프라인 상태인 경우) 사용자 지정 오프라인 페이지로 대체하여 정상적인 저하 경험을 제공합니다.

2. 네트워크 우선, 캐시 대체 전략

이 전략은 네트워크에서 최신 콘텐츠를 제공하는 것을 우선시하고 나중에 사용할 수 있도록 응답을 캐시합니다. 네트워크를 사용할 수 없는 경우 캐시된 버전으로 대체합니다. 이 방법은 뉴스 기사 또는 소셜 미디어 피드와 같이 자주 변경되는 콘텐츠에 적합합니다.

            
self.addEventListener('fetch', (event) => {
  event.respondWith(
    fetch(event.request)
      .then(response => {
        // Check if we received a valid response
        if (!response || response.status !== 200 || response.type !== 'basic') {
            return response;
        }
        // Clone the response to cache it
        const responseToCache = response.clone();
        caches.open('my-site-cache-v1')
            .then(cache => {
                cache.put(event.request, responseToCache)
            });
        return response;
      })
      .catch(() => {
        // If the network request fails, try to serve from the cache.
        return caches.match(event.request);
      })
  );
});

            

              
                Copy
              
            
          

이 경우 코드는 먼저 네트워크에서 콘텐츠를 가져오려고 시도합니다. 네트워크 요청이 성공하면 응답이 캐시되고 원래 응답이 반환됩니다. 네트워크 요청이 실패하면(예: 사용자가 오프라인 상태인 경우) 캐시된 버전을 검색하는 것으로 대체합니다.

3. 오래된 내용 재검증 전략

이 전략은 캐시된 콘텐츠를 즉시 제공하는 동시에 백그라운드에서 캐시를 업데이트합니다. 콘텐츠를 비교적 최신 상태로 유지하면서 빠른 페이지 로드를 보장하는 강력한 기술입니다. 사용자는 즉각적인 응답성을 경험하고 캐시된 콘텐츠는 백그라운드에서 업데이트됩니다. 이 전략은 일반적으로 이미지, 글꼴 및 자주 액세스하는 데이터와 같은 자산에 사용됩니다.

            
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.open(CACHE_NAME).then(cache => {
      return cache.match(event.request).then(response => {
        // Check if we found a cached response
        const fetchPromise = fetch(event.request).then(networkResponse => {
          // If network request is successful, update the cache
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        }).catch(() => {
          // If network request fails, return null (no update)
          console.log('Network request failed for: ', event.request.url);
          return null;
        });
        return response || fetchPromise;
      });
    })
  );
});

            

              
                Copy
              
            
          

이 접근 방식을 사용하면 서비스 워커는 먼저 캐시에서 요청을 제공하려고 시도합니다. 캐시에 콘텐츠가 있는지 여부에 관계없이 서비스 워커는 네트워크에서 콘텐츠를 가져오려고 시도합니다. 네트워크 요청이 성공하면 백그라운드에서 캐시를 업데이트하여 후속 요청에 대한 최신 데이터를 제공합니다. 네트워크 요청이 실패하면 캐시된 버전이 반환되고(있는 경우), 그렇지 않으면 사용자에게 오류가 발생하거나 대체 리소스가 표시될 수 있습니다.

4. API에 대한 동적 캐싱

API를 처리할 때 요청의 URL 또는 매개변수를 기반으로 응답을 캐시해야 하는 경우가 많습니다. 이를 위해서는 캐싱에 대한 보다 동적인 접근 방식이 필요합니다.

            
self.addEventListener('fetch', (event) => {
  const requestURL = new URL(event.request.url);

  if (requestURL.pathname.startsWith('/api/')) {
    // This is an API request, so cache it dynamically.
    event.respondWith(
      caches.open('api-cache').then(cache => {
        return cache.match(event.request).then(response => {
          if (response) {
            return response;
          }
          return fetch(event.request).then(networkResponse => {
            cache.put(event.request, networkResponse.clone());
            return networkResponse;
          });
        });
      })
    );
  }
});

            

              
                Copy
              
            
          

이 예에서는 API 요청을 처리하는 방법을 보여줍니다. 요청된 URL이 /api/로 시작하는지 확인합니다. 그렇다면 전용 'api-cache'에서 응답을 검색하려고 시도합니다. 캐시된 응답을 찾을 수 없으면 네트워크에서 콘텐츠를 가져와 캐시하고 응답을 반환합니다. 이 동적 접근 방식은 API 응답을 효율적으로 관리하는 데 매우 중요합니다.

오프라인 기능 구현

탐색 인터셉션의 가장 중요한 이점 중 하나는 완전히 작동하는 오프라인 환경을 만들 수 있다는 것입니다. 사용자가 오프라인 상태일 때 서비스 워커는 캐시된 콘텐츠를 제공하여 인터넷 연결 없이도 주요 기능 및 정보에 액세스할 수 있습니다. 이는 신뢰할 수 없는 인터넷 액세스 지역이나 이동이 잦은 사용자에게 특히 중요할 수 있습니다. 예를 들어 여행 앱은 지도 및 목적지 정보를 캐시할 수 있고 뉴스 앱은 최근 기사를 저장할 수 있습니다. 이는 인도 농촌 지역이나 아마존 열대 우림의 외딴 지역과 같이 인터넷 액세스가 제한된 지역의 사용자에게 특히 유용합니다.

오프라인 기능을 구현하려면 캐시할 리소스를 신중하게 고려해야 합니다. 여기에는 다음이 포함되는 경우가 많습니다.

• 필수 HTML, CSS 및 JavaScript 파일: 이는 애플리케이션의 핵심 구조 및 스타일을 형성합니다.
• 주요 이미지 및 아이콘: 이는 애플리케이션의 시각적 매력과 유용성을 향상시킵니다.
• 자주 액세스하는 데이터: 여기에는 기사, 제품 정보 또는 기타 관련 콘텐츠가 포함될 수 있습니다.
• 오프라인 페이지: 사용자가 오프라인 상태일 때 표시할 사용자 지정 페이지로, 유용한 메시지를 제공하고 사용자를 안내합니다.

사용자 경험을 고려하십시오. 콘텐츠가 캐시에서 제공되는 경우 사용자에게 명확한 지표를 제공합니다. 사용자가 다시 온라인 상태일 때 캐시된 콘텐츠를 새로 고치거나 업데이트하는 옵션을 제공합니다. 오프라인 환경은 원활하고 직관적이어야 하며 사용자가 인터넷 연결 상태에 관계없이 애플리케이션을 효과적으로 계속 사용할 수 있도록 보장해야 합니다. 빠른 광대역에서 느리고 불안정한 연결에 이르기까지 다양한 네트워크 조건에서 오프라인 기능을 철저히 테스트하십시오.

서비스 워커 탐색 인터셉션에 대한 모범 사례

효율적이고 안정적인 탐색 인터셉션을 보장하려면 다음 모범 사례를 고려하십시오.

1. 신중한 캐싱 전략 선택

제공하는 콘텐츠 유형에 따라 적절한 캐싱 전략을 선택하십시오. 위에서 설명한 전략에는 각각 장단점이 있습니다. 콘텐츠의 특성을 이해하고 가장 적합한 접근 방식을 선택하십시오. 예를 들어 "캐시 우선" 전략은 CSS, JavaScript 및 이미지와 같은 정적 자산에 적합할 수 있지만 "네트워크 우선" 또는 "오래된 내용 재검증" 전략은 API 응답 또는 동적 데이터와 같이 자주 업데이트되는 콘텐츠에 더 적합할 수 있습니다. 다양한 시나리오에서 전략을 테스트하는 것이 중요합니다.

2. 버전 관리 및 캐시 관리

업데이트를 처리하고 사용자가 항상 최신 콘텐츠에 액세스할 수 있도록 캐시에 대한 적절한 버전 관리를 구현하십시오. 애플리케이션의 자산을 수정할 때마다 캐시 버전 이름(예: `my-site-cache-v1`, `my-site-cache-v2`)을 늘립니다. 이렇게 하면 서비스 워커가 새 캐시를 만들고 캐시된 리소스를 업데이트합니다. 새 캐시가 생성된 후에는 스토리지 문제를 방지하고 새 버전을 사용하도록 오래된 캐시를 삭제하는 것이 필수적입니다. 'cache-name' 접근 방식을 사용하여 캐시를 버전 관리하고 설치 프로세스 중에 오래된 캐시를 정리하십시오.

            
const CACHE_NAME = 'my-site-cache-v2'; // Increment the version!
const urlsToCache = [
  '/',
  '/index.html',
  '/style.css',
  '/script.js'
];

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then((cache) => {
        console.log('Opened cache');
        return cache.addAll(urlsToCache);
      })
  );
});

self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.filter(cacheName => {
          return cacheName != CACHE_NAME;
        }).map(cacheName => {
          return caches.delete(cacheName);
        })
      );
    })
  );
});

            

              
                Copy
              
            
          

`activate` 이벤트는 오래된 캐시를 정리하여 사용자의 스토리지를 관리하기 쉽도록 유지하는 데 사용됩니다. 이렇게 하면 사용자가 항상 최신 콘텐츠에 액세스할 수 있습니다.

3. 효율적인 리소스 캐싱

캐시할 리소스를 신중하게 선택하십시오. 모든 것을 캐시하면 성능 문제가 발생하고 스토리지 사용량이 증가할 수 있습니다. 애플리케이션의 핵심 기능에 필수적이고 자주 액세스하는 콘텐츠인 중요한 리소스를 캐시하는 데 우선 순위를 두십시오. Lighthouse 또는 WebPageTest와 같은 도구를 사용하여 사이트의 성능을 분석하고 최적화 기회를 식별하십시오. 웹용 이미지를 최적화하고 적절한 캐싱 헤더를 사용하여 서비스 워커의 효율성을 개선하십시오.

4. 반응형 디자인 및 적응성

애플리케이션이 반응형이고 다양한 화면 크기 및 장치에 적응하는지 확인하십시오. 이는 다양한 플랫폼에서 일관된 사용자 경험을 제공하는 데 매우 중요합니다. 상대 단위, 유연한 레이아웃 및 미디어 쿼리를 사용하여 원활하게 적응하는 디자인을 만드십시오. 다양한 언어, 읽기 방향(예: 아랍어 또는 히브리어의 경우 RTL) 및 문화적 선호도를 지원하여 글로벌 사용자를 위한 접근성 영향을 고려하십시오.

5. 오류 처리 및 대체

네트워크 오류 및 기타 예기치 않은 상황을 정상적으로 처리할 수 있도록 강력한 오류 처리를 구현하십시오. 사용자 경험이 중단되지 않도록 유용한 오류 메시지 및 대체 메커니즘을 제공하십시오. 네트워크 오류가 발생한 경우 사용자 지정 오프라인 페이지 또는 유용한 메시지를 표시하는 것을 고려하십시오. 사용자가 연결을 다시 얻으면 요청을 다시 시도하거나 캐시된 콘텐츠를 새로 고치는 메커니즘을 제공하십시오. 전체 네트워크 중단, 느린 연결 및 간헐적인 연결을 포함하여 다양한 네트워크 조건에서 오류 처리를 테스트하십시오.

6. 안전한 서비스 워커

서비스 워커는 올바르게 구현되지 않으면 보안 취약점을 도입할 수 있습니다. 중간자 공격을 방지하려면 항상 HTTPS를 통해 서비스 워커 스크립트를 제공하십시오. 서비스 워커에서 캐시하거나 조작하는 모든 데이터를 신중하게 검증하고 삭제하십시오. 잠재적인 보안 문제가 있는지 서비스 워커 코드를 정기적으로 검토하십시오. 서비스 워커가 올바르게 등록되었고 범위가 의도한 출처로 제한되었는지 확인하십시오.

7. 사용자 경험 고려 사항

오프라인 기능을 염두에 두고 사용자 경험을 디자인하십시오. 애플리케이션이 오프라인 상태이고 콘텐츠가 캐시에서 제공되는 시기를 나타내는 시각적 신호를 제공하십시오. 사용자가 캐시된 콘텐츠를 새로 고치거나 데이터를 수동으로 동기화할 수 있는 옵션을 제공하십시오. 대용량 파일 또는 멀티미디어 콘텐츠를 캐시할 때 사용자의 대역폭 및 데이터 사용량을 고려하십시오. 오프라인 콘텐츠를 관리하기 위한 명확하고 직관적인 사용자 인터페이스를 보장하십시오.

8. 테스트 및 디버깅

다양한 장치 및 브라우저에서 서비스 워커 구현을 철저히 테스트하십시오. 브라우저 개발자 도구를 사용하여 서비스 워커의 동작을 검사하고, 캐시 콘텐츠를 확인하고, 문제를 디버그하십시오. Lighthouse와 같은 도구를 사용하여 애플리케이션의 성능을 평가하고 개선할 영역을 식별하십시오. 오프라인 환경을 테스트하기 위해 다양한 네트워크 조건(예: 오프라인 모드, 느린 3G)을 시뮬레이션하십시오. 호환성 및 안정성을 보장하기 위해 서비스 워커를 정기적으로 업데이트하고 다양한 브라우저 및 장치에서 테스트하십시오. 인터넷 속도와 안정성이 크게 다를 수 있으므로 다양한 지역과 다양한 네트워크 조건에서 테스트하십시오.

탐색 인터셉션의 이점

서비스 워커 탐색 인터셉션을 구현하면 다음과 같은 많은 이점이 있습니다.

• 성능 향상: 캐시된 콘텐츠는 페이지 로드 시간을 크게 단축하여 보다 응답성이 뛰어난 사용자 경험을 제공합니다.
• 오프라인 기능: 사용자는 인터넷 연결 없이도 주요 기능 및 정보에 액세스할 수 있습니다. 이는 신뢰할 수 없는 인터넷이 있거나 이동 중인 사용자에게 특히 유용합니다.
• 네트워크 사용량 감소: 캐시에서 콘텐츠를 제공하여 네트워크 요청 수를 줄여 대역폭을 절약하고 성능을 향상시킵니다.
• 향상된 안정성: 애플리케이션이 네트워크 오류에 더 탄력적으로 대처합니다. 사용자는 일시적인 중단 중에도 애플리케이션을 계속 사용할 수 있습니다.
• 프로그레시브 웹 앱(PWA) 기능: 서비스 워커는 PWA의 핵심 구성 요소로, 기본 앱과 같은 느낌과 동작을 제공하는 웹 애플리케이션을 만들 수 있습니다.

글로벌 영향 및 고려 사항

탐색 인터셉션을 염두에 두고 서비스 워커를 개발할 때 다양한 글로벌 환경을 고려하는 것이 중요합니다.

• 인터넷 연결: 인터넷 속도와 가용성은 국가 및 지역에 따라 크게 다릅니다. 느리거나 불안정한 연결이 있는 지역 또는 연결이 전혀 없는 지역에서도 효과적으로 작동하도록 애플리케이션을 설계하십시오. 다양한 네트워크 조건에 맞게 최적화하십시오. 제한적이거나 비싼 데이터 요금제를 사용하는 지역의 사용자 경험을 고려하십시오.
• 장치 다양성: 전 세계 사용자는 고급 스마트폰에서 구형 저전력 장치에 이르기까지 광범위한 장치를 통해 웹에 액세스합니다. 서비스 워커 구현이 모든 장치에서 성능에 최적화되었는지 확인하십시오.
• 언어 및 현지화: 여러 언어 및 현지화된 콘텐츠를 지원하도록 애플리케이션을 설계하십시오. 서비스 워커를 사용하여 사용자의 기본 설정에 따라 콘텐츠의 다양한 언어 버전을 동적으로 제공할 수 있습니다.
• 접근성: 장애가 있는 사용자가 애플리케이션에 액세스할 수 있는지 확인하십시오. 의미론적 HTML을 사용하고 이미지에 대한 대체 텍스트를 제공하고 애플리케이션이 키보드로 탐색할 수 있는지 확인하십시오. 보조 기술로 애플리케이션을 테스트하십시오.
• 문화적 감수성: 문화적 차이와 선호도를 염두에 두십시오. 문화적으로 민감하지 않은 언어 또는 이미지를 사용하지 마십시오. 대상 청중에 맞게 콘텐츠를 현지화하십시오.
• 법률 및 규정 준수: 데이터 개인 정보 보호, 보안 및 콘텐츠와 관련된 지역 법률 및 규정을 인식하십시오. 애플리케이션이 모든 해당 법률 및 규정을 준수하는지 확인하십시오.

결론

서비스 워커 탐색 인터셉션은 웹 애플리케이션 성능, 안정성 및 사용자 경험을 크게 향상시키는 강력한 기술입니다. 페이지 로드 요청을 신중하게 관리하고, 자산을 캐시하고, 오프라인 기능을 활성화함으로써 개발자는 글로벌 청중에게 매력적이고 성능이 뛰어난 웹 애플리케이션을 제공할 수 있습니다. 모범 사례를 수용하고, 글로벌 환경을 고려하고, 사용자 경험을 우선시함으로써 개발자는 서비스 워커의 모든 잠재력을 활용하여 위치나 인터넷 연결에 관계없이 진정으로 뛰어난 웹 애플리케이션을 만들 수 있습니다. 웹이 계속 발전함에 따라 서비스 워커를 이해하고 활용하는 것은 앞서 나가고 가능한 최상의 사용자 경험을 제공하는 데 필수적입니다.