긴 휴가를 마치고 오랜만에 포스트를 작성해 본다. 이번 포스트에서는 웹개발 및 플랫폼 관리에 있어서 가장 기본적이면서도 놓치기 쉬운 요소에 대하여 알아보기로 하자. 알다시피, 사이트코어는 무궁무진(?)하게 플랫폼을 비지니스 컨셉 또는 사용자에 맞게 확장 및 개발 구조를 변경할 수가 있다. 예를 들어, 하나의 플래폼에 많은 개발 에이전시들이 이용하고 있으면 이에 맞게 개발 구조를 변경해야 할 뿐더러 관리자 입장에서는 각각 에이전시 개발자들이 플랫폼의 기준을 얼마나 잘 준수하며 개발을 하는지에 대하여 관리를 해야한다.
개발 준수사항을 따르지 않고 웹사이트를 만들고 설계할 시 소수의 웹사이트 관리는 조그만한(?) 노력으로 충분히 보완하고 수정할 수 있지만, 사이트의 수 및 사이즈에 따라 보수하는데에 있어서 하나의 프로젝트로 진행할만큼의 시간, 노력, 그리고 비용이 든다. 특히나, 컴포넌트 및 모듈을 많은 웹사이트들과 공유하는데 있어서는 더욱 그러하다.
그 중의 또 하나의 가장 큰 문제점은 웹사이트 Performance 이다. 겉보기에는 웹사이트가 이쁘게 만들어졌고, 잘 돌아가는것처럼 보이나 그 뒤에 서버, 플랫폼, 데이타베이스 등은 개발 준수사항을 따르지 않음으로써 많은 리소스를 소비할뿐더러 요즘첨럼 클라우드를 기반으로 Infrastructure가 짜여져 있는 환경에서는 비용까지 고려해야한다. 또한, 고객 및 웹사이트 방문자의 입장에서도 웹사이트의 느린 렌더링 그리고 페이지를 이동하고 관련된 미디어를 노출하는데에도 시간이 소비되는 부분에 있어서 마케팅 및 비지니스에 영향을 끼친다.
필자는 지금까지의 경험을 토대로 어떻게 사이트코어의 Performance를 최적화 할 수 있는지에 대한 요소를 정리해 보았다.
- Roslyn Compiler - 로슬린 컴파일러 오픈소스 컴파일러이면서 API를 통하여 .NET 코드를 분석한다. 고로, 로슬린 .NET 코드 분석툴이라고 설명할 수가 있다. 먼저, Visual Studio에서 사이트코어 컴포넌트 작업을 할때 NuGet Compiler를 설치하고 개발을 하다보면 어디에서 코드 문제가 발생하는지 바로 알수있다. 로슬린 컴파일러는 사이트코어가 Views 로드하는데 미리 컴파일을 함으로써 로딩 시간을 더욱 빠르게 해준다. 사이트코어는 이미 DLLs파일을 포함하고 있으며, 이를 Web.Config 파일에서 활성화만 시켜주면 된다.
<system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701" /> <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\"Web\" /optionInfer+" /> </compilers> </system.codedom>
- HTML Cache Setting - 이는 웹사이트 방문자 관점에서 페이지 렌더링 속도를 향상시킬수 있다. 특히나 SXA를 사용하고 있을때에는 각 사이트 세팅마다 컴포넌트에 대하여 HTML Cache 레이어를 쉽게 설정할 수가 있다.
- Data Cache - HTML Cache 처럼 사이트코어처럼 데이타소스를 많이 이용하는 플랫폼에서는 특히나 중요하다. 기본적으로 초기 세팅이 되어있는데 이는 새로운 사이트코어를 셋업할때의 기본 세팅이므로 사이트에 맞게 설정이 중요하다.
- Asset Optimizer - 이는 SXA의 기반의 웹사이트를 개발할때 특히나 중요하다. 만약 이를 세팅하지 않고 웹사이트를 렌더링할시 하나하나의 CSS/JS 파일을 Request/Response 하는데 있어서 많이 리소스가 필요하 수 있고, 이는 사이트 Performance에 영향을 미친다. Optimizer를 사용함으로써 Asset의 요소를 모두 모아 Minify 하여 리소스 소비를 간략 시킬수 있다.
- IIS Dynamic Content Compression - 이는 HTTP Compression으로써 IIS를 설치할때 추가적인 기능중의 하나다. 이 Compression은 IIS와 사용자 브라우져간에 Transmission 시간을 빠르게 해줌으로써 컨텐츠를 빠르게 렌더링하는데 도움이 된다.
- The Limited Number of Child Item - 싱글 노드 아래 많은 많은 Child 아이템이 있다면 CMS내에 에디팅을 하는데 Performance 문제가 있을 수 있다. 고로, 100개의 Child 아이템으로 제한하는것을 권한다.
- The Limited Number of Rendering Variants - SXA기반으로 웹사이트를 개발하다보면 기존의 SXA 컴포턴트를 이용하여 추가적으로 새로운 스타일 및 레이아웃의 렌더링 옵션을 만들수가 있다. 하지만, 너무 많은 옵셥은 오히려 Performance 또는 에디팅에 있어서 모듈을 렌터링하는데 시간이 걸린다. 고로, 15개의 옵션으로 제한을 두는것을 권한다.
- Image Parameter - 요즘은 데스크탑 및 모바일뷰를 Responsive Design으로 개발을 한다. 하나의 고정된 이미지를 사용하기 보단 모바일뷰일때는 Image Parameter를 이용하여 서버에서 이미지를 re-size할수가 있다. 또한, 수정된 이미지는 파일시스템내의 데이타 Cache 폴더에 저장되므로 다음 Request가 있을시 반복적인 렌터링 및 수정 작업을 필할수있다.
- The Limited Number of Components on Page - 한 페이지의 들어가 컴포넌트수는 제한을 두어 페이지 렌더링 및 수정작업을 하는데 리소스 소비를 줄일수 있다. SXA 기반의 웹사이트일 경우 일반적이며 많은 페이지에 반복적으로 들어가는 컴포넌트라면 Partial Design을 통하여 우선적으로 세팅을 하고, 각각의 페이지에는 그 페이지에 맞는 컴포넌트를 추가하도록 하자. 이는 CMS내의 작업뿐만 아니라, 서버의 CPU 및 메모리 소비에도 영향을 주므로 명심하자.
