요약: 확장 프로그램 API는 뒤로-앞으로 캐시를 지원하도록 업데이트되었습니다. 탐색을 미리 로드합니다. 자세한 내용은 아래를 참조하세요.
Chrome은 빠른 탐색을 위해 노력해 왔습니다. 빠른 탐색 뒤로-앞으로 캐시 등의 기술을 (데스크톱 발송 기간: Chrome 96) 및 추측 규칙 (Chrome 103에서 출시됨) 이전 버전과의 비교가 모두 개선되었습니다. 경험해 볼 수 있습니다 이 게시물에서는 브라우저 업데이트와 확장 API를 사용하여 이러한 새 워크플로를 수용할 수 있습니다.
페이지 유형 이해하기
뒤로-앞으로 캐시와 사전 렌더링을 사용하기 전에 탭에 활성 페이지가 하나만 있었습니다. 항상 보이는 것이었습니다. 만약 사용자가 이전 페이지로 돌아가면 활성 페이지가 삭제됩니다 (페이지 B). 역사의 이전 페이지는 완전히 재구성됩니다 (페이지 A). 확장 프로그램은 수명 주기 페이지의 어느 부분이 활성/표시 상태의 탭이 하나뿐이었기 때문입니다.
<ph type="x-smartling-placeholder">
뒤로-앞으로 캐시와 사전 렌더링을 사용하면 더 이상 일대일이 불가능합니다. 탭과 페이지의 관계를 볼 수 있습니다. 이제 각 탭에는 여러 개의 페이지 및 페이지가 제거되지 않고 상태 간에 있습니다.
예를 들어, 페이지는 사전 렌더링된 (보이지 않는) 페이지로 수명을 시작할 수 있습니다. 사용자가 링크를 클릭할 때 표시되는 활성 페이지로 전환된 후 사용자가 다른 페이지로 이동할 때 뒤로-앞으로 캐시 (표시되지 않음)에 다른 페이지로 이동할 수 있습니다. 이 도움말의 후반부 새로운 속성을 살펴보고 확장 프로그램이 확인할 수 있습니다
<ph type="x-smartling-placeholder">
탭은 하나가 아니라 사전 렌더링된 일련의 페이지, 활성 (표시) 페이지, 일련의 뒤로-앞으로 캐시 페이지가 포함됩니다.
확장 프로그램 개발자에게 어떤 변화가 있나요?
프레임 ID == 0
Chromium에서는 최상위/기본 프레임을 가장 바깥쪽 프레임이라고 합니다.
frameId를 가정하는 확장 프로그램 작성자
0 (이전 권장사항)이면 문제가 있을 수 있습니다.
이제 탭에는 가장 바깥쪽에 있는 여러 프레임 (사전 렌더링 및 캐시된 프레임)이 있을 수 있으므로
가장 바깥쪽 단일 레이어가 있다는 가정하에
잘못된 프레임입니다. frameId == 0은(는) 계속하여
활성 페이지의 가장 바깥쪽 프레임이지만 페이지의 가장 바깥쪽 프레임은
같은 탭에 있는 다른 페이지는 0이 아닙니다. 새로운 frameType 필드는
이 문제를 해결하기 위해 추가되었습니다. '프레임이 가장 바깥쪽 프레임인지 어떻게 결정하나요?' 도움말을 참고하세요.
섹션을 참조하세요.
프레임 및 문서의 수명 주기
확장에 문제가 있는 또 다른 개념은 있습니다. 프레임은 커밋된 URL과 연결된 문서를 호스팅합니다. 문서는 예를 들어 탐색을 통해 변경될 수 있지만 frameId는 변경되지 않습니다. 따라서 특정 문서에서 일어난 일을 그것과 연관시키기가 어렵습니다. frameIds만 사용합니다. documentId 개념이 도입됩니다. 고유 식별자로 사용됩니다. 프레임이 탐색되고 새 문서가 열립니다. 이 필드는 페이지가 수명 주기 상태를 변경하는 시점( prerender/active/cached)를 동일하게 유지할 수 있습니다.
웹 탐색 이벤트
chrome.webNavigation 네임스페이스의 이벤트
여러 번 발생할 수 있는
동일한 페이지를 표시할 수 있습니다 자세한 내용은
“페이지가 어떤 수명 주기에 속해 있는지 어떻게 알 수 있나요?”
및 '페이지 전환 시점은 어떻게 결정하나요?' 섹션에 나와 있습니다.
페이지의 수명 주기를 어떻게 알 수 있나요?
DocumentLifecycle
유형이 frameId가
사용할 수 있습니다 이벤트에 DocumentLifecycle 유형이 있는 경우
(예: onCommitted)
값은 이벤트가 생성된 상태입니다. 언제든지 쿼리하거나
WebNavigation getFrame()의 정보
및 getAllFrames()
메서드를 사용할 수 있지만 항상 이벤트의 값을 사용하는 것이 좋습니다. 만약
두 메서드 모두 이벤트가 호출될 때까지 프레임의 상태가 변경될 수 있음을 인식해야 합니다.
두 메서드 모두에 의해 프로미스 반환이 확인될 때 생성됩니다.
DocumentLifecycle
다음 값을 갖습니다.
"prerender" : 현재 사용자에게 표시되지 않지만 사용자에게 표시될 준비를 하고 있습니다."active": 사용자에게 현재 표시됩니다."cached": 뒤로-앞으로 캐시에 저장됩니다."pending_deletion": 문서가 폐기됩니다.
프레임이 가장 바깥쪽 프레임인지 어떻게 알 수 있나요?
이전에는 확장 프로그램에서 frameId == 0를 통해
발생하는 이벤트가 가장 바깥쪽 프레임에 대한 것인지 여부를 나타냅니다. 여러 페이지 포함
이제 가장 바깥쪽에 여러 프레임이 있으므로 frameId의 정의는
문제가 있습니다 캐시된 뒤로-앞으로 관련 이벤트를 수신하지 않습니다.
있습니다. 그러나 사전 렌더링된 프레임의 경우 frameId은
0이 아닌 값을 가질 수 있습니다. 따라서 frameId == 0를
가장 바깥쪽 프레임인지 확인합니다.
이를 돕기 위해 우리는
FrameType 드림
따라서 프레임이 실제로 가장 바깥쪽 프레임인지 쉽게 확인할 수 있습니다.
FrameType의 값은 다음과 같습니다.
"outermost_frame": 일반적으로 최상위 프레임이라고 합니다. 참고: 여러 가지가 있습니다 예를 들어 사전 렌더링 및 캐시된 각 페이지에는 최상위 프레임이라고 할 수 있는 가장 바깥쪽에 있는 프레임이 있습니다."fenced_frame": 나중에 사용하기 위해 예약되어 있습니다."sub_frame": 일반적으로 iframe입니다.
DocumentLifecycle와 FrameType를 결합하여 프레임이
가장 바깥쪽에 있는 활성 프레임을 생성합니다. 예:
tab.documentLifecycle === “active” && frameType === “outermost_frame”
프레임의 사용 시간 문제를 해결하려면 어떻게 해야 하나요?
위에서 언급했듯이 프레임은 문서를 호스팅하며 프레임은 새로운
frameId는 변경되지 않습니다. 이렇게 하면
frameId만 있는 이벤트를 수신합니다. URL을 조회하는 경우
이벤트가 발생한 시점과 다를 수 있으므로 이를
사용 시간 문제입니다.
이 문제를 해결하기 위해 documentId를 도입했습니다.
(및 parentDocumentId)
webNavigation.getFrame()
메서드는 이제 documentId가 제공되는 경우 frameId을 선택사항입니다. 이
documentId는 프레임을 이동할 때마다 변경됩니다.
페이지가 전환되는 시점을 어떻게 결정하나요?
페이지가 상태 간에 전환될 때를 판단하기 위한 명시적인 신호가 있습니다.
WebNavigation 이벤트를 살펴보겠습니다.
페이지를 처음 탐색하면 4개의 이벤트가 순서대로 표시됩니다.
참조하세요. 이 네 가지 이벤트는
DocumentLifecycle 상태는 "prerender" 또는 "active"입니다.
onBeforeNavigate
onCommitted
onDOMContentLoaded
onCompleted
이 내용은 아래 다이어그램에서 확인할 수 있으며 documentId
사전 렌더링된 페이지가 활성 페이지가 되면 "xyz"로 변경됩니다.
documentId
있습니다.페이지가 뒤로-앞으로 캐시에서 또는
활성 상태에 이벤트가 3개 더 있습니다 (그러나 DocumentLifecyle가
"active").
onBeforeNavigate
onCommitted
onCompleted
documentId는 원래 이벤트와 동일하게 유지됩니다. 이것은
documentId == xyz가 활성화될 때 위 그림과 같습니다. Note that the
onDOMContentLoaded를 제외하고 동일한 탐색 이벤트가 실행됩니다.
페이지가 이미 로드되었기 때문입니다.
의견이나 질문이 있으신 경우 언제든지 chromium-extensions 그룹