사실 이 내용은 프론트엔드 개발자를 위한 문제은행에서 답을 모르는 것들을 포스팅해서 기억해 두려고 발췌해 온 주제랍니다. 사이트는 아래를 참고해 주세요 ; )

👨‍💻 CSS 스프라이트(CSS Sprites)란?

🐵: 안녕하세요 : ) Kimgorilla 입니다. 오늘은 CSS 스프라이트란 무엇인지에 대해서 알아보도록 하겠습니다.

CSS Sprite 또는 CSS Image Sprite라고도 불리는데요, 여기서 이 Sprite라는 단어는 합성과 같은 의미로 쓰여지는데요. 직역을 해보자면 CSS 이미지 합치기(?) 가 되겠습니다.

왜 이미지 합치기라고 불리냐면 CSS image Sprite는 여러개의 이미지를 하나의 이미지로 합쳐서 관리하는 기술이기 때문입니다.

이해를 돕고자 친숙한 사이트 몇개를 선정해 실제로 사용중인 Sprite image를 가져왔습니다.

두 사진은 각각 네이버와 다음에서 실제로 사용중인 Sprite image 입니다.

🤔철수: "어? 그러면 html에서 image가 하나면 어떻게 불러다 사용해요? 저는 로고 하나만 필요한걸요?"

🐵: 
다 방법이 있습니다. CSS의 background 속성중에 background-image, background-position 와 우리가 원하는 로고의 크기 즉 width, height 속성만 있다면 Sprite image에서 특정 아이콘 부분만 사용하는것이 가능합니다.

마치 이런식으로 말이죠.

🤔철수: "다시 생각해 보니깐 굳이 이렇게 사용해야 하는 이유가 있을까요? 여러사진으로 보내는게 사용하기 편할꺼 같은데요.

🐵: 

이러한 방식으로 사진을 사용하는 이유는 사이트의 성능을 향상시키기 위함인데요. 사실 이전 포스팅에서 iamge spriting에 대해 살짝 언급을 했었습니다.

(브라우저가 한 번에 1개의 도메인에서...)

궁금하신분은 한번 보시면 좋을것 같습니다.

요약해서 말씀드리자면, 브라우저는 한번에 하나의 파일만 가져올수 있습니다. 그렇기 때문에 이미지 여러개를 요청하게 되면 그만큼 서버로 요청도 많아지게되고 요청이 많아지는 만큼 네트워크 지연도 많아지게 됩니다. 결국 페이지렌더링이 늦어지게 되는거죠.

그렇기 때문에 많은 사이트에서 HTTP 요청 횟수를 줄이기 위해서 로고나 아이콘과 같은 사진들을 하나로 합쳐서(Sprite) 하나의 이미지로 만들어 보내는 것입니다.

이러한 sprite image에서 특정 icon의 위치 찾는게 쉽지만은 않습니다. 그래서 이러한 sprite image 에서 특정부분을 사용하기 위한 css로 바꿔주는 여러 프로그램과 사이트들이 있는데요. 제가 소개드릴 사이트는 sprite cow 라는 사이트입니다.
http://www.spritecow.com/

사이트에 들어오셔서 원하는 이미지를 열어줍니다. 저는 네이버의 sprite image를 열었습니다.

 그리고 마우스를 이용해 원하는 로고영역을 선택해주세요.

그러면 아래에 해당 영역을 사용하기 위한 css가 나타내어지게 됩니다.

오늘 살펴볼 내용은 여기까지이구요. 궁금한점이나 피드백은 언제든 환영입니다. 댓글을 통해서 의견 남겨주시길 바랍니다 : ) 감사합니다.

사실 이 내용은 프론트엔드 개발자를 위한 문제은행에서 답을 모르는 것들을 포스팅해서 기억해 두려고 발췌해 온 주제랍니다. 사이트는 아래를 참고해 주세요 ; )

👨‍💻 Progressive rendering이란 무엇인가요?

🐵: 안녕하세요 김고릴라입니다 : )

오늘 포스팅할 내용은 점진적인 렌더링입니다. 이게 어떤건지 알아보도록 하겠습니다!

프로그레시브 렌더링은 서버에서 웹 페이지의 일부를 순차적으로 렌더링하면서 전체 페이지가 렌더링 될 때까지 기다리지 않고 웹 페이지를 클라이언트에 스트리밍하는 기술입니다.

즉, 콘텐츠를 가능한한 빠르게 표시하기 위해서 사용이 되는데요. 이를 이해하기 쉽게 하나의 예를 들어 보겠습니다.  

🤔 철수 :
"다른 사이트랑은 다르게 네이버는 메인 페이지에서 엄청나게 많은 데이터를 보여주고 있는데, 뭔가 더 빠르게 페이지가 로드되는거 같아"

🐵: 

위의 철수의 사례가 이해하기에는 대표적인 사례가 아닐지 싶습니다. 네이버같은 경우에는 메인페이지에서 보여주어야할 데이터가 정말이지 많습니다. 광고부터 뉴스 그리고 실시간검색까지 정말이지 많은 데이터를 받아오는데요. 이때 우리는 기타 다른 사이트와 동일한(?) 대기시간을 느낍니다. 그 이유는 네이버도 progressive rendering을 사용하고 있기 때문이라 볼수 있습니다. 네이버도 중요한 데이터를 먼저 받아와 랜더링하고 그 다음 덜 중요한 순으로 데이터를 보내주어 화면을 랜더링해주고 있기 때문입니다. 

눈에는 보이진 않지만 뒤에서 열심히 데이터를 받아 바로바로 화면에 보여주고 있는것이죠

점진적 렌더링 (일명 점진적 서버 측 렌더링 )은 서버 에서 중요한 컨텐츠를 렌더링 한 후에 중요 하지 않은 컨텐츠를 기다리지 않고 클라이언트로 스트리밍을 시작 하는 기술입니다. 

그런 다음 중요하지 않은 콘텐츠는 나중에 서버에서 렌더링되면 스트리밍합니다. 브라우저는 중요한 내용에 대해 먼저 렌더링을 시작하여 브라우저 화면에 그려줍니다. 그다음 브라우저가 서버로부터 컨텐츠를 수신하면 중요하지 않은 컨텐츠는 나중에 페이지에서 렌더링 (페인트)됩니다.

이 과정을 절차적으로 확인해 보도록 할게요.

1. 브라우저가 서버에 HTML을 요청합니다.

2. 서버는 API 요청을 수행하고 서버에서 중요한 컨텐츠를 먼저 렌더링하여 브라우저로 스트리밍합니다 .

3. 브라우저는 HTML 청크(덩어리) 를 받아서 화면에 렌더링 (페인트)합니다.

4. 서버는 중요 컨텐츠를 렌더링 한 후 중요하지 않은 컨텐츠 를 렌더링하고 이를 클라이언트로 스트리밍 합니다.

5. 브라우저는 나중에 중요하지 않은 컨텐츠를 받아서 렌더링 (페인트)합니다.

6. 전체 페이지가로드되면 브라우저는 일반적으로 이벤트 핸들러 및 기타 대화식 동작을 연결하는 DOM 요소에 대한 상호 작용을 수화합니다.

다음은 SSR vs PSSR로 렌더링 된 동일한 웹 사이트의 예입니다 . 사이트가 대기 시간이 긴 저 대역폭 네트워크를 통해로드되었다고 가정합니다.

Pers 프로파일 링 SSR과 PSSR 을 비교 하면 페이지에 컨텐츠가 얼마나 빨리 표시되는지 명확하게 개선 할 수 있습니다.

참고사이트 : 

https://medium.com/the-thinkmill/progressive-rendering-the-key-to-faster-web-ebfbbece41a4

🐵: 이와 관련된 기술에 대해 알아보도록 하겠습니다.

관련 기술 예시:

• 이미지 지연 로딩 - 페이지의 이미지를 한꺼번에 로딩하지 않습니다. JavaScript를 사용하여 사용자가 이미지를 표시하는 페이지 부분으로 스크롤 할 때 이미지를 로드 할 수 있습니다.

• 보이는 콘텐츠의 우선순위 설정 (또는 스크롤 없이 볼 수 있는 렌더링) - 가능한 한 빨리 표시하기 위해 사용자 브라우저에서 렌더링될 페이지에 필요한 최소한의 CSS/콘텐츠/스크립트 만 포함하면 deferred 스크립트를 사용하거나 DOMContentLoaded/load 이벤트를 사용하여 다른 리소스와 내용을 로드할 수 있습니다.

사실 이 내용은 프론트엔드 개발자를 위한 문제은행에서 답을 모르는 것들을 포스팅해서 기억해 두려고 발췌해 온 주제랍니다. 사이트는 아래를 참고해 주세요 ; )

👨‍💻 페이지 로드 시간을 줄이는 세 가지 방법에 관해서 이야기 해 보세요.

🐵: 안녕하세요 김고릴라입니다 : )

오늘 포스팅할 내용은 브라우저가 서버로부터 데이터를 받아 사이트를 로드시키기까지 걸리는 시간에 대하여 이야기를 해보고자 합니다.

😧철수 :
"한국장학 재단 사이트에 접속을 하는데 브라우저에서 사이트 화면이 나오기 까지 잠시 화면이 흰바탕 화면으로 보였어!"

🐵:

네 아주 자연스러운 일인데요, 우리가 특정 사이트를 접속할 때 종종 잠시 흰바탕의 화면이 나오는것을 볼 수 있습니다.

이러한 화면이 나오는 이유는 서버로부터 보내진 Html, Css, Js, jpg... 등 파일들이 아직 브라우저로 도착하지 않았기 때문에 발생하는 현상입니다. 

즉, 화면에 보여줄 데이터가 없어서 발생한거에요.

그리고 이러한 화면이 사라지기까지의 시간을 '페이지 로드시간' 혹은 '레이턴시', 대기시간 등으로 불립니다.

😧철수 : 그렇다면 이러한 대기시간을 줄이는 방법은 무엇이 있나요?

🐵:

일단 현재 대기시간을 줄이고자 하는 서비스의 형태에 따라 답변이 달라질 수 있을것 같습니다.

만들어진 웹서비스가 SSR 즉 서버측에서 화면을 모두 구성한 다음에 보내주는 방식의 서비스인가 또는 CSR 이라고 클라이언트 측에서 서버로 부터 데이터를 받은 후에 이를 가지고 화면을 구성을 하는가에 따라서 이러한 '대기시간'의 등장 빈도수가 달라집니다.

일반적으로 SSR을 따르게 되면 페이지에서 페이지로 이동시 전체문서 즉 Html 부터 CSS, JS까지 다시 요청해서 받아오게 됩니다. 그렇기 때문에 페이지 이동간에 '대기시간'이 계속 나타나게 되어지죠.

하지만 CSR을 따르게 되면 최초에 화면을 구성하기 위한 데이터를 받아오고, 이후 페이지 이동간에는 필요한 최소한의 데이터만 서버로부터 받아와 화면을 구성하기 때문에 SSR과는 다르게 '대기시간'이 매우 짧아지게 됩니다.(거의 안느껴지죠)

이렇듯 서비스 전체에 대한 총 대기시간을 줄이고자 하는것이 목적이라면 이렇게 CSR형태로 개발하는 방법이 답이될 수 있겠습니다.

😧철수 : 그렇다면 CSR로 개발하면 무조건 효율적인건가요?

🐵: 

그렇지 않습니다. 

사실, CSR은 초기 도입시에 대한 대기시간(페이지로드시간)이 SSR형태의 서비스에 비해 깁니다.

그 이유는 CSR이 화면을 구성하기 위한 데이터를 미리 다 받아두고 이후 페이지 변화간에 기존에 받아두었던 데이터를 재 활용해서 화면을 구성해주기 때문입니다. 미리 데이터를 다 받아두기 때문에 서버로 부터 받는 데이터 크기 또한 다를 뿐더러 화면을 구성하기위해 JS코드를 해석하는등 이러한 추가적인 시간이 생기게됩니다.

이러한 상황에서는 우리가 최초 페이지 로드시간을 줄이는 방법은 여러가지가 있습니다.

일단 개발자를 이용한 개선방법부터 알아보겠습니다.

받아온 데이터를 해석하는데 걸리는 시간을 줄이기 위해서 평소 개발시 불필요한 코드를 정리하는 습관을 들이거나, 최대한 심플한 코드를 짜는 습관을 들이는 방법이 있겠습니다.

다음은 네트워크 측면에서 방법을 찾아보겠습니다.

서버로부터 보내진 데이터를 받기까지의 걸리는 시간 때문에도 대기시간이 생깁니다. 이러한 상황은 서버로부터 데이터를 빠르게 받는 방법을 통해 대기시간을 줄일 수 있는데요.

그 첫번째 방법으로는 단순하게 네트워크 속도 그 자체를 빠르게 만들어 주는겁니다. 하지만 이러한 방법은 개발측면에서 할 수 있는것이 아니기 때문에 쉬운 방법은 아닙니다. 

두번째 방법으로는 서버로부터 보내는 데이터를 최대한 작게 만들어서 보내주는 방법이 있습니다. 개발이 완료된 소스코드의 들여쓰기나 빈 여백공간과 같이 소스코드 열람시 개발자의 가독성을 위한 데이터 부분들을 제거하는 등 소스코드 자체를 압축시키는 방법이 있습니다. 

세번째 방법으로는 gzip을 이용한 전송데이터 압축인데요. 전송하고자 하는 데이터를 압축시켜서 전송시켜주고 이를 클라이언트가 받아서 압축을 풀어 사용하는 방식입니다. 이 방식은 데이터 크기 자체를 줄여 전송시켜주기 때문에 도착까지 걸리는 시간이 적습니다. 하지만 클라이언트가 압축을 해제후 사용해야 하기 때문에 크기가 다소 작은 데이터를 보낼때는 효율이 좋지 않을 수 있습니다.