교육-15

강민창·2024년 7월 9일

회사 교육

목록 보기

15/29

NEXACRO Javascript framework를 Merge, Commpress 기능을 통해 파일 개수 및 사이즈 최적화

운영 시에는 NEXACRO Javascript framework(Library)에 대해서는 필수 사용권장

기본 Merge시 5개의 파일이 생성되나, json파일 수정을 통한 1개 파일 변경 가능
- 1개의 json으로 파일을 생성시 사이즈가 커지므로 최초 접속 시 다수의 파일을 동시에 받는 것보다 단점을 가지고 있으나, 캐시 처리 후에는 효율적임
Compiled JS는 NER 실행환경에서만 가능하며, 보안 측면을 고려할 때는 Compiled JS를 권장
- 개발 소스 보안 측면을 고려할 때는 Compiled JS 권장
Deploy 방법
- Nexacro Studio 메뉴의 Deploy Application를 통해 전체 빌드 가능
- Deploy File 선택을 통한 개별 파일 진행 가능
- 또는 제품 폴더의 nexacrogenertor.exe, nexacrocompressor.exe파일을 이용하여 배치파일 형태 가능(단, windows 계열 Machine에서만 가능)

NEXACRO 엔진모듈 중 사용하지 않는 JS파일을 제거하여 Js 최소화한다

일부 기능 또는 몇 개의 화면에서 사용하는 경우라면 필요한 요소만 대상 화면에 적용

초기 화면 로딩 시까지 시간이 지연되는 것을 시각적인 효과로 체감속도를 줄인다

체감속도 감소
- 네트워크 상황이 좋지 못한 PC나, PC사양이 낮은 경우 최초 접속 시 로딩 지연시간이 발생함
- 로딩 시간은 동일하나, 대기 시간 동안 이미지를 보여줌으로써 접속중임을 인지할 수 있도록 한다

Javascript defer 옵션을 통해 이미지를 먼저 보여준다

Defer
- 초기 제품을 실행하기 위해서는 내부 엔진 파일(js)를 다운로드 받게 되는데 이때 pc사용에 따라 다소 시간이 지연되나 defer옵션을 통해 이미지를 먼저 보여준다

Application에서 사용할 수 있는 최대 화면 개수를 제한한다

메모리
- Application 실행 시 한계 메모리가 있음 이를 초과시 비정상 종료 및 이상동작(대표 현상 : 화면이 움직이지 않거나, 백지화 현상, 화면 깜박임 등)
오픈 화면 개수 제한
- 화면 구성에 따라 메모리 사용량이 다르므로, Application개발 시 최대 오픈할 수 있는 화면(MDI) 오픈 창 등의 개수를 제한한다

이 부분은 Application 설계 단계에서 업무 특성을 고려하여 최대 오픈 가능한 화면 개수를 제한

최초 로딩 페이지는 가급적 단순하게 구성한다

로딩 페이지 단순화
- 최초로 로딩되고 보여지는 페이지는 가급적 단순화하여 구성
- 메인 페이지에 많은 수의 데이터셋과 링크된 페이지, 많은 include등으로 구성하게 되면 이로 인해 로딩 시간이 길어지며, 초기 로딩 속도 이슈가 원인이 됨

Tracemode는 개발 시 유용하나 운영 시에는 성능에 영향을 미침

운영환경에서는 반드시 Tracemode 설정을 off 및 trace문 주석처리

Tracemode는 개발 시 디버깅이 용이하나, 운영 시에는 성능에 영향을 준다
운영서버에는 trace를 off하는 것을 권장한다
Tracemode를 off 하더라도 trace문 내부의 성능에 영향을 주는 구문이 있다면 내부 코드가 실행되므로 trace문 자체를 주석 처리하도록 한다
개발 완료 후 운영 단계에서는 trace off 및 불필요한 trace문은 제거한다

많은 이미지와 다양한 스타일을 적용하게 되면 응답시간 및 렌더링 등의 영향을 받음
이미지는 손실률이 없고, 높은 압축률을 보이는 png사용 권장

성능을 고려하여 페이지 구성 시 이미지는 최소화
- 컴포넌트의 스타일로 구성이 가능하다면 이로 대체
- 컴포넌트의 다양한 스타일을 구성할 수 있으나 스타일이 복잡할수록 렌더링에는 영향을 줌
  즉, 성능에 영향을 미침

상단 이미지는 기본 형태이나 하단 이미지는 Grid의 edittype과 padding이 적용된 경우이다
하단의 Grid를 HTML 형태로 만들기 위해서는 더 많은 node가 필요할 것이다

padding 줄 경우 node가 추가적으로 생성
- padding을 줄 경우 node가 추가적으로 생성되므로 성능향상을 위해서는 권장하지 않음

모든 폼에서 모든 공통함수를 include하는 방식보다는 필요한 부분만을 include하여 최적화
공통영역 성능은 담당자의 구현 및 컨설팅 역량에 따라 상당한 영향을 줌

공통으로 사용하는 include함수 최소화
- 모든 폼에서 사용하는 공통함수를 include하는 방식보다는 필요한 부분만을 include하여 최적화됨
- 특정 업무에서만 사용하는 함수는 공통에서 제외하고 해당 폼에서 처리
공통영역에 대한 부분은 담당자의 역량에 따라 성능좌우
- 공통영역에 대한 부분은 Application의 전체 선능에 영향을 주므로 개별 화면에 해당하는 부분은 해당 폼에서만 구현해 사용하도록 하고, Application전체에 해당하는 부분에 대해서만 공통영역으로 만들어 사용을 해야 함(즉, 공통담당자는 모든 함수를 공통모듈로 빼지 말고 타당성을 정확히 파악 후 진행)

공통영역은 단순 몇몇 화면의 이슈 해결이 아닌 Application 전체 영향을 미침

공통함수를 폼이 아닌 json에 등록하여 최초 1회만 로딩하도록 구성

공통함수 폼이 아닌 json형태로 등록
- 공통함수를 폼마다 include 하지 않고 json에 등록하여 최초 1회만 로딩하도록 구현
  즉, 엄무화면에서는 include가 없도록 구성

공통함수를 json처리 후에도 include가 필요한 경우 다수의 공통함수를 include하는 것 보다는 필요한 파일만 include항 사용한다

하나의 공통함수에 여러 개의 js를 include?
- 하단의 main.xjs를 include하고 다수의 js가 포함되어 있는 경우 불필요한 경우 불필요한 js가 포함됨
- 해당 업무에 필요한 js만 include하도록 세분화 필요

폼에서 사용하는 공통코드는 form의 onload시 호출하게 되므로 반드시 async 통신 사용
다수의 공통코드는 1:1 Dataset보다는 1:n Dataset를 받도록 구성한다

폼 onload 서비스는 비동기 사용
- 공통코드는 주로 폼의 onload이벤트에서 서비스를 호출하는 경우가 많으므로, 가능한 비동기 사용을 권장한다
- 다수의 Dataset을 조회하는 경우에는 1:1 보다는 1:n Dataset를 받아올 수 있도록 구성
참고
- 공통코드는 쉽게 변경이 되지 않기 때문에 한번 호출한 데이터는 Global dataset으로 관리하며, 메모리상의 데이터를 재활용하여 서비스 시간을 줄일 수 있다

다수의 컴포넌트로 구성된 복잡한 화면의 경우 브라우저 사양에 따라 성능저하 원인이 된다
초기 화면에 표현되지 않아도 되는 경우 특정 영역을 Div등으로 구성하여 후 처리한다

Div 영역 분할
- 다수의 Component로 구성된 복잡한 형태의 화면의 경우 브라우저 사양에 따라 성능 저하 원인 초기 화면에 표현되지 않아도 되는 경우 특정 영역을 Div 등으로 구성하여 후 처리
- 주로 CS화면을 컨버전을 하는 경우 다소 복잡한 형태가 많으니 초기 개발 설계 시 주의해야 한다