TIL 221202 vscode 단축키 / aria-label, aria-hidden / Critical rendering path

Chae·2022년 12월 2일

TIL 2212

목록 보기
2/22
post-thumbnail

🎆 오늘 공부한 것

  • 브랜치 스위치하는 방법
  • vscode 유용한 단축키
  • aria-label / aria-hidden
  • Critical rendering path / reflow, repaint
  • 타입스크립트 3장 진짜 조금 읽음
  • 테일윈드 설치 방법 대충 훑어보기

🙄 오늘 하려고 했는데 못한 것... 엥? 겁나 많고요

  • preload / modulepreload / prefetch 공부
  • 구멍난 마크업 언어 지식 채워넣기 2 (이듬 강의)
  • 알고리즘 강의 보기
  • 타입스크립트 책 읽기(3장 끝까지)
  • 리덕스 진입하기(대체 언제쯤 공부할 수 있게 될까?)



✨ git branch 스왑 / 자잘한 vscode 관련 팁

🎇 git branch 스왑

$ git branch < 현재 어떤 브랜치가 있는지 확인

$ git switch main < 그냥 스왑할 때만 사용

$ git branch -d flex < flex라는 브랜치를 삭제하겠다는 말

$ git checkout -b flex < 플렉스라는 브랜치를 만들면서 바로 브랜치 스왑

🎇 자잘한 vscode 팁, 단축키

🚀 한 줄 삭제하기

shift + ctrl + k

🚀 emmet 수식 평가 (커스텀)

shift + alt + m : emmet 수식 평가

🚀 emmet 약어로 래핑 (커스텀)

shift + alt + w : emmet 약어로 래핑

ul.member>li*5>a[href='/']+span[aria-hidden='true']{:}

<ul class="member">
 <li><a href="/"></a><span aria-hidden="true">:</span></li>
 <li><a href="/"></a><span aria-hidden="true">:</span></li>
 <li><a href="/"></a><span aria-hidden="true">:</span></li>
 <li><a href="/"></a><span aria-hidden="true">:</span></li>
 <li><a href="/"></a><span aria-hidden="true">:</span></li>
</ul>


ul>li.class$*>a[href='/']{어디에붙을까}
<ul>
 <li class="class1">
    <a href="/">어디에붙을까11</a>
 </li>
 <li class="class2">
    <a href="/">어디에붙을까22</a>
 </li>
 <li class="class3">
    <a href="/">어디에붙을까33</a>
 </li>
 <li class="class4">
    <a href="/">어디에붙을까44</a>
 </li>
 <li class="class5">
    <a href="/">어디에붙을까55</a>
 </li>
</ul>


✨ 웹 접근성을 고려한 마크업 (논리적 구조 마크업 / aria-label, aria-hidden)

🎇 논리적 구조로 마크업하기

(발그림 ㅈㅅ)
위 이미지의 헤더로 봤을 때, 디자인적 관점으로는(그냥 보이는 순서로)
1. 텍스트 링크(LNB)
2. 로고
3. 메인 메뉴(GNB)
순서로 마크업을 해야겠다는 생각을 한다.
(나도 그렇게 생각했는데 예제 html을 보고 어 이게 뭐지!? 했다.)

하지만 이 사이트의 구조상
1. 제일 첫번째로 로고를,
2. 텍스트 링크,
3. 메인 메뉴
순서로 기계가 인식하게 하는 것이 합당하다.

🎇 aria-label, aria-hidden

aria-label

예제 사이트 링크

사이트를 들어가보면 로고들의 마크업이 이렇게 되어있다. logo1, logo2, logo3 이런 식으로 클래스 네이밍을 하는 것도 좋지 못한 방식일 뿐더러, 웹 접근성의 측면에서 보면 백그라운드로 이미지가 삽입되어있기 때문에(alt가 없음) 스크린리더를 사용하는 사람들은 이 로고가 무슨 의미인지 알 수 없게 된다.

이것의 단편적인 해결방법으로

aria-label을 사용할 수 있다.
aria-label = "coca cola"를 작성해주면 스크린리더가 이 이미지는 coca cola다! 를 알려주게 된다. (alt를 대체할 수 있는 느낌으로 이해하면 될 것 같음)

아래는 aria-label을 사용할 수 없는 요소이다.

  • code
  • caption
  • deletion
  • emphasis
  • generic
  • insertion
  • mark
  • paragraph
  • presentation / none
  • strong
  • subscript
  • superscript
  • suggestion
  • term
  • time

🚀 aria-hidden

예시 이미지 출처 : 스크린리더 사용자를 위한 착한마크업 4편(특수문자 - 구분선)

상품별배송과 택배배송, 2일이내 출고라는 단어 사이에 있는 ㅣ 라는 글자(아무 의미 없는 꾸밈 요소)를 스크린리더는 "상품별배송. 이. 택배배송. 이. 2일이내 출고" 와 같이 "이"로 읽어버린다. 실제로 마크업에 "ㅣ"가 들어있기 때문... 아무튼 사용자에게 혼란을 주는 상황이다.

이럴 땐

<span class="line"></span>

<span class="line" aria-hidden="true"></span>

aria-hidden="true"를 넣어주면 스크린리더가 읽지 않게 된다.

이처럼 꾸밈으로만 사용된 마크업 요소 때문에 스크린리더 사용자에게 혼란을 주는 경우에 넣어주면 유용함.

🚨 읽어들여야 되는 정보가 있는 요소에는 aria-hidden="true"를 사용하면 안된다. 또 이 속성은 자식에게 상속되기 때문에 읽어들여야되는 요소의 상위에 추가하지 않도록 주의한다!!!!



✨ Critical rendering path

MDN : Critical rendering path 링크

중요 렌더링 경로 (Critical Rendering Path)는 브라우저가 HTML, CSS, Javascript를 화면에 픽셀로 변화하는 일련의 단계를 말하며 이를 최적화하는 것은 렌더링 성능을 향상시킵니다. - mdn

crp

👆 이미지 출처

도큐먼트 오브젝트 모델은 HTML을 분석함으로써 만들어집니다. HTML은 Javascript를 요청할 수 있으며, 이 경우 DOM 이 변경될 수 있습니다. HTML은 차례대로 CSS 오브젝트 모델을 만들기 위한 스타일에 대한 요청을 만들거나 포함합니다. 브라우저 엔진은 이 두가지를 결합하여 렌더 트리를 생성하며 레이아웃은 페이지의 모든 것에 대한 크기와 위치를 결정합니다. 일단 레이아웃이 결정되면 화면에 픽셀을 그립니다. - mdn

대충 요약하면

브라우저는
1. html, css, js를 서버에서 받아와 (request / response)
2. 로딩 과정을 거쳐(loading)
3. DOM과 CSSOM을 구성하고(scripting)
4. 브라우저에 표시를 하기 위해 렌더트리를 생성한다. (render tree)
5. 그리고 요소들이 어떤 위치에, 어떤 크기로 그려질 것인지 계산을 하고(layout),
6. 레이아웃이 결정되면 브라우저에 그림을 그림(painting)

아... 벌써 머리가 아프지만 성능 개선에 아주 중요한 개념이다. 버벅거리는 사이트는 나도 싫고 답답하니 나는 그런 사이트 안 만들기 위해서 공부해야지...

🎇 Render Tree

렌더트리

👆 렌더트리 이미지

렌더트리가 만들어지는 과정 영상

DOM과 CSSOM가 결합되어 브라우저에 실제로 보이게 될 것들을 추려 트리 구조를 생성하는 것...!

실제로 보이는 것들만 추린다는 것은 display : none 같은 안 보이는 것들은 렌더트리에 추가 되지 않는 다는 것이다.

이때 속성에 따라 필요한 경우 Render Layer가 만들어진다.

  • CSS 3D Transform(translate3d, preserve-3d 등)이나 perspective 속성이 적용된 경우
  • <video> 또는 <canvas> 요소
  • CSS3 애니메이션함수나 CSS 필터 함수를 사용하는 경우
  • 자식 요소가 레이어로 구성된 경우
  • z-index 값이 낮은 형제 요소가 레이어로 구성된 경우

왜 굳이 레이어가 나누어지지? 성능을 위해서ㅇㅇ
만약 레이어가 하나만 있고, 그 중 한 요소만 위의 속성으로 보이는 것을 변경한다면, 브라우저는 이거 하나를 바꾸기 위해 모든 요소를 전체적으로 다시 그리고 업데이트를 해야 된다. 하지만 레이어가 나뉘어져있다면 변경되어야 되는 요소만 부분적으로 업데이트를 할 수 있음. ㄹㅇ 포토샵 레이어랑 개념이 비슷하다고 보면 됨
(그렇다고 또 레이어를 너무너무 많이 나누어 놓으면 그것도 성능에 타격이 감)

근데 위의 속성 이런 거 하나도 없이 div에 간단한 속성만 있다면 레이어는 걍 하나만 사용한다.

🎇 layout (reflow)

요소들이 페이지에서 배치되는 위치와 방법, 각 요소의 너비와 높이 그리고 서로 관련된 위치를 결정하는 단계. position(relative, absolute, fixed..), width, height 등등 틀과 위치에 관련된 부분들이 계산된다.

화면에 보이는 요소 각각이 어디에 어떻게 위치할 지를 정해주는 과정을 Webkit에서는 layout으로, Gecko에서는 reflow로 부르고 있다.

드디어 나왔다 reflow... 슬비쌤이 강의에서 언급하신 reflow와 repaint 알아보려다가 여기까지 온 거임😭

🎇 paint (repaint)

화면에 픽셀을 그리는 단계. visibility, outline, background-color 같은 진짜 눈에 보이는 것들이 이때 그려진다.

이때 만약, Render Layer가 두 개 이상이 있다면 레이어들을 하나로 컴포짓하는 과정을 추가로 거치고 찐으로 그려지게 된다.

레이아웃과 페인트의 과정을 시각화 해놓은 영상 두개가 있다...
Gecko reflow~paint 시각화 영상 링크

facebook css reflow 시각화 영상


🎇 그래서 성능 좋게 하려면 어쩌라는 건데

기껏 다 적어놓고 중요한 걸 까먹고 있었다... 잘 준비하려다가 후다닥 와서 추가하는 중...

웹 성능을 위해서는 layout, 그니까 reflow 단계까지 가지 않게 css를 짜는 것이 좋다.

이미지 출처


대표적인 예시로 엘레멘트 하나 위치를 옮기는 애니메이션을 구현하고 싶다고 칠 때, position top, left 같은 layout을 변형 시키는 속성보다 컴포짓 단계에서만 변형 시키는 transform translate로 옮기는 게 성능면에서 훨씬 좋다는 것이다.

근데 이것도 위의 이미지보면 알 수 있듯이 브라우저마다 또 차이가 있음 어후 진짜ㅡㅡ; 그래도 position은 모든 브라우저가 layout을 건드리는 반면, transform은 사파리랑 엣지 말고는 제법 괜찮은 성능을 보여준다.

참고로 위의 b / g / w / e 는

  • 크롬 (Blink)
  • 파이어폭스 (Gecko)
  • 사파리 (WebKit)
  • 엣지 (EdgeHTML)

의 웹 브라우저 엔진을 의미한다.

위의 이미지처럼 브라우저마다 reflow, repaint, composite 어쩌고를 보고 싶으면
요기나
요기를 들어가보셔요





🎆 내일 할 것

  • 테일윈드 스터디
  • 스터디 끝나고 병원 갔다가 점심 먹고 들어오기
  • preload / modulepreload / prefetch 공부
  • 구멍난 마크업 언어 지식 채워넣기 2 (이듬 강의)
  • 알고리즘 강의 보기(진짜)
  • 리덕스 진입하기(진짜 진짜 제발)



📝 오늘의 일기

엥ㅠㅠ?? 오늘 수업 들으면서 알게 된..? 생소한 단어들 위주로 공부하다 보니 벌써 밤이다. 오늘 뭔가 많이 하려고 했는데 아무것도 못함... 내일은 테일윈드 스터디 참여해야 돼서 늦게까지 공부하지도 모대...😭 아니... 블로그 정리하다가 하루 다 간다 아이고 아이고... 오늘 공부한 거 추려서 깃헙 커밋하는 건 자고 일어나서 해야지...

아!!! 웹 접근성 너무 어렵다;

오열하는 짤

중요하다. 너무나 중요한 부분인 거 안다. 그치만...지금까지 이런 거 전혀 고려 안하고 마크업해왔는지라... 갑자기 신경쓰려니 너무너무너무 어렵다.😭😭
오늘 수업 듣는 내내 웹 접근성의 중요성만 점점 더 크게 느껴져서 공부 열심히 해야겠구나...싶었다. html css는 잘 모를 수록 쉽게 느껴지고 익히면 익힐 수록 어렵게 느껴지는 것 같음... html css 쉽다고 무시하는 사람 있으면 크게 꾸짖어야지...😅

하...그치만 너무너무 유익하다....하.... 무슨 울다가 그치만 유익해.... 근데 어려워.... 그치만 너무 중요해.... 벗... 나를 힘들게 해... 근데 또 일할 때 이런 거 다 고려하면서 마크업 해보고 싶어... 진짜 내 마음은 뭘까..? (밈입니다)


오늘자 갬성글
밥 먹고 집 들어와서 보리차 마시다가 갑자기
'와 근데 내 인생에 이렇게 뭔가 열심히 공부해본 적이 있나?' 이 생각이 들었다. 자의로 공부해본 기억은 당연히 없고, 공부하면서 즐거워본 적도 없다. 하지만 프론트엔드 준비가 그걸 해냅니다! (무기력하게 지냈던 어쩌고 기간은 마음이 힘들어서였으니 논외로 침ㅎㅎ;)

오늘 공부한 거 거의 없는 것 같아서 좀 침울했는데 이 생각과 동시에 기분이 제법 괜찮아졌다. 혼자 초조해 해봤자 공부 효율만 떨어진다. 간만에 찾은 즐거운 일인데 조급한 마음 가지지말고 침착하게 한 단계 한 단계 올라가자.😌


📌 오늘자 미세한 어쩌고
시간 날 때마다 웹 접근성 영상 보기(강사님 연구소 채널)

profile
TIL(거의 일기)위주. 공부한 것들은 정리해서 깃허브에 올리고 있습니다. 개인적으로 공부 중인 내용들이기 때문에 틀린 정보가 있을 수 있습니다.

0개의 댓글