iframe 태그는 웹 페이지에 내장 된 프레임을 만들 수 있으며 SRC 속성을 지정하여 다른 웹 페이지 문서의 내용을 호출합니다. 프레임 세트와 마찬가지로 웹 페이지 구조를 분할하여 웹 페이지의 일부를 공개적으로 유지하는 데 사용되지만 전체 웹 페이지를 분할하는 프레임 세트의 프레임 워크 구조와 비교할 때 iframes는 더 유연하며 웹 페이지의 어느 곳에서나 내장 할 수 있습니다. Iframe 사용의 기능으로 인해 일부 웹 페이지에서 널리 사용되었으며, 이로 인해 부적절한 학대가 발생했습니다. 웹 디자인은 iframe 웹 요소를 사용하는 몇 가지 일반적인 방법을 분석합니다.
- 비동기 데이터 교환을위한 솔루션으로 새로 고침 응답 페이지 구성 요소를 작성합니다. 이것은 초기에 Ajax를 사용하지 않고 비동기 적으로 요청을 보내는 대안적인 방법입니다. 페이지에서 보이지 않는 iframe 요소를 설정하고 요청을 전송 해야하는 페이지 주소로 SRC 속성을 지적하면 요청을 보낼 수 있습니다. 동일한 도메인에서 반환 된 페이지는 데이터를 얻기 위해 구문 분석 할 수 있습니다. 또 다른 장점은 AJAX의 샌드 박스 보안 모델을 우회하고 데이터를 얻기 위해 크로스 도메인 요청을 성공적으로 보낼 수 있다는 것입니다. 그러나이 경우 IFRAME의 문서 개체를 검색 할 수 없습니다. 그 특성으로 인해 크로스 도메인 요청이 필요한 일부 웹 페이지에는 여전히 적용됩니다. 이러한 종류의 새로 고침은 데이터 교환 프로세스 중에 상위 페이지가 새로 고침되지 않으며 사용자 작업에 계속 응답한다는 것을 의미합니다. 실제 데이터 교환은 부모 페이지에 포함 된 iframe 페이지에 의해 잠겨 있습니다. 이 임베디드 iframe 페이지는 필요에 따라 표시되거나 보이지 않도록 설정할 수 있으며 부모 페이지의 다른 요소의 응답에는 사용자에게 영향을 미치지 않습니다. 이 효과는 Ajax의 새로 고침과 유사하지만 그 메커니즘이 완전히 다르다는 것을 알 수 있습니다. Gmail은 AJAX 응용 프로그램의 모델이지만 많은 IFRAME를 결합하여 우수한 성능과 사용자 경험을 달성합니다.
- 페이지를 최적화하는 방법. iframes를 사용하여 스크립트를 병렬로드하여 아이콘 및 광고와 같은 느린로드 타사 콘텐츠의로드 문제를 해결하십시오. Google의 광고 플랫폼 Adsense는 Iframe을 사용하여 사용자 웹 사이트에서 수익을 공유하는 것을 의미합니다. 또한 국내 포털의 홈페이지에서 광고 코드를보고 분석하여 이러한 종류의 기술을 볼 수 있습니다. 네트워크가 낮은 네트워크 압력하에있을 때 숨겨진 Iframe을 사용하여 더 큰 파일을 캐시에 예압하여 다른 페이지에서 사용할 수 있습니다. 예압의 개념은 Google 홈페이지 용 Firebug를 사용하여 분석 할 수 있습니다. 바디 태그에서 볼 수 있습니다.
onload = document.fqfocus (); if (document.images) new image (). src = '/images/nav_logo4.png'
이러한 코드를 사용하면로드 된 이미지 Nav_Logo4.png는 홈페이지에서 사용되지 않지만 검색 결과 목록과 같은 다른 페이지 에서이 이미지를 사용하면 캐시에서만 읽어야하며 다시 다운로드 할 필요가 없습니다.
- IE6 브라우저의 플로팅 레이어에 대한 해킹 방법으로서 선택 제어 및 플래시 요소를 차단합니다. Web2.0 시대에 Lightbox (또는 Thickbox) 기술은 좋은 경험과 신선한 시각적 경험으로 인기있는 효과가되었습니다. 이 기술은 실제로 절대적으로 배치 된 플로팅 레이어를 사용하여 원본 페이지를 다루기 위해 텍스트 정보, 그림, 양식 또는 기타 임의의 페이지 요소를 제시하여 브라우저 또는 브라우저의 자체 메시지 및 입력 컨트롤이 종종 사용자와 상호 작용하는 데 사용되는 초기 웹 개발 방식을 대체합니다. 구식으로, 새로운 Windows를 팝업하는 스크립트는 종종 브라우저의 광고 차단 시스템에 의해 가로 채며 브라우저의 자체 메시지 컨트롤은 브라우저의 프로세스를 방해하여 전체 페이지가 잠겨있는 여러 태그를 통해 눈썹을 깎아 내고 다른 웹 페이지가 브라우징하기 때문에 사용자 경험 연구원에 의해 비판됩니다. 자신에 대한 엄격한 요구 사항을 가진 최전선 웹 프론트 엔드 개발자로서 Lightbox 효과를 구현하는 과정 에서이 문제를 확실히 발생시킬 것입니다. 절대 포지셔닝 레이어는 IE6의 웹 페이지에서 일부 컨트롤 및 플래시를 다룰 수 없으며 스타일이 더 높은 z-index 값으로 설정 되더라도 쓸모가 없습니다. 선택 요소는 IE6의 양식 수준 요소이며 우선 순위는 다른 모든 HTML 태그보다 훨씬 높기 때문입니다. 동일한 양식 수준의 IFRAME만이 커버 할 수 있습니다. 따라서 개발자들은 플로팅 레이어를 IFRAME에 넣거나 부동 층에 Iframe을 배치하면이 문제를 해결할 수 있음을 발견했습니다. 다행 스럽게도이 문제는 IE6 이후 IE 업그레이드 버전에서 수정되었지만 IE6의 경우 여전히 50%+ 시장 점유율 (출판 시점에 통계)이 있지만이 솔루션은 여전히 실질적인 의미입니다.
위의 세 가지 응용 프로그램 외에도 일부 부적절한 응용 프로그램은 Iframe 요소에도 일반적입니다. 예를 들어, 페이지에 너무 많은 iframe 프레임을 포함시키고 프레임 외부의 링크 태그의 대상 속성을 지정하여 클릭하면 iframe을 업데이트하십시오. 이 사용법은 프레임 세트와 유사하여 탐색 공유 목적을 달성합니다. 원래 의도는 좋지만 단점에 대해서는 의심의 여지가 없습니다. 이로 인해 페이지 요청이 너무 많습니다. 위에서 언급 한 "웹 사이트 속도를 높이기위한 모범 사례"기사는 페이지를 최적화하는 Iframes 수를 최소화해야하며 세 가지 단점이 요약되어 있음을 분명히 명시합니다.
- 콘텐츠가 비어 있더라도 리소스 손실 (클라이언트 및 서버 포함)을 유발합니다.
- 블록 페이지 onload 이벤트 트리거 (블록 페이지 onload, 페이지가로드되는 것을 방지 할 수 있으므로 변환되므로 여기에 의심이 있습니다).
- 의미가 없음 (SEO는 웹 사이트 마케팅의 중요한 부분입니다)
XHTML1.0의 HTML5의 다음 버전에서는 웹 페이지 가용성에 대한 부정적인 영향으로 인해 프레임 세트 태그에 대한 지원이 없으며, 이는 측면의 몇 가지 문제를 설명합니다.
또한 내장 된 iframe은 내부 컨텐츠 크기에 자동으로 적응할 수 없으므로 페이지 디스플레이의 무결성을 유지하기 위해 iframe 컨텐츠의 변경에 따라 크기를 즉시 조정하려면 JavaScript 스크립트를 작성해야합니다. JavaScript 스크립트가 수정해야 할 필요성과 함께 여러 흩어진 요청은 여러 Iframe 페이지가 시스템을 실행하는 위험을 증가시킵니다. 그렇다면 페이지 콘텐츠를 공개적으로 유지하는 좋은 방법이 있습니까? 서버 측은 오랫동안 솔루션을 제공했습니다. ASP의 포함 및 PHP의 요구 방법은 모두 프로그램에 기존 코드를 포함하는 데 사용됩니다. 또한 페이지의 특정 부분 (예 : 내비게이션 메뉴, 바닥 글)을 공개 할 수 있습니다. 그러나 실행 후 전체 페이지로 출력하여 클라이언트 요청을 효과적으로 줄이며 IFRAME의 높은 적응성에 문제가 없습니다.
