css의 상대단위로서 어떠한 기준에따라 값이 상대적으로 변하는 폰트 단위이다. 그 기준이 em은 부모값에 따라 적용되며, rem은 root 즉 html의 값에 따라 적용된다.

em

.parent{
    font-size:20px;
}
.child{
    font-size:0.5em; // 10px로 적용된다.
}

rem

.parent{
    font-size:20px;
}
.child{
    font-size:0.5rem; 
    // *html의 기본값은 16px이다. 따라서 16px의 0.5인 8px이 적용된다
}

😄 rem, em을 알아보았는데 컴포넌트 단위로 쪼개서 사용할 경우 부모요소가 바뀌는 케이스가 무수히 많다. 그래서 em을 사용할 경우 폰트사이즈가 부모요소에 따라 바뀔수 있고, em은 폰트사이즈를 직관적으로 알기 어렵다. rem은 root html에따라 폰트사이즈를 직관적으로 알 수 있고, 컴포넌트 단위로 쪼개더라도 폰트사이즈에 별다른 이슈는 발생하지 않는다.

아이폰 Safari에서는 노치화면과 url바 등으로 힌해 vh값이 제대로 적용되지않는다. 해당 부분까지 포함하여 계산하는것으로 예상됨

🚨 vh는 vh = viewport height 라는 의미로 화면에 보여지는 viewport에 맞춰 그에따른 비율로 설정된다. 화면의 높이가 1000px이라 가정해보면 1vh는 10px이 된다.

2-1. js로 적용해보기

js를 활용하여 window innerHeight값을 활용해 해당 값을 기준으로 하여 vh값을 재설정하여 변수로 저장한다.

/*
--vh라는 값으로 html태그에 --vh값을 설정해준다 
(윈도우 innerHeight값을 기준으로 1vh를 px값으로 --vh에 저장) 
*/
function setVhProperty(){
  let vh = window.innerHeight * 0.01;
  document.documentElement.style.setProperty('--vh', vh + 'px');   
}

//실행부
setVhProperty();

//윈도우 resize시마다 실행(viewport가 바뀌기때문에)
window.addEventListener('resize', function () {
  setVhProperty();
});

😀 이제 css에서 --vh값을 활용하여 vh값을 설정해준다.

.100vh{
    height: calc(var(--vh, 1vh) * 100);
}

2-2. css로 적용해보기

-webkit-fill-available 속성 사용하기 뷰포트의 사용 가능한 만큼 높이값을 설정해준다.

.100vh{
    height: -webkit-fill-available;
}

🚨 해당 속성은 꽉채울 경우에만 사용할 수 있을것 같고, webkit 기반만 적용이 가능하기에 ios일경우에만 사용하도록 분기해주는게 좋을 것 같다.

분산 버전 관리 시스템인 git저장소 호스팅을 지원하는 웹 서비스. 원격 저장소 역할 및 다른사람들과 협업을 가능해게 해준다.

git init //git 저장소 만들기 
git branch -M main 
// git은 기본 브랜치 이름이 main이어야함. 
경우에따라 기본 브랜치가 master로 설정되어있을 수 있기때문에 main으로 변경해준다.

2. github 원격저장소에 올리기

로컬 → 원격으로 업로드 해보기

git push -u https://github.com/user/prj~~ main
// main브랜치를 해당 원격저장소 주소에 올리라는 의미

-u 옵션은 해당 원격저장소 주소를 기억해두라는 의미로 한번 실행후에 git push만 입력해도 push됨.

3. github 각종 명령어

git remote add origin https://github.com/user/prj~~  
// 해당주소를 origin 변수명으로 저장해 사용할수 있음 
// git push -u origin main 2번에 나온 push명령을 간소화할수있음 

git remote -v //변수목록 살펴보기

git clone https://github.com/user/prj~~ //해당주소의 소스 내려받기

git을 누가 사용하고있는지 구분하기위해 PC의 Terminal에 진입해서 유저이름 세팅을 해줍니다.

git config --global user.email "이메일"
git config --global user.name "사용자"

이후 프로젝트 root경로에 진입, git init 명령어를 통해 git을 시작합니다.

2. add / commit

이제 git을 시작했으니, 저장소(repository)에 파일을 저장하는 명령어를 실행해봅니다.

git status //git의 현재 상태를 확인합니다.
git add 파일명 //해당 파일을 stage area에 등록합니다.
git add . //전체 파일을 stage area에 등록합니다.
git commit -m "메세지" //stage area에 등록된 파일들을 repository에 저장합니다.

git은 add를 통해 stage area에 커밋대상들을 임시로 등록해둡니다. 이후 확실하게 repository에 저장할 파일들을 commit 명령어를 통해 저장합니다.

3. branch 활용하기

이제 repository에 저장하는 방법을 익혔는데 우리가 프로젝트 진행중에 또다른 사이드프로젝트를 진행하게 된다면.. 현재코드와 사이드프로젝트간 충돌이 발생할수도 있고 복잡해집니다. 이럴때 사용할 수 있는 프로젝트의 복사본을 만들어주는 branch에대해 활용해봅시다.

git branch 브랜치이름 //브랜치 생성(보통 기본 branch명은 main 또는 master
git switch 브랜치이름 //해당 브랜치로 이동

swiper를 적용하여 반응형 코딩을 하던 중 반응형 기준에 맞춰 swiperPerView를 3,6,9씩 보여주는 UI를 만들던 중 브라우저창 전체화면 시 swiper가 일부 깨지는 현상이 발견되었다.

첫번째 시도

윈도우 리사이즈시 swiper.update() 메서드를 실행하면 해결할 수 있을 것 같았다. 리사이즈 마지막 발생시점(?)에 swiper.update() 메서드를 실행해보았으나 결과는 실패였다. 원인불명인데 update() 메서드의 버그로 유추해본다.

var swiper;
$(function){
    swiper = new Swiper(".swiper-container",{
        slidesPerView:9,
          loop:true,
          breakpoints:{
            720:{
              slidesPerView:3
            },
            900:{
              slidesPerView:3
            },
            1180:{
              slidesPerView:3
            },
        }
    });

      var resizeCheck; // 리사이즈 END체크
      $(window).resize(function(){
        if(resizeCheck){ //계속 리사이즈중이면 clear
            clearTimeout(resizeCheck); 
        };

          //0.5초이상 리사이즈 지속하지않으면 실행
          resizeCheck = setTimeout(function(){
            console.log("resizeEnd");
              swiper.update(); //스와이퍼 업데이트
        },500);
    });
}

두번째 시도

일전에 탭메뉴로 탭1 일반컨텐츠, 탭2 스와이퍼 컨텐츠를 구현한 경험이 있었다. 그 당시 탭2가 display:"none" 되어있어서 탭1로 진입후 탭2 클릭시 스와이퍼가 제대로 동작하지않은 경험이 있다. 그당시 사용했던 방법은 스와이퍼에 observer, observeParents 매개변수로 각각 true값을 넣어서 해결했던 방법이다. swiper API에 따르면 아래와 같은내용이다.

observer : true Swiper는 스타일을 변경(예: 숨기기/표시)하거나 하위 요소를 수정(예: 슬라이드 추가/제거)할 때마다 업데이트(재초기화)됩니다.

observeParents : true Swiper 부모요소의 변화에따라 업데이트(재초기화)됩니다.

위의 매개변수를 추가함으로써 브라우저창 전체화면 시 swiper가 일부 깨지는 현상도 해결되었다.

참고자료: https://swiperjs.com/swiper-api

나는 gulp를 회사에서 처음 접하게 되었는데 주로 퍼블본 scss를 css로 변환 및 통합, babel을 통한 js의 변환 등에 사용하였는데, gulp 설치부터 플러그인 활용법에 대해 다시한번 정리해보고자 한다.

Gulp란?

nodejs와 npm 기반의 task-runner이다. 웹 개발 시 필요한 최적화, 유닛 테스트 등 반복되는 task들을 자동화 하기위해 사용된다. 다양한 플러그인들을 활용해 scss를 css로 변환하거나 IE에서 호환이되지않는 es6를 es5로 변환시켜주는 등 최적화에도 효율적으로 사용되곤 한다.

Gulp 시작하기

Gulp 설치

npm install --save-dev gulp gulp -version

gulp 설치 후 gulp version을 체크하여 설치가 완료되었는지 확인한다.

CLI version: 2.3.0 Local version: 4.0.2

위와같이 출력되면 설치완료

gulpfile.js 생성

gulpfile.js는 gulp task를 정의하는 파일이다. 프로젝트 root경로에 "gulpfile.js" 파일을 생성한다.

task 선언 및 수행

gulpfile.js를 생성후 gulp가 수행할 task를 해당 파일에 Javascript로 선언해준다.

task 선언

function defaultTask(cb) {
    cb();
}

exports.default = defaultTask

task 수행

exports.default로 하였기에 명령어는 아래와같다.

gulp default 또는 gulp

gulp task 수행시 대략 이렇게 이해하면 편할것 같다. exports.실행명령어 = 함수;

ex) "test"로 export할 경우 exports.test = defaultTask 수행 명령어: gulp test

API 파헤쳐보기

•src

gulp가 파일을 읽기위해 사용되는 메소드이다. stream을 리턴한다.

아래와같이 src란 변수로 선언해서 사용할수 있다.

const { src } = require( 'gulp' ) ;   

src(globs, [options])

globs는 문자열 또는 배열 type이고, 읽어들일 파일(들)을 해당 타입에 맞게 입력하면 된다. options는 다양하게 있지만 필요에따라 찾아보면 될 것 같다. 활용예제는 dest에서 같이 다루겠다.

•watch

gulp가 파일을 감시하기 위해 사용되는 메소드이다. 변경이 발생하면 glob을 보고 작업을 실행한다. 예를들면, scss를 바라보고 변경이 감지되면 css로 변환하는 watch task를 만들어 사용할 수 있다.

const { watch } = require('gulp');

watch(['input/*.js', '!input/something.js'], function(cb) {
  // body omitted
  cb();
});

위 코드를 보면 gulp의 watch대상은 input폴더 하위의 js중 something.js를 제외한 모든 js파일이 된다. (* string의 !가 있으면 해당 파일 제외됨) 이와 같이 응용할 수 있겠다.

•dest

쉽게 표현하면 파일을 작성(?)하는 역할을 한다. 예를 들면, scss 파일들을 src로 읽어서 css로 변환(scss→css 변환은 다음장에서 다루겠다.) 한후, 변환된 css들을 통합하여 하나의 파일로 만든뒤, 내가 원하는 위치(directory)에 파일을 위치시킬때 사용될수 있다. 주로 프로젝트에서 통합된 css를 include하기 때문에 gulp활용 시dest는 빠질수 없는 요소이다.

dest(directory, [options])

directory에 파일을 작성하고자 하는 경로를 입력하면 된다.

const { src, dest } = require('gulp');

function copy() {
  return src('input/*.js')
    .pipe(dest('output/'));
}

exports.copy = copy;

위 코드를 보면 input폴더 하위의 모든 js파일을 읽어들여 output폴더 하위에 작성하게 된다.

series, parallel 등도 많이 쓰게되었지만 퍼블리싱에서 가장 많이쓰이고 필수적인 src,watch,dest만 정리를 해보았다. 다른 써보지못한 API에 대해서도 여유가있으면 더 공부해볼만 할것같다. 많이 알수록 간편해지고, "이런게 있었네?"와 같은 소득을 얻게 될수도 있게될테니 말이다.

참고: https://gulpjs.com/docs/en/api/concepts

다음 장에서

gulp의 설치부터 task작성, 여러가지 API활용을 정리해보았는데 다음장에서는 scss를 css로 컴파일, es6 JS를 es5로 컴파일 등을 해보며 gulp에서 많이쓰이는 플러그인들을 알아볼 예정이다.

안드로이드 일부 기기에서 스크롤을 빠르게했을시 브라우저의 렌더링 오류인지 레이아웃이 깨지는 현상이 발생되었다..

Before에 컨텐츠 내용이 잘 나왔다면, 사용자가 스크롤을 아주 빠르게 이동했을시 After 화면 처럼 컨텐츠의 일부 텍스트, 이미지 등이 렌더링 되지 않았다.

원인 파악

해당 페이지는 컨텐츠 클릭시 해당 컨텐츠의 scrollTop으로 이동하는 스크롤 이벤트가 걸려있었고, 또한 이동시 jquery animate를 사용중이다.

우선은 가장 의심되는 원인으로는 "브라우저 렌더링(?), 페인팅(?)이 느리다" 였다. 스크롤시에 브라우저가 화면을 다시그리는데 스크롤 속도에 대비해 브라우저 페인팅이 느려서 해당 현상이 나타난 것으로 보였다.

해결 방법

transform:translate3d(0, 0, 0)

결론적으로 css의 핵(hack)이라고 불려지는 transform:translate3d(0,0,0)을 사용하여 해결할 수 있었다. 0,0,0값을 준것은 변형이 필요없기 때문이다.

조금 더 자세히 구글링 해보니 translate3d는 GPU 가속을 사용하는 요소로서 기본적으로 브라우저 렌더링시에는 CPU를 사용하는데 GPU가 이에 개입하여 렌더링을 빠르게 할수있게 돕는다고 한다. 그래서 해당영역의 가장 부모인 overflow가 적용되어있는 컨텐츠에 적용하였다.

will-change: transform;

추가적으로 stack overflow를 헤매다가 발견한 will-change속성인데 예상되는 변화의 종류에 관한 힌트를 브라우저에 제공하여 브라우저 렌더링에 대비할수 있게 해주는 속성이다. 미리 대비할수 잇기에 기존에 핵으로 사용했던 translate3d보다 최적화면에서는 더 나을수 있다고 한다. 하지만 일부 Safari, IE등 지원이 되지않아, 이번엔 사용할 수 없었다.

마치며

이전부터 핵으로 들어봤었던 transform: translate3d(0,0,0)과 같은 코드는 "이렇게 하니까 잘되네" 라며 쉽게 넘어가곤 했던 코드중 하나였던 것 같다. 이번에 수정을하며 오류원인, 해결된이유 등에 대해 조금더 디테일하게 찾아봐야 더 발전할 수 있을거 같다고 느꼈다.

참고) https://developers.google.com/web/fundamentals/performance/rendering/simplify-paint-complexity-and-reduce-paint-areas?hl=ko

https://developer.mozilla.org/ko/docs/Web/CSS/will-change

브라우저 ⇒ 도메인서버와 통신하여 호스트의 IP를 찾음. 이후 브라우저는 해당 호스트IP서버와의 TCP 연결을 생성, 이제 브라우저는 IP서버와의 리소스 요청및 다운로드를 진행한다. 리소스에는 HTML,CSS,IMAGE,JS,Font 등.. 리소스를 다운로드하면서 페이지를 그리는 과정을 렌더링 이라고한다.

렌더링 과정

1. HTML구문 분석을 진행하면서 DOM트리 생성
2. HTML구문 분석 중 CSS링크가 발견되면 CSS구문 분석을 진행하여 CSSOM 트리생성 (HTML과 별도의 스레드로 동작함)
3. DOM+CSSOM ⇒ 렌더 트리 생성
4. 렌더트리를 통해 노드들의 위치 정보가 계산됨. 브라우저의 왼쪽위부터 오른쪽 아래 순으로 진행
5. 브라우저창에 표현하는 페인트 단계

JS의 경우 DOM,CSSOM을 동적으로 변경 가능해서 렌더링 도중 JS에 의해 변경이 발생하면 3~5번 과정을 재수행한다. 따라서, 렌더링 과정에서 최대한 JS의 개입 없이 최적화가 필요하다. 그러나 대다수의 JS는 렌더링에 관여하여 이를 잘 구분하여 분리해야 한다..

DOM 최적화

HTML의 구문분석은 관대하다.

HTML 구문분석 과정에 작은 오류가 발생하면 브라우저가 알아서 처리하는 경우가 있다. ( ex:일부 태그를 닫지 않는 케이스 ) 그러나 이런 케이스가 많아질 경우 브라우저가 처리하면서 많은 메모리와 CPU를 소모할 수 있고 이는 렌더링 시간에 어느 정도 관여할 수 있다는 점이다. 오류 최소화가 필요한 부분이다.

과도한 HTML 태그 중첩 사용은 피하자.

위의 렌더링 과정에서 JS가 동적 변경을 발생시키면 35번 과정을 되풀이한다고 언급한 내용이 있다. 35번 과정을 되풀이 할때 HTML태그가 많다면 이것 또한 렌더링 지연의 원인이 될 것이다.

Atomic 디자인패턴으로 퍼블리싱 한 경험이 있는데 atom단위, module단위로 분리하는 과정에서 지나치게 태그를 많이 감싸서 활용하다보니 결과물을 보았을 때 생각보다 많고 불필요한 태그 중첩을 사용한 경험이 있다. 나중에 개발 데이터가 입혀진 후에는 수정이 많이 어려울 것으로 생각된다.

CSS 최적화

CSS를 분리하자

CSS를 통으로 말아서 사용하면 브라우저의 첫 화면과 관련없는 (뒤에 숨어있는 페이지 등) 리소스가 있을 수 있어, 렌더링 속도 지연에 영향을 준다. 해당 페이지에 필요한 CSS를 분리하면 좋다는 말이다. 그러나 이게 맘처럼 쉽지는 않을 것 같다. 어떻게 분리해야 좋을지는 좀 더 고민이 필요해보인다.

또 다른 방법으로는 당장 필요하지 않는 CSS를 지연 로드 시키는것이다. 예를 들면 <link data-href="css파일"/> 로 태그 작성 후 js onload이벤트를 통해 페이지가 로드되면 "data-href " 값 이용해 파일을 연결한다. 이 또한 CSS 파일 분리를 잘 해 두어야 할 수 있는 방법이다.

어떻게 CSS를 효율적으로 분리할 수 있을지가 중요한 것 같다.

JS 최적화

async, defer 속성을 이용

위에 언급한 듯이 JS는 렌더링 지연에 영향을 주는 부분이 있다. 따라서 HTML 구문 분석 과정에 꼭 필요한 JS와 그렇지 않은 JS를 구분할 필요가 있다.

async, defer 속성이 이를 도와줄 수 있다. async 속성은 HTML 구문 분석과 동시에 실행하고, defer 는 JS를 미리 다운 받아 놓은 뒤 HTML 구문 분석이 완료된 후 실행한다.

그 외에 onload event를 활용하는 방법이 있다.

CSS와 마찬가지로 JS 분리가 관건이다.