0
여러 가지 코딩 방법이 있습니다. AEM, JSP, EXT JS, JSTL, Sightly, CORAL UI. 최종 사용자에게 더 빠른 웹 페이지 렌더링을 위해 AEM에서 구현하는 것이 가장 좋은 조합이 무엇인지 혼란 스럽습니다.페이지 렌더링에서 어떤 프레임 작업이 더 빠를 것입니까?
A
답변
2
렌더링 속도는 콘텐츠가 캐싱 계층에서 전달 될 때 관련이 없습니다. 캐시 워밍업을 위해서는 아키텍처가 아니라 기술이 중요합니다.
0
먼저 프런트 엔드 및 백 엔드 렌더링 엔진을 혼합합니다. 두 번째 ExtJS 및 Coral UI는 대부분 제작 인스턴스에 사용되며 렌더링 인스턴스에는 사용되지 않습니다. i.net는 여기에 대해 이야기되지만, 성능의 측면은 어도비는 전망이 좋은이 출시되었을 때 말한 확실하지 말했듯이 :
- 사용하여 전망이 좋은 페이지의 부분에 매우 자주 JSP 명중되지 않은 부분에 그 JSP와 HTL (Sightly) 모두 AEM에 의해 바이트 코드로 컴파일되므로, 이것이 현재 얼마나 관련이 있는지를 확신 할 수 없다. 우리는 렌더링을 할 때 전체적으로보기로 결정했습니다. 왜냐하면 속도가 빠르면 사용 가능한 캐싱 레이어가 너무 많아 걱정할 필요가 없기 때문에 우리의 삶이 더 쉬워졌습니다 (FE 및 BE).
이 정보가 도움이되기를 바랍니다.
Adobe는 6.1 이상에서 Sightly 만 지원합니다. 다른 모든 플랫폼은 외부 요인으로 인해 중단되지 않는 한 계속 작동하지만 향후에 비 시각 플랫폼에 새로운 기능이 추가되지는 않습니다. 따라서이 정보를 기반으로 선택의 여지가 없는지 확실하지 않습니다. 기술적으로, 페이지 렌더링 속도는 HTML 구성에 따라 다르므로 어떤 속도면에서 (스크립트의 서버 측 컴파일 또는 클라이언트 측 HTML 변환) 확실하지는 않습니다. –
다른 의견 작성자들이 이미 말했듯이 : 당신은 많은 것을 혼합하고 있습니다. 기본적으로 JSP와 HTL (이전의 Sightly) 중에서 선택할 수있는 "프레임 워크"가 두 가지 있습니다. HTL은 AEM 6.1 이후의 유일한 옵션이기 때문에이 옵션조차 가지고 있지 않습니다. 하지만 어쨌든 캐시에서 페이지를 전달하려고해야하므로 선택할 수는 있더라도 별 문제가되지 않습니다. – Jens