워드프레스 빠르게 하기

[ 이글은 2018년 06월 13일에 최종 수정되었습니다. ]
§

일단 웹사이트의 속도를 결정하는 요소는, 웹사이트 마다 다르지만, 대략적으로 서버성능이 7~80%, front-end scripting 구조 가 2~30% 정도의 영향을 끼친다고 볼 수 있습니다.

서버의 성능을 높히고 최적화 하는 작업을 통해 사이트 속도를 높힐 수 있지만, 대다수 소규모 웹사이트의 경우 웹호스팅 회사를 통해 사이트가 호스팅 되고 있는게 현실 입니다.

그래서 서버성능이나 세팅, 또 Nginx 같은 사이트 속도에 유리한 서버사용이 불가능 한 경우, 차선책으로 최대한 front-end 에서 속도를 높혀주는 수 밖에 없습니다.

워드프레스 는 크게 보면 워드프레스 core 파일에 테마와 플러그인이 얹혀진 형태 입니다. 당연히 테마의 속도를 빠르게 하면 사이트 속도도 빨라집니다.

워드프레스_구조

1. 테마 속도 높이기

일단 테마의 모습을 한번 살펴 봅시다.

wp_layout

크게 나눠서 헤더, 사이드바, footer, (한국어로 쓰려니 “뿌..” 어감이 좋지 않아서. ㅎㅎ), 그리고 loop 되서 보여지는 컨텐츠 area 로 나눠져 있습니다. 경우에 따라서 여러개의 사이드바가 달려있을 수 도 있고, 없을수도 있고, footer 가 없을 수 도 있습니다.

헤더

시판되는/공유되는 테마를 보면 사이트 로고 나 로그인 같은 부분에 단순한 링크를 걸기위해 php 를 사용해 relative path (상대경로) 를 이용 하는데 (테마가 어느 사이트에서나 작동될 수 있기 위해 어쩔수 없죠.) 이 부분을 모두 absolute path (절대경로) 로 대체하여 php 사용을 줄여 줍니다.

왜 php 사용을 줄여야 하는가?

a. 서버의 부담을 덜어주기 위해서 입니다.
b. html 은 항상 php 보다 빠릅니다.

메뉴

php 로 생성되는 메뉴/메뉴들을 html 로 대체합니다. 헤더와 footer 등에 걸려있는 메뉴에 자주 변동사항이 없는 경우 (사이트가 완성된 경우), 워드프레스를 통해 메뉴를 생성하지 말고, html 로 메뉴를 짜 넣습니다. 물론 기본적인 html 과 css, 혹은 javascript 에 대한 이해가 있어야 가능한 작업입니다.

사이드 바

경우에 따라서 (use case 가 가능한 경우) sidebar 부분역시 html 로 대체 합니다. 단순한 제품이나 서비스 관련 광고 배너를 걸어 놓는 용도로 사이드바를 사용하는 경우가 많은데, 이런경우 사이드바를 워드프레스에서 생성할 필요가 없습니다.

*물론 이 작업들을 하기전, 내가 사용하려는 테마가 어떻게 만들어졌는지를 먼저 살펴볼 필요가 있습니다. 테마 프레임워크를 사용한 무거운 테마는 아닌지, 페이지 빌더 같은 쓸데 없는 기능이 달려 있지는 않은지 확인해 봐야 합니다. 한 예로 ftp 를 사용할 줄 알고, 기본적인 html 에 대한 이해가 있다면, 로고이미지 하나를 바꾸기 위해, 테마 기능을 사용해야 할 필요가 전혀 없습니다.

Footer

Footer 역시 html 로만 만들어질 수 있습니다. 보통 footer 에서 사용하게 되는 copyright 연도를 php 로 보여주는데 <?php echo date("Y"); ? > 이 부분은 javascript 으로 대체할 수 있습니다. <script >document.write(new Date().getFullYear())</script >

Footer 에 포함되는 메뉴 역시 위에서 설명드린데로 사이트가 완성된 후, html 로 작성하시면 됩니다.

여기서 의문하나. php 대신 javascript 을 쓰면 오히려 로딩속도가 더 늦어지는게 아닌가?

그렇지 않습니다. php 는 서버에서 가동되는 것 이지만, javascript 은 방문자의 브라우져를 가동시키는 것 입니다. 따라서 동접자가 100명인 경우, 내 서버는 100번 php 를 execute 하게 되지만, javascript 은 각 방문자의 브라우져에서 한번만 execute 됩니다. 동접자가 많을수록 javascript 을 쓰는 것이 로딩속도에 이득입니다.

2. 플러그인

많은 수의 플러그인 코드를 살펴보면, 플러그인 자체의 기능보다 사용자 옵션을 위해 짜여진 php 스트립트 부분이 훨씬 더 많습니다. 이런 옵션들은 한번 설정하면 그만인데, 그 한번 설정하는 옵션때문에 많은 수의 query 가 발생합니다. 플러그인을 사용해야 한다면, 플러그인을 site specific 플러그인 화 해서 사용합니다. 가능하다면, 내가 직접 그 기능을 짜서 사용 합니다.

슬라이더 플러그인의 예를 들자면, 웹디자이너 수준의 html 과 css, 그리고 js 를 이해한다면 (슬라이더가 js 를 쓰는 경우) 슬라이더 플러그인을 사용하지 않고, 직접 슬라이더를 작성해 사이트에 적용할 수 있습니다. (개인적으로 슬라이더를 하나 만들어 붙이는게 복잡한 슬라이더 사용설명을 읽고 적용하는 것 보다 더 시간이 적게 걸립니다.)

3. 사이트 Asset 관리

사이트에 로딩되는 front-end asset 들을 살펴보면 그 크기가

이미지 >>>>>>>>>>>>>>> javscript >>>>>> css 순서로 이미지 파일의 크기가 압도적 입니다.

asset_management

이미지 하나가 사이트 전체를 담당하는 css 보다 더 느리게 로딩되고 있음을 볼 수 있습니다.

테마의 UI 를 담당하는 버튼같은 경우, raster 이미지 사용을 하지말고 (jpg 나 png 를 쓰지 말라는 것 입니다), 파일사이즈가 작은 vector 이미지나, 아이콘 폰트, css 등으로 대체 합니다. *물론 내가 svg 같은 vector 이미지를 만들 수 있는 아도비 일루스트레이터 같은 프로그램 사용을 할 줄 모른다면 이 역시 가능한 작업이 아닙니다.

*이글을 읽고 있는 분이 웹디자이너라면 svg 를 적극적으로 사용하십시오. 잘알고 계시겠지만, svg 는 vector 라서 이미지를 아무리 크게 키우더라도 깨짐 현상이 나타나지 않습니다. 고로 16pt X 16pt 정도의 매우 작은 svg 파일을 페이지 전체를 덮는 이미지로 사용하더라도 이미지가 깔끔하게 구현됩니다. (페이지 로딩속도는 빨라지고, 이미지는 어느 기기에서나 더 샤프하게 구현되고. 1석2조 인 것 입니다.)

HTTP Request 숫자 줄이기

js 이건 css 이건 이미지 파일이건, 브라우저가 한번에 fetch 할 수 있는 파일 숫자는 다음과 같습니다.

Firefox 3+: 6
Opera 9.26: 4
Opera 12: 6
Safari 3: 4
Safari 5: 6
IE 7: 2
IE 8: 6
IE 10: 8
Chrome: 6

예를들어 크롬의 경우 18개의 파일을 페이지로 불러와야 한다면 6개씩 세번에 걸쳐 파일을 불러와야 합니다. 그리고 이 프로세스가 많이 질수록 로딩 속도가 늦어 집니다.

따라서 이미지를 써야 한다면 가능한 경우 inline 으로 적용하는것이 속도 향상에 도움이 됩니다. 이미지의 파일크기가 작은경우 base64 encode 를 하는 것 도 좋은 방법입니다.


위 방법들은 워드프레스 자체에 관련된 내용이라기 보다, 기본적인 사이트 구축및 관리에 대한 내용이 대부분 입니다.

결국, 워드프레스가 느려지는 이유는 워드프레스 자체의 문제라기 보다는 html 과 css, 또 이미지 등이 사이트에 어떻게 적용이 되고 로딩속도에 어떤 영향을 끼치는지에 대한 기본적인 상식이나 개념이 부족해서임을 알 수 있습니다. 워드프레스가 느린게 아니라 사용하시는 테마나 플러그인이 느린 것 입니다.

명언

그럼에도 왜 대다수의 웹사이트들을 보면 front-end 가 엉망인가?

한국에 국한된 문제가 아닙니다. front-end 개발자가 턱없이 부족하기 때문입니다. front-end 개발자는 기술적으로 깊게 들어가지 않지만, 대신 알아야 할 영역 과 구사해야하는 여러가지 technique (기법) 들이 상당히 많습니다. 1~2년 정도 경력을 쌓아서 모두 터득할 수 있는 수준이 아닙니다. 그래서 대다수 소규모 사이트들의 front-end 는 엉망이고, 사이트가 느릴 수 밖에 없는 구조로 구축됩니다. 여기다 호스팅까지 웹호스팅을 쓰니 총체적 난국이 되어버리는거죠.

프론트엔드 개발자는 왜 구하기 어렵나요? : 참조하실 분들은 참조하세요. 어떻게/왜 미국에서는 front-end 개발자들이 프로그래머 보다 더 높은 임금을 받고 일하는지 납득하지 못하는 한국 개발자분들이 계시더라구요.

워드프레스가 우수한 점은, XE 나 드루팔과는 달리, front-end 를 내가 수정하는 것이 그리 어렵지 않다는 점 입니다. 하지만 이 front-end 까지 깔끔하게 정리해 줄 수 있는 솔루션은 지구상에 존재하지 않습니다.

워드프레스를 옹호하는 것 이 아니라, 아무 탓도 없는 워드프레스를 내 사이트가 느린 이유 나 대상 (culprit) 으로 지목하는 것은 옳지 않습니다.

‘나는 이런거 하나도 할줄 모른다. 그런데 플러그인은 많이 쓰고 싶고, 사이트 속도는 빨랐으면 좋겠다.’ 라는 희망을 갖고 계신 분이라면 그 해결책도 워드프레스 내에 존재 합니다.

a. 실력있는/시간많은 front-end 개발자 고용하기
b. Cache 플러그인 사용하기 (https://wordpress.org/plugins/w3-total-cache/)

cache 플러그인을 썼는데도 속도가 만족스럽지 않다면, 그게 현실이고, 그 현실에 수긍해야 합니다.

*개발자라면, 개발하실때, query 모니터, debugging 툴등을 사용하여, 내가 짜고 있는 script 이 bottle-neck 을 유발하지는 않는지, 로딩속도에 악영향을 끼치지는 않는지 확인해 가며 개발을 한다면 쾌적한 속도를 자랑하는 사이트 구축이 가능합니다.

Query Monitor

Debug Objects

hackya 는

Attorney, front-end developer, digital media artist, WordPress enthusiast, & a father of 4 wonderful children.

Tags: , ,

카테고리: , , ,

Ω

28 Comments

  • 지윤 says:

    정말 좋은 글이네욥!! 이글 퍼가도 되나요?

    • Matthew says:

      네. 퍼가셔도 되고, 가급적이면 출처를 밝혀주시면 감사하겠습니다. 제 글을 퍼가서 “짜집기” 식으로 다시 re-post 하시는 분들 보면 기분이 썩 좋지는 않더라구요.

  • 좋은 정보 공유해주셔서 감사합니다. 역시 메튜님은 옆구리(?)를 한번씩 찔러줘야 뭐가 나온다니까요? ㅋㅋ

    위에서 열거한 방법들을 예전부터 시행해볼까 했는데… 게으름 때문에(스파라이트, CSS아이콘 등), 그리고 현재는 학습 차원에 있는 관계로 PHP 를 HTML 코드로 전환을 하지는 않았습니다.

    그리고, 아래와 같은 의문점이 있어 망설이기도 했구요.

    1) 많은 이미지를 SVG로 대체하여 인라인 인코딩해서 사용할 경우, html 의 용량이 높아져 모바일 환경에서는 좋지 않은걸로 알고 있습니다.(모바일 캐시 용량 문제 어쩌고 저쩌고 그랬던거 같아요) 그래서, 제한적으로 사용해야 하는걸로 알고 있구요.

    그런데, “이미지를 써야 한다면 가능한 경우 inline 으로 적용하는것이 속도 향상에 도움이 됩니다.” 라고 말씀하셔서… 위의 내용이 상관이 없는것인지 궁금합니다.
    2) 그리고, SVG 같은 경우 IE 하위 버전에서 지원이 안되는걸로 알고 있는데, 인코딩하면 그런 문제는 없는것인지요?
    3) 만약 브라우저 호환성 문제가 있다면, 스크립트(또는 CSS)에서 지원이 안되는 경우 jpg, png 등으로 분기를 하면 되긴 하겠는데… 이미지가 한두개도 아니고 어떻게 해야 할지 조금 망설여 집니다. (CSS 아이콘으로 대체하면 많이 줄어들겠지만요)
    4) 그리고, PHP 를 HTML 로 대체했을때… 또는 플러그인에서 필요한 소스만 쏙~ 빼다 썼을때, 단기적인 효과는 있겠지만 장기적으로 봤을때는 조금 문제가 있어 보입니다.
    물론 사용자 입장에서 얘기 드리는거예요.
    ㄱ. 플러그인 같은 경우… 그런식으로 만들어서 사용자에게 제공하면 업데이트(기능 향상)를 제대로 받을 수가 없고, 나중에는 워드프레스 버전업에 따라 호환성 문제도 생길 것 같은데 이 부분은 어떻게 생각하시는지요?
    ㄴ. 본문에서 얘기한것처럼 PHP 를 HTML 과 CSS 로 구현했을 경우… 헤더, 사이드바, 푸터 등은 이제 고정이 되어 버리니, 이것 역시 장기적인 관점에서는 스스로 업데이트/확장 가능성을 버린것 처럼 보이는데요…
    물론 개발자 같은 경우는 쉽게 수정이 가능하지만… 컴맹 수준에 가까운 일반 사용자들에게는 워드프레스의 장점을 포기한 것과 같아 보입니다.
    ㄷ. 저보다 더 잘아시겠지만… 클라이언트의 요구사항은 수시로 변하고, 웹 트렌드 또한 수시로 변하므로 속도만을 위해 확장성(?)을 포기하는 것은 장기적으로 안 좋아 보이는데 이 문제에 대해서는 어떤 의견이신지요?
    ㄹ. 아니면… 일반 사용자들은 뭔가 추가할때마다 돈을 들여 의뢰할 수 밖에 없는 것일까요?

    • Matthew says:

      svg 는 거의 모든 브라우저에서 지원됩니다.

      http://caniuse.com/#feat=svg

      svg 는 이미지 파일과 비교해서 1/10 정도로 파일크기가 작습니다. 그래서 inline 적용을 해도 오히려 html 전체 크기가 줄어듭니다, 더 커지는게 아니라.

      테마는 직접짜는게 가장 좋은 방법입니다. 업데이트 걱정할 필요가 없으니까요. 하지만 직접 테마를 짜서 쓸수 있는 분들이 많지 않고. …

      제가 공유한 테마도 보시면 headerBK.php 처럼, 같은 내용인데 하나가 “BK” 가 붙은 backup 파일임을 보실 수 있습니다. 원판 그대로인 파일을 BK 로 만들어 놓고, header.php 를 하나 더 만들어서 고치는 방식입니다. 그래서 나중에 테마가 업데이트 되면 업데이트를 받을 수 있습니다. 또 다른 방법은 header.php 를 header.html, 혹은 header2.php 식으로 이름을 바꿔서 index.php, single.php 등에서 이 header.html 이나 header2.php 를 불러오는식으로 구축하면 업데이트 받는데 문제가 생기지 않습니다. sidebar 도 같은식.

      확장성을 버리는게 아닙니다. sidebarBK.php 가 남아 있으니까요.

      css sprite 은 http request 숫자를 줄여준다는 잇점때문에 몇년전만해도 저도 쓰는 방식이었지만, 지금은 아무도 안쓰다시피 합니다. (유지보수가 까다롭고 시간이 많이 걸리기 때문에 효율적이지 않습니다.)

      “사용자에게 제공하면” – 플러그인을 공유를 해야 하는 입장이면 사이트 최적화는 버릴 수 밖에 없습니다. 모두가 사용가능한 플러그인이 각 사이트에 맞춤옷처럼 맞을 수 가 없죠. 맥도날드 빅맥이 빅맥을 사먹는 사람들 각각의 입맛에 맞춰서 만들어질 수 없는 것과 같은 맥락 입니다.

      일반 사용자들은 뭔가 추가할때마다 돈을 들여 의뢰할 수 밖에 없는 것일까요? – 그건 전적으로 그 일반인의 실력수준 문제 입니다.

      XE 나 그누보드로 사이트를 구축할 수 있는 수준의 일반인분들은 워드프레스 가 너무 쉬워서 그냥 웃음만 나온다고들 하십니다.

      • “svg 는 이미지 파일과 비교해서 1/10 정도로 파일크기가 작습니다. 그래서 inline 적용을 해도 오히려 html 전체 크기가 줄어듭니다, 더 커지는게 아니라.”

        고 말씀하셨는데… 이미지 크기는 줄어들겠지만(사실 비교도 안되죠, 이미지가 없으니) html 용량은 커져야 한다고 봐야하는거 아닌지요?

        그런데, 예전 스터디때 SVG 언급을 하시길래 관련 정보를 찾아봤는데, 모바일에서는 단일 캐시 용량에 제한이 있어 html 이 일정 수준 넘어가면 캐시가 안된다고 본 것 같아서요. (가물가물, 링크도 못 찾겠음)

        잘 몰라서 여쭤보는 겁니다. ^^;;

        공유해주신 테마는 제가 아직 자세히 살펴보지 않아 xxBK.php 가 있었는지 못 본것 같습니다. 그런데, 테마야 그렇다 치고 플러그인은 어떻게 해야 될까요?

        XE, 그누보드로 혼자 사이트를 구축할 수 있는 사람이라면 일반적인 관점에서 논할때 컴맹 같은 일반인들은 아닌 것 같습니다.

        일반인들 수준이 모두 그 정도면 국내 웹에이전시 굶어 죽지 않을까요? ^^;;

        메튜님 관점에서는 사용자 수준인지 몰라도, 국내에서는 개발자(또는 준개발자), 퍼블리셔 등등으로 불리는 수준인것 같아요. ㅠㅠ

        에효~ 초보자 수준에서 물어보자니 여러모로 많이 어렵네요…

        • Matthew says:

          브라우저 마다 파일크기 제한이 있습니다.

          http://www.html5rocks.com/en/tutorials/offline/quota-research/#toc-mobile

          그런데 raster image (ex. jpg, png) 를 쓰고 있으면서 svg 때문에 문서 파일크기가 늘어날 걱정을 하는건, 덤프트럭을 타고 출퇴근 하는 사람이 ‘아, 이 덤프트럭을 Scion iQ (이 차가 가장 작은 소형차라고 하네요) 로 바꿨을때 연비가 늘어나지 않을까? 같은 걱정을 하는 겁니다. ㅋㅋㅋ

          “국내 웹에이전시 굶어 죽지 않을까요? ^^;; ” – 많이들 없어지고, 사라지고, 망했죠. (그리고 그분들 지금 열심히 치킨 튀기고 계신다는.. 이게 지금 농담이라고 생각하시죠? 아니거든요.) 원래 웹에이전시란 자체적 기술이 있는게 아니라 일을 따서 하청을 주는 업체를 웹에이전시 라고 합니다. (이게 한국은 10단계까지 내려가는 일도 있습니다. 구글링해보시면 무척 재미있는 글들을 찾으실 수 있으실겁니다. ㅎㅎ)

          그리고 돈버는데 기술따위는 전혀 필요없어요!!! 모르셨나요? ㅎㅎㅎ 연줄만 관공서 같은곳에 있으면 돈버는데 아무런 문제가 되지 않습니다.

          한국 사시는 분이 저보다도 실정을 잘모르시면, 어쩌죠? >.<;;

          *요즘 미국도 웹으로 돈을 버는 업체들 보다, 워프+SaaS 라던지, 앱개발 등으로 돈버는 업체가 월등히 많습니다.

          사실 지금 무진장 좋은, 한국에서 무조건 되는, 워프+SaaS 아이디어/사업모델 2개가 있는데, 이걸 글로 쓰다가 말았습니다. 제가 직접하려고. ㅋㅋㅋ Angel investor 를 찾아도 되는데, 그냥 지금 사업체에서 돈을 좀 끌어모아서 내년쯤 시작해보려구요. ㅎㅎ

          일단 열심히 일해야 돈이 모이겠죠. ㅠㅠㅠ 아.. 일하기 싫다…

          • 1) 제가 예전에 어디선가 봤던 링크를 못찾아 Data URI Performance 로 검색해 보았어요. 아래 링크를 보시고, 조금 더 설명을 해주실 수 있으신가요? (번역을 해도 제대로 의미를 파악 못해… 메튜님의 말과 뭔가 틀린것 같은데 비교가 안되요)

            http://www.mobify.com/blog/data-uris-are-slow-on-mobile/

            http://www.mobify.com/blog/base64-does-not-impact-data-uri-performance/

            2) 웹에이전시에 대한 얘기가 아니였는데, 이상한 방향으로 주제가 흘러갔네요? 그리고, 저는 IT 관련 일을 실제 해본적이 없으니…. 어디 살든 말든 치킨(?) 튀기는것 같은 속사정이야 제가 알 수 없는 일이죠. ㅋㅋ

          • Matthew says:

            “이미지의 파일크기가 작은경우 base64 encode 를 하는 것 도 좋은 방법입니다.” 제 본문글과,

            Web engineers like Barbara Bermes of the CBC are using data URIs in exactly the right way: for small, frequently used graphics, and measuring the performance impact of each change to her web content.

            저 블로그에 나와 있는 내용과 다르지 않은데요.

            한글도 독해력이 썩 좋지는 않으신듯. ㅎㅎㅎ 농담입니다, 농담.

            Paul Irish 가 하는 말이 곧 법입니다.

            https://plus.google.com/+PaulIrish/posts/JEHnUSQnrqJ

            1kb 을 기준으로 inline 해라. (물론 실제 테스트 해봐야 합니다. 어느쪽이 더 유리한지.)

            저 블로그에서 테스트한 파일 사이즈를 보세요. 무려 17.6kb 입니다. Paul Irish 가 1kb 선으로 기준을 잡으라고 했는데 17배가 넘는 파일로 테스트를 하면서 멍청한 소리를 하고 있습니다.

            그래서 아래 비판글들도 많이 달려있고.

            그리고 벌써 2년전 내용이라 신뢰 할만한 정보도 아닙니다. 저때만 해도 css sprite 쓰던 때라 css sprite 쓰라고 하고 있지 않습니까?

            그리고 저도 하나 지적하자면, 저 테스트는 파일로딩속도만 보고 있지, http request 가 줄어듬으로 해서 얻어지는 이익은 계산을 하지 않고 있습니다.

          • Matthew says:

            그리고 이글도 보세요.

            http://www.mobify.com/blog/base64-does-not-impact-data-uri-performance/

            바보같은 소리를 하니까 바로 까이지 않습니까?

            >SVGs appear to be quite slow on mobile

            Try setting image size in both css and svg.

            It’s a known issue:

            1. SVG rasterizer renders image with “unlimited size” taking a lot of time
            2. Browser looks up svg image size and what css tells him
            3. Browser re-renders svg

            svg 가 실제 어떻게 적용되어야 하는지도 모르고 무작정 테스트를 한겁니다.

          • 1) 난독증이 있어 죄송합니다. “이미지를 써야 한다면 가능한 경우 inline 으로 적용하는것이 속도 향상에 도움이 됩니다.” 에서 가능한 경우를 잘못 해석했고, 그 밑에 있는 문장은 읽지도 못하고 넘어갔네요. ㅠㅠ

            2) 링크의 글들이 그런 내용의 글이었군요. 크롬 브라우저로 번역을 해서 읽어도 당췌 뭔 소린지 모르겠고… 그냥 “base64 encode 방식이 뭔가 문제가 있구나” 라고만 생각했어요. 그래서, 둘중에 하나를 선택해야 했죠. 모든 이미지를 변환하든가 포기하든가. ^^;;

            3) 잘 모르고 있던 부분을 일깨워 주셔서 감사합니다. 정말… 현직 프론트엔드 개발자 포스~ 짱입니다. ㅎㅎ

          • Matthew says:

            저 현직 아닙니다. ㅎㅎㅎ
            정확하게 얘기해서 제 회사의 project manager 역활을 하고 있습니다. ^^;;

            회사가 영세하다보니 코딩도 직접하는 경우가 많다는게 함정이지만. ㅋㅋㅋㅋ

            물론 좋은점도 있습니다. 공부할 시간도 많아지고, 예전에 계약직으로 일할때 처럼 하루에 몇줄은 작성해야 한다는 암시적인 pressure 같은걸 주는 사람도 없고…

          • 그래도, 제 눈에는… 아주 높은(실력이) 곳에 있는 분 같습니다. 부러우면 지는건데… ㅠㅠ

  • codei says:

    스크립트로 뽑아주는 시간은 클라이언트 브라우져의 시간입니다. 정확하지 않아요 ㅎㅎ
    그리고 한국은 프론트엔드 개발자 자리가 많지도 않고, 전반적인 포지션도 썩 좋지 못 합니다.
    만능 주의 한국!

    • Matthew says:

      네, 전세계에서 유일하게 웹퍼블리셔라는 직업군이 있는것만 봐도 한국 웹생태계가 어느 정도인지 알 수 있죠. 미국에서 가장 기초직업군인 웹디자이너를 한국에서는 퍼블리셔라고 하고, 정작 한국 웹디자이너는 이 퍼블리셔가 하는일을 이해 하지도 못하는…

      닭이 먼저인지 계란이 먼저인지 말하기 어려운 내용이지만,

      한국 front-end 개발자들 기술 수준이 낮아서 높은 급여를 받지 못하는건지, 높은 급여를 받지 못하니 기술이 떨어지는건지, 에매모호 합니다.

      삼성같은 대기업이 국내에서 front-end 개발자를 찾지못해 영국계 개발회사에 의뢰해서 사이트를 꾸미는걸 보면, 한국 front-end 개발자들 기술수준이 낮다고 할 수 있지만, 반면 평소에 고용주들이 급여를 제대로 지불하지 않아서 기술이 낮아진거라고 볼 수 도 있는 문제거든요.

  • css sprite 관련 질문 드립니다. ^^;;

    “css sprite 은 http request 숫자를 줄여준다는 잇점때문에 몇년전만해도 저도 쓰는 방식이었지만, 지금은 아무도 안쓰다시피 합니다. (유지보수가 까다롭고 시간이 많이 걸리기 때문에 효율적이지 않습니다.)” 라고 말씀해 주셨는데…

    css sprite 를 안 쓰는 이유는 작업의 비효율성과 유지보수 문제점 뿐 인가요? 아니면 다른 성능상의 이슈 같은 것이 있기 때문인가요?

    • Matthew says:

      css sprite 은 만들기가 무지 쉽습니다. 구글링 하면 수도 없이 나옵니다.

      http://spritegen.website-performance.org/

      http://wearekiss.com/spritepad

      브라우져에 extension 만 달아도 마우스 클릭 한번으로 생성되는게 있었는데… 오래전이라 없어졌는지..

      암튼, 그럼에도 불구하고,

      몇년전 부터 거의 모든 사람들이 쓰지 않게된 이유가, 비효율성/유지보수 문제 이외, 반응형 웹디자인 때문입니다. 물론 css sprite 을 반응형으로 만들수는 있습니다. css sprite 을 container 에 담고, 그 container 를 반응형으로 만드는거죠.

      여기서 생기는 문제점들 :

      1. 아시겠지만 css sprite 은 한개의 이미지 파일입니다. 이걸 반응형으로 구사해봤자, 각 기기들에서 조금씩, 혹은 많이 어긋나게 됩니다. 그럼 또 각 모바일 기기에 맞는 css sprite 을 추가로 만들던가, css 를 추가로 작성하던가 해야 하는데, 업무량도 많아질뿐더러 만족스러운 결과를 얻기 힘듭니다.

      (그래픽디자이너들은 이 사실을 잘 알고 있지만 랭커님은 모르실 수 있어서 : raster 이미지 파일은 크기를 늘려도 깨지는 현상 (pixelate) 이 발생하지만, 이미지를 줄여도 샤프함이 사라지고 무뎌집니다.) – 이런 문제도 발생합니다.

      2. 각 이미지를 optimize 해줄 수 없게 됩니다. 모바일 뷰에서는 작은 png 파일이 더 유리한데, 이게 desktop (PC) 에서는 svg 가 더 속도면에서 유리한 case 가 생깁니다. 아니면 같은 png 파일이라도 모바일 뷰에서는 작은 이미지, PC 뷰에서는 큰 이미지 – 이걸 이미지 대체기법이라고 합니다. view 마다 다른 이미지를 보여주는게 보편적인/근대적 방법인데 css sprite 에서는 이걸 어떻게 처리하죠? 이렇게 하려면 css sprite 를 버려야 합니다.

      3. http request 는 줄지만, 오히려 이미지 사이즈가 커져서 로딩속도가 더 늘어나는 case 도 존재합니다. http request 가 총 12번인데, css sprite 을 써서 이걸 7번으로 줄였다. 여기서 얻어지는 잇점은? 없습니다. 오히려 로딩속도만 늘어나죠.

      4. 이미지를 background-image 로 사용해야 하는 경우와, element 로 사용되어야 하는 규칙이 존재합니다.

      http://stackoverflow.com/questions/492809/when-to-use-img-vs-css-background-image

      그럼 background-image 로 적용된 이미지만 css sprite 을 써야 하는데, 이게 또 웃기는 거죠/별 도움도 안되는 케이스가 발생하죠.

      어떤 기법이 생겨났다 사라질때는 분명히 그럴만한 이유가 있기 때문입니다. css sprite 은 예전에 이미지를 많이 써서 웹사이트를 구축하던 시절에, 또 반응형 디자인 기법이 생겨나기 전에 유용했던 기법이지만, 근대 웹사이트 구축 기법과 맞지 않습니다.

      • 그런 이유가 있었군요…

        말씀하신대로 css sprite 를 자동으로 생성해주는 사이트들도 많은데, 왜 효율성/유지보수 측면에서 좋지 않다고 하시나… 궁금했습니다.

        말씀하신 문제점 까지는 생각치 못하고, 제 사이트의 경우… 메뉴(네비게이션)에 들어가는 아이콘들은 어떻게 sprite 를 적용해야 할까 고심하고 있었습니다. (뷰가 달라지면 아이콘들이 제 멋대로 ㅋㅋ)

        그리고, img 와 background 사용 용도에 대한 개념도 조금 잡힌 것 같습니다.

        감사합니다. 메튜님께 상담료(?) 비슷한거라도 드려야 될 듯… ^^;;;

        • Matthew says:

          요즘은 아이콘을 svg 나 css 로 (혹은 아이콘폰트) 로 작성하는 경우가 대부분인데, 예를 들어 검색버튼 (확대경 아이콘) 을 css 로 작성해보면 간단하게 만들어도 이게 1kb 까지 사이즈가 나옵니다. (element 딱 2개 써서 만들었는데 그렇더라구요.) 반면 svg 는 1kb 이하로도 만들 수 있거든요.

          무슨 얘기냐 하면, 전부다 케바케고 어떤 정답이 없다는거죠. 경우에 따라서 css 가 유리할 수 도 있고, svg 가 유리할 수도 있고, 그렇습니다.

          하지만 어떤 경우에도 아이콘을 raster 이미지로 만드는거는, 이게 색상수정도 불가능하고, 크기 수정도 제약이 있고 (모바일에서 깨끗하지 않게 보여지는 문제), 좋은/근대적 방식은 아닙니다.

          • 감사합니다. 덕분에 이미지 관련해서는 모든게(제 수준에서) 명확해 진 것 같습니다. 꾸벅(인사드림)… 으로 밖에는 표현할 말이 없네요. ㅠㅠ

          • Matthew says:

            무슨 아이콘 말씀하시는가 해서 살펴봤는데, googleusercontent.com 에서 이미지 호스팅 하시면 이미지 깨지는건 알고 계신가요?

            http://stackoverflow.com/questions/20903967/gmails-new-image-caching-is-breaking-image-links-in-newsletter

            http://blog.kerika.com/googleusercontent-com-can-trip-you-up-if-you-disable-third-party-cookies/

            쿠키는 3종류가 있습니다. session cookie, persistent cookie, evercookie.

            session 쿠키는 브라우져를 끄면 사라집니다.

            persistent 쿠키는 내가 삭제를 해야 없어집니다.

            evercookie 는 컴퓨터를 reformat 하기 전에는절대 안 없어집니다. (물론 삭제해주는 프로그램이 존재하긴 합니다.)

            어떤 웹사이트들은 이 evercookie 를 씁니다. 랭커님 PC 에도 아마 evercookie 들이 있을겁니다. (물론 못찾으십니다. 이 evercookie 는 악성코드처럼 PC 내에서 여기저기 돌아다니면서 은신을 하기 때문에.)

            사용자 입장에서 몹시 불쾌한겁니다. 내가 웹에서 뭘하는지 나도 모르게 누군가가 나를 평생 monitoring/관찰 하고 있는거거든요. 아마 토렌트 사용자들 PC 에는 정부에서 다 이 evercookie 를 깔아놨을겁니다. 그래서 파워유저들은 이 3rd party 쿠키를 disable 해 놓습니다.

            이래서 랭커님 사이트 아이콘이 저한테는 깨져 보입니다.

          • googleusercontent 에서 이미지 호스팅 하면 이미지 깨지는거 몰랐습니다. ㅠㅠ (알았으면 썼을리가 없죠)

            그런데, 저 같은 경우 아이콘 뿐 아니라 포스팅 내 이미지도 거의 모두 googleusercontent 에서 가져오는데… 이걸 어떻게 해야 하나요?

            총,총체적 난국인가요? ^^;;;

            P.S 구글드라이브에서 호스팅을 하는 경우는 위에서 말씀하신 쿠키 문제가 없는건가요?

            아… 그리고 아이콘을 sprite 로 작업한거는 로컬에서 간단하게 테스트해보는 중이라 제 사이트에 방문하셔도 소용이 없습니다. 메튜님이 “라이브에서 수정하는 것은 미친(?) 짓” 이라고 하셔서, 그 이후로 초간단한 작업 아니면 로컬에서 작업한 후에 옮기고 있습니다. ㅎㅎ

          • Matthew says:

            음… 단순한 쿠키문제가 아니네요.

            구글의 diagnostic 에 의하면, googleusercontent.com 이란 사이트에서 악성스크립트가 다운로드 되서 방문자 컴퓨터를 감염시키고 있답니다. ㅋㅋㅋ

            Of the 6769942 pages we tested on the site over the past 90 days, 1224 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2015-09-15, and the last time suspicious content was found on this site was on 2015-09-15.

            Has this site hosted malware?

            이 사이트 (googleusercontent.com) 은 악성코드를 호스트 하나요?

            Yes, this site has hosted malicious software over the past 90 days. It infected 1123 domain(s)

            네, 지난 90일간 1123개의 웹사이트를 감염시켰습니다.

            켁… >.<

            http://www.google.com/safebrowsing/diagnostic?site=googleusercontent.com/

            진지하게 말씀드리자면, 제 컴퓨터 백신프로그램이 랭커님 사이트에 상주하고 있는 어떤 악성코드를 감지하고, 그 부분을 block 했을 가능성도 있어 보입니다.

            제 구글드라이브 개인계정은 용량을 96% 정도 사용해서 저는 테스트 해보지 않았는데, 개인 공간이니까 큰 문제가 없을거라 생각합니다.

            웹사이트 작업하실때는, 가급적이면 작업하는 컴퓨터로 웹서핑같은 것 하지말고, 다른 관련없는 프로그램들은 설치하지 말아야 합니다.

            본업이 아니고 그냥 취미로 사이트 꾸미시는 분들 중, 자신의 컴퓨터가 악성코드에 감염되서 그 악성코드가 웹사이트로 까지 번지는걸 보게 됩니다. (몇달전 Kopress 에도 그런 상황이라 질문글 올리신 분이 계셨었어요.)

            그때 그분 사이트, 아예 싹 갈아 엎어야 되는 상황이었는데…

            아무튼 이런 부분도 항상 신경쓰세요.

          • 이럴수가… googleuserconent.com 은 구글의 피카사 웹앨범(제계정)인데… 그래서, 믿고 썼는데… ㅠㅠ

            그렇다면, 구글 드라이브를 이용해도 비슷한 상황이 발생할 수도 있을거 같은데요. 갑자기 폭풍 절망감이… 망했음. OTL

          • Matthew says:

            구글드라이브는 나만의 저장공간이라서 googleusercontent 와는 다른 환경입니다. 물론 한번도 구글드라이브에 웹사이트 asset 을 호스팅 해본적은 없습니다.

            일단 랭커님이 마루타 역활….. 은 아니고, 암튼 사용해 보시고 문제점이 발생하면 알려주세요. 저도 궁금합니다. 그런데 왠지 별 문제 없을 것 같습니다.

          • 음… 안되겠어요. 일단 보통 방문자들에게는 가시적인 문제가 없는것 같으니 그냥 포기할래요. ^^;; (일단 저 조차도 결과를 볼 수가 없으니)

            그런데, 메튜님의 경우… 제 블로그를 볼 때, 본문 내 이미지도 깨져 보이나요? (메뉴에 들어간 아이콘 같은거 말구요)

          • Matthew says:

            쿠키문제가 아니라 제 컴퓨터에 설치된 백신의 false positive 현상이었던 것 같습니다.

          • 그런건가요? 백신이 그런 문제를 일으킬 수도 있나 보군요…

            아무튼 다행이구요, 답변 주셔서 감사합니다. ^^

Leave a Reply

Your email address will not be published. Required fields are marked *