디자이너를 위한 웹 성능 최적화 기법 감상후기

#1904B02

책 표지

읽으면 좋으실 것 같은 분들

지금의 웹 디자이너라면 알아두어야 기본적인 내용을 잘 알려주고 있는 책이라 생각됩니다.

책의 내용은디자이너이기 때문에 모른다고 말하기 이전에 디자이너이기 때문에 알아두어야 할 내용이라고 해두는 것이 좋을 것 같다는 생각이 들었습니다.

감상평

요새는 웬만한 규모의 사이트가 아니라면 이미지의 압축을 신경 쓰는 작업자가 과연 어느 정도일지 의문이 들기도 합니다만. 파일형식(JPG, GIF, PNG)을 크게 신경 쓰지 않는 경향이 있긴 한 것 같습니다. 이전에는 용량에 상당히 많은 관심을 두고 있었습니다. 책을 읽다 보니 그런식으로 작업하던 시간이 떠올랐으며 어느 순간 작업자인 저 역시도 편하면서 나쁜 방식을 따라 하고 있었다는 것을 떠올리고 뜨끔했습니다.

Base64 형식의 이미지의 경우에는 제대로 사용되고 있는 곳을 찾아보기 힘든 편이긴 한데요. 이미지를 코드로 관리한다는 관점에서는 좋지만, 소스의 코드가 길어서 다른 소스들과의 가독성 부분에서 좋지 않은 경험을 준다는 약점을 가지고 있기 때문이 아닐까 생각됩니다.

SVG는 갈수록 활용도가 높아지고 있어서 좋지만, 아직 국내시장에서는 IE 하위 버전을 강제적으로 대응해야만 하는 업종들이 많아 작업자들이 좋은 건 알면서도 제대로 사용해 볼 수 있는 환경은 아니라는 생각이 듭니다.(회피 방법이 없는것은 아니지만 말이죠) 이 부분은 CSS3의 애니메이션 부분도 비슷한 상태라고 할 수 있을 것 같습니다. 또한, 책에서도 나오는 내용이지만 HTML 파일의 크기가 커지는 경우와 이미지 파일을 캐싱하지 않는다는 부분은 고려의 대상이 되어야 하겠습니다.

창피한 이야기이긴 하지만 (업력이 오래되었다고 해도 모든 것을 전부 알고 있는 것은 아니라는 생각으로 지내고 있는 만큼, 솔직히 말해서) div의 과도한 사용을 지칭하는 'divitis'란 용어를 처음 접했습니다. 그냥 다중으로 되어 있어 복잡하니 요소에 맞추어서 적절한 태그를 사용하는 것이 좋다는 식으로만 얘기들을 나누었지 "이건 너무 divitis하니 바꾸어야 할 것 같다"라는 식으로는 대화를 나눈 적이 없었거든요.

마크업 단계에서는 어느 정도 정착되어 가고 있는 것이 CSS는 상단, SCRIPT는 하단이라는 공식이지만 실질적으로는 프로그램이 붙고 덩치가 커지며 작업자가 많아질수록 이런 형식은 거의 무시되고 있는 것이 현실이 아닐까 하는 생각이 들기도 했습니다.

이미지의 Sprite 방식 역시도 좋다는 것은 알지만 사이트의 규모에 따라 이 정도까지 신경을 쓸 여유가 없다는 식이 되게끔 중구난방으로 진행되기도 하기에 작업자(마크업 엔지니어)가 힘이 들기도, 귀찮기도 한 부분입니다. 제대로 된 규칙 하에 엄밀히 지켜가면서 작업이 현실에서는 제대로 동작하지 않는 경우가 꽤 있기 때문입니다.

저 역시도 프로젝트에서 몇 가지는 실제로 사용하고 있기도 합니다만 프로젝트의 가이드에 활용하면 좋을 것 같은 내용을 모아봤습니다.

이미지 최적화를 위한 가이드

1. 아이콘을 보여주기 위한 class의 규칙
2. 아이콘 사용 방법과 의미를 정의
3. 작업자가 많을 때 생길 수 있는 다양한 코드를 통일시킬 수 있는 일관성 있는 가이드
4. 브라우저 지원 범위의 명시

마크업 단계에서 최적화를 위한 가이드

1. 예를 들어 기본 글꼴을 줄 간격 1.4em에 크기를 14px로 잡았을 경우
2. 헤더의 글자를 기본 14px에서 비율로 조절한다
3. 마진과 패딩은 기본 1.4em에서 비율로 조절한다
4. 그리드를 직접 만들 때는 14px 이나 1.4em을 기반으로 증가시킨다

기타

1. CSS의 파일 크기는 30kb 이하를 목표로 하고 필요에 따라 사이트 전체, 페이지별로 준비한다
2. Script파일들은 async 태그를 적절히 사용한다
3. @media를 잘 사용해서 반응형 디자인에 적극적으로 활용하자

아쉬웠던 점

책의 예제 중 몇 가지는 IE를 지원하지 않는 예제들도 있습니다. 알아두면 좋지만, 국내 실정에서 IE를 무시하는 프로젝트를 접하는 경우는 소수에 해당하는 만큼 이를 해결하려면 또 다른 방법을 마련해야 하니 아예 사용 자체를 못 해보는 경우가 허다한 것 같다는 것이 개인적인 견해입니다.

실질적으로 작업을 해도 알아주는 사람은 동종업계에서도 극소수일 거라 생각되는 방법이 소개되기도 했는데요. 프레임워크 사용 시 버전이 올라갔을 때의 관리면 등 관리코스트가 늘어가는 관계로 프로젝트에서 사용하지 않는 소스의 삭제를 들 수 있을 것 같습니다. 뭐 상당히 이상적인 방법임은 틀림없지만, 현실적으로는 0.1kb에 해당할 수도 있는 부분에 에너지를 쏟아붓는 사람은 정말 극소수일 겁니다. 관리자 측면에서 보면 그런 쪽에 신경을 쓰기보다는 일정을 빨리 뽑아내는 것이 중요하다고 생각하니까 말이죠. 좀 아쉬운 현실이긴 합니다.