문맥
프리랜서 개발자로 일하면서 종종 XSLT를 기반으로 웹 사이트를 만들었습니다. 즉, 모든 요청에 대해 페이지 내용에 대해 알아야하는 모든 내용 (현재 로그인 한 사용자 이름, 최상위 메뉴 항목,이 메뉴가 동적 / 구성 가능한 경우, 텍스트)을 포함하는 XML 파일이 생성됩니다. 페이지의 특정 영역 등에 표시됩니다. 그런 다음 XSL 프로세스 (캐시 등)를 HTML / XHTML 페이지로 처리하여 브라우저로 보냅니다.
특히 PHP를 사용하여 소규모 웹 사이트를보다 쉽게 만들 수 있다는 좋은 지적이 있습니다. 일종의 템플릿 엔진이지만 다른 템플릿 엔진을 선호합니다. 대부분의 템플릿 엔진보다 훨씬 강력하고 더 잘 알고 있기 때문에 다른 템플릿 엔진을 선호합니다. 필요할 경우 별도의 API를 만들 필요없이 자동 액세스를 위해 필요에 따라 원시 XML 데이터에 액세스 할 수도 있습니다.
물론, 캐싱 기술이 우수하더라도 XSL은 여전히 전체 웹 사이트 성능을 저하시키고 더 많은 CPU 서버 측을 필요로하기 때문에 중간 규모 또는 대규모 웹 사이트에서는 완전히 실패합니다.
질문
최신 브라우저는 XML 파일을 가져 와서 XML과 같이 선언 된 관련 XSL 파일로 변환 할 수 <?xml-stylesheet href="demo.xslt" type="text/xsl"?>있습니다. Firefox 3이 가능합니다. Internet Explorer 8도 가능합니다.
이는 XSL 처리를 사용자의 50 %를 위해 서버에서 클라이언트 측으로 마이그레이션 할 수 있음을 의미합니다 (이를 구현하려는 여러 웹 사이트의 브라우저 통계에 따라). 즉, 사용자의 50 %가 각 요청마다 XML 파일 만 수신하므로 서버 대역폭 (XML 파일은 처리 된 HTML 아날로그보다 훨씬 짧음)이 줄어들고 서버의 CPU 사용량이 줄어 듭니다.
이 기술의 단점은 무엇입니까?
여러 가지에 대해 생각했지만이 상황에는 적용되지 않습니다.
- 브라우저 요청에 따라 원시 XML을 전송하는시기와 대신 HTML로 변환 할시기를 선택하기가 어려운 구현 및 필요성. 분명히 시스템은 실제 시스템보다 훨씬 어렵지 않을 것입니다. 유일한 변경 사항은 모든 XML에 XSL 파일 링크를 추가하고 브라우저 검사를 추가하는 것입니다.
- XSLT 파일은 서버에 의해 캐시되지 않고 브라우저에 의해 다운로드되므로 더 많은 IO 및 대역폭 사용. XSLT 파일은 브라우저에 의해 캐시되기 때문에 (이미지, CSS 또는 JavaScript 파일이 실제로 캐시됩니다) 문제가 될 것이라고 생각하지 않습니다.
- 일부 브라우저에서 페이지를 저장할 때 발생할 수있는 문제와 같이 클라이언트 측의 일부 문제 일 수 있습니다.
- 코드 디버깅 어려움 : 표시되는 유일한 소스는 다운로드 한 XML이기 때문에 브라우저에서 실제로 사용중인 HTML 소스를 얻는 것은 불가능합니다. 반면에, 나는 클라이언트 측에서 HTML 코드를 거의 보지 않으며 대부분의 경우 직접 사용할 수 없습니다 (공백 제거).
답변
브라우저에서 XSLT를 점진적으로 렌더링 할 수 없음
것을이 수단 아무것도 다른 부하 아무것도 모든 데이터가 표시 될 때까지 전체 스타일 시트가로드 및 처리.
이미지, CSS 및 JS의 점진적 렌더링 및 프리 페치에 빠져 있습니다.
다른 요청에 의해 초기로드가 지연됨
작은 파일 (<20kb) 의 경우 대역폭이 아닌 요청 수가 병목 현상입니다. 은 프런트 엔드 성능 이며 대부분의 페이지와 스타일 시트는이 범주에 속합니다.
큰 페이지가 있으면 더 나빠집니다. 첫 번째 요점을 참조하십시오.
아마도 대역폭을 절약하지 않을 것입니다
XSLT 자체는 매우 장황하며 현재 페이지에서 사용 된 것뿐만 아니라 모든 사이트에 대한 템플릿과 모든 드문 경우에 대한 논리를 포함해야 할 수도 있습니다.
블로그 게시물을 보내는 경우와 같이 보내는 기본 XML 파일에 마크 업 된 모든 데이터를 여전히 포함해야합니다. XSLT가이를 작게 만들기 위해 할 수있는 마법은 없습니다. 복잡한 데이터를 보내는 경우 어쨌든 많은 마크 업이 발생합니다.
캐시가 과대 평가되었습니다
브라우저 캐시는 그리 좋지 않습니다 .
Yahoo! 사용자의 40-60 %는 캐시 경험이 비어 있으며 모든 페이지 조회의 ~ 20 %는 빈 캐시로 수행됩니다.
대기 시간으로 인해 추가 요청이 가장 많은 경우 캐시는 더 나빠 집니다.
이탈률을 확인합니다. 캐시 된 XSLT를 사용하지 않는 사용자는 추가 비용을 지불하여 스타일 시트를 다운로드하고 처리 될 때까지 기다립니다.
gzip 리버스 XSLT
XSLT를 통해 수행되는 대부분의 변환은 간결한 마크 업을보다 장황한 것으로 변경하고 반복을 추가합니다. 그러나 gzip은 파일에서 반복 / 중복을 제거하는 데 탁월합니다!
어쨌든 gzip을 사용해야합니다 (XML을 압축하지 않은 상태로 보내는 것은 낭비입니다). 처리 된 문서의 zip 크기는 처리되지 않은 XML의 zip 크기와 거의 같을 가능성이 있지만 추가 XSLT를 보내지 않아도되며 브라우저는 첫 번째 패킷이 도착하자마자 렌더링을 시작할 수 있습니다.
클라이언트가 느려질 수 있습니다
캐시에서로드하는 가장 좋은 경우를 가정하더라도 클라이언트 측의 XSLT 처리는 사용자의 CPU가 더 빠르며 XSLT 엔진이 더 빠른 경우에만 더 빠릅니다.
서버 측에서는 모든 종류의 최적화 트릭 (예 : 캐시 처리 조각 또는 전체 페이지)을 수행 할 수 있습니다. 최신의 가장 빠른 XSLT 프로세서를 사용할 수 있습니다 (브라우저에는 XSLT 1.0 만 있고 최적화되지 않은 것 같습니다). 그리고 서버에는 많은 저렴한 사무용 컴퓨터, 전화 등보다 강력한 CPU가있을 것입니다.
답변
HTML을 직접 생성 할뿐만 아니라이 서버 측을 확장하지 않아야 할 이유가 없습니다. PHP와 비교할 때 일정한 오버 헤드가 큰 이유는 없습니다. XSLT> JVM / CLR 컴파일러가 있으며 기본 코드로 변환 할 수도 있다고 가정합니다.
그러나 데이터와 프리젠 테이션 구조를 따로 따로 전송한다는 아이디어가 좋습니다.
많은 대역폭과 서버 성능을 절약 할 수 있습니다. 그러나 pomeL은 여러 가지 점을 언급했습니다.
브라우저 전체에 대한 적절한 지원을 위해 xslt.js 가 도움이 될 수 있습니다.
개인적으로 저는 XML을 좋아하지 않으므로 브라우저에서 실행할 JSON 템플릿 엔진과 JS 템플릿 엔진을 대신 사용합니다. 또는 템플릿 마크 업을 서버 측에서 실행 가능한 js로 변환하는 일종의 템플릿 엔진으로 클라이언트 측에서 렌더링하는 데 사용됩니다.
JavaScript는 거의 모든 곳에서 상당히 빠르며 사용 가능합니다. JSON과 JS는 XML 및 XSLT보다 훨씬 컴팩트합니다.
답변
소형 XML을 전송하고 클라이언트에 캐시 된 XSLT가 있으면 대역폭을 절약 할 수도 있습니다.
스마트 폰처럼 XSLT를 지원하지 않는 브라우저는 제외하십시오. 그러나 어쨌든이를 위해 특수화 된 버전을 만들어야합니다.
답변
주요 문제는 소수의 브라우저 만이 기능을 잘 지원했기 때문에 지원할 새 플랫폼을 만드는 데 어려움을 겪지 않았습니다. 또한 이전 버전의 IE는이 기능을 잘 지원하지 못했으며, 올바르게 기억하면 적어도 하나의 IE에 다른 XSLT 방언이있어 모든 종류의 재미있는 문제가 발생합니다.