CSS Sprite 또는 CSS Image Sprite라고도 불리는데요, 여기서 이 Sprite라는 단어는 합성과 같은 의미로 쓰여지는데요. 직역을 해보자면 CSS 이미지 합치기(?) 가 되겠습니다.
왜 이미지 합치기라고 불리냐면 CSS image Sprite는 여러개의 이미지를 하나의 이미지로 합쳐서 관리하는 기술이기 때문입니다.
이해를 돕고자 친숙한 사이트 몇개를 선정해 실제로 사용중인 Sprite image를 가져왔습니다.
NAVER sprite image
Daum sprite image
두 사진은 각각 네이버와 다음에서 실제로 사용중인 Sprite image 입니다.
🤔철수: "어? 그러면 html에서 image가 하나면 어떻게 불러다 사용해요? 저는 로고 하나만 필요한걸요?"
🐵: 다 방법이 있습니다. CSS의 background 속성중에 background-image, background-position 와 우리가 원하는 로고의 크기 즉 width, height 속성만 있다면 Sprite image에서 특정 아이콘 부분만 사용하는것이 가능합니다.
마치 이런식으로 말이죠.
🤔철수: "다시 생각해 보니깐 굳이 이렇게 사용해야 하는 이유가 있을까요? 여러사진으로 보내는게 사용하기 편할꺼 같은데요.
🐵:
이러한 방식으로 사진을 사용하는 이유는 사이트의 성능을 향상시키기 위함인데요. 사실 이전 포스팅에서 iamge spriting에 대해 살짝 언급을 했었습니다.
요약해서 말씀드리자면, 브라우저는 한번에 하나의 파일만 가져올수 있습니다. 그렇기 때문에 이미지 여러개를 요청하게 되면 그만큼 서버로 요청도 많아지게되고 요청이 많아지는 만큼 네트워크 지연도 많아지게 됩니다. 결국 페이지렌더링이 늦어지게 되는거죠.
그렇기 때문에 많은 사이트에서 HTTP 요청 횟수를 줄이기 위해서 로고나 아이콘과 같은 사진들을 하나로 합쳐서(Sprite) 하나의 이미지로 만들어 보내는 것입니다.
이러한 sprite image에서 특정 icon의 위치 찾는게 쉽지만은 않습니다. 그래서 이러한 sprite image 에서 특정부분을 사용하기 위한 css로 바꿔주는 여러 프로그램과 사이트들이 있는데요. 제가 소개드릴 사이트는 sprite cow 라는 사이트입니다. http://www.spritecow.com/
사이트에 들어오셔서 원하는 이미지를 열어줍니다. 저는 네이버의 sprite image를 열었습니다.
그리고 마우스를 이용해 원하는 로고영역을 선택해주세요.
그러면 아래에 해당 영역을 사용하기 위한 css가 나타내어지게 됩니다.
오늘 살펴볼 내용은 여기까지이구요. 궁금한점이나 피드백은 언제든 환영입니다. 댓글을 통해서 의견 남겨주시길 바랍니다 : ) 감사합니다.
프로그레시브 렌더링은 서버에서 웹 페이지의 일부를 순차적으로 렌더링하면서 전체 페이지가 렌더링 될 때까지 기다리지 않고 웹 페이지를 클라이언트에 스트리밍하는 기술입니다.
즉, 콘텐츠를 가능한한 빠르게 표시하기 위해서 사용이 되는데요. 이를 이해하기 쉽게 하나의 예를 들어 보겠습니다.
🤔 철수 : "다른 사이트랑은 다르게 네이버는 메인 페이지에서 엄청나게 많은 데이터를 보여주고 있는데, 뭔가 더 빠르게 페이지가 로드되는거 같아"
🐵:
위의 철수의 사례가 이해하기에는 대표적인 사례가 아닐지 싶습니다. 네이버같은 경우에는 메인페이지에서 보여주어야할 데이터가 정말이지 많습니다. 광고부터 뉴스 그리고 실시간검색까지 정말이지 많은 데이터를 받아오는데요. 이때 우리는 기타 다른 사이트와 동일한(?) 대기시간을 느낍니다. 그 이유는 네이버도 progressive rendering을 사용하고 있기 때문이라 볼수 있습니다. 네이버도 중요한 데이터를 먼저 받아와 랜더링하고 그 다음 덜 중요한 순으로 데이터를 보내주어 화면을 랜더링해주고 있기 때문입니다.
눈에는 보이진 않지만 뒤에서 열심히 데이터를 받아 바로바로 화면에 보여주고 있는것이죠
점진적 렌더링 (일명점진적 서버 측 렌더링)은서버에서 중요한 컨텐츠를렌더링 한 후에 중요하지 않은 컨텐츠를 기다리지 않고 클라이언트로 스트리밍을 시작하는 기술입니다.
그런 다음 중요하지 않은 콘텐츠는 나중에 서버에서 렌더링되면 스트리밍합니다. 브라우저는 중요한 내용에 대해 먼저 렌더링을 시작하여 브라우저 화면에 그려줍니다. 그다음 브라우저가 서버로부터 컨텐츠를 수신하면 중요하지 않은 컨텐츠는 나중에 페이지에서 렌더링 (페인트)됩니다.
이 과정을 절차적으로 확인해 보도록 할게요.
브라우저가 서버에 HTML을 요청합니다.
서버는 API 요청을 수행하고 서버에서 중요한 컨텐츠를 먼저 렌더링하여 브라우저로 스트리밍합니다.
브라우저는HTML청크(덩어리)를 받아서 화면에 렌더링 (페인트)합니다.
서버는 중요 컨텐츠를렌더링한 후중요하지 않은 컨텐츠를렌더링하고이를 클라이언트로스트리밍합니다.
브라우저는 나중에 중요하지 않은 컨텐츠를 받아서 렌더링 (페인트)합니다.
전체 페이지가로드되면 브라우저는 일반적으로 이벤트 핸들러 및 기타 대화식 동작을 연결하는 DOM 요소에 대한 상호 작용을 수화합니다.
다음은SSR vs PSSR로렌더링 된 동일한 웹 사이트의 예입니다.사이트가 대기 시간이 긴 저 대역폭 네트워크를 통해로드되었다고 가정합니다.
Pers프로파일 링SSR과 PSSR을비교하면 페이지에 컨텐츠가 얼마나 빨리 표시되는지 명확하게 개선 할 수 있습니다.
이미지 지연 로딩 - 페이지의 이미지를 한꺼번에 로딩하지 않습니다. JavaScript를 사용하여 사용자가 이미지를 표시하는 페이지 부분으로 스크롤 할 때 이미지를 로드 할 수 있습니다.
보이는 콘텐츠의 우선순위 설정 (또는 스크롤 없이 볼 수 있는 렌더링) - 가능한 한 빨리 표시하기 위해 사용자 브라우저에서 렌더링될 페이지에 필요한 최소한의 CSS/콘텐츠/스크립트 만 포함하면deferred스크립트를 사용하거나DOMContentLoaded/load이벤트를 사용하여 다른 리소스와 내용을 로드할 수 있습니다.
오늘 포스팅할 내용은 브라우저가 서버로부터 데이터를 받아 사이트를 로드시키기까지 걸리는 시간에 대하여 이야기를 해보고자 합니다.
😧철수 : "한국장학 재단 사이트에 접속을 하는데 브라우저에서 사이트 화면이 나오기 까지 잠시 화면이 흰바탕 화면으로 보였어!"
🐵:
네 아주 자연스러운 일인데요, 우리가 특정 사이트를 접속할 때 종종 잠시 흰바탕의 화면이 나오는것을 볼 수 있습니다.
한국장학재단 사이트 접속중 캡쳐
이러한 화면이 나오는 이유는 서버로부터 보내진 Html, Css, Js, jpg... 등 파일들이 아직 브라우저로 도착하지 않았기 때문에 발생하는 현상입니다.
즉, 화면에 보여줄 데이터가 없어서 발생한거에요.
그리고 이러한 화면이 사라지기까지의 시간을 '페이지 로드시간' 혹은 '레이턴시', 대기시간 등으로 불립니다.
😧철수 :그렇다면 이러한 대기시간을 줄이는 방법은 무엇이 있나요?
🐵:
일단 현재 대기시간을 줄이고자 하는 서비스의 형태에 따라 답변이 달라질 수 있을것 같습니다.
만들어진 웹서비스가 SSR 즉 서버측에서 화면을 모두 구성한 다음에 보내주는 방식의 서비스인가 또는 CSR 이라고 클라이언트 측에서 서버로 부터 데이터를 받은 후에 이를 가지고 화면을 구성을 하는가에 따라서 이러한 '대기시간'의 등장 빈도수가 달라집니다.
일반적으로 SSR을 따르게 되면 페이지에서 페이지로 이동시 전체문서 즉 Html 부터 CSS, JS까지 다시 요청해서 받아오게 됩니다. 그렇기 때문에 페이지 이동간에 '대기시간'이 계속 나타나게 되어지죠.
하지만 CSR을 따르게 되면 최초에 화면을 구성하기 위한 데이터를 받아오고, 이후 페이지 이동간에는 필요한 최소한의 데이터만 서버로부터 받아와 화면을 구성하기 때문에 SSR과는 다르게 '대기시간'이 매우 짧아지게 됩니다.(거의 안느껴지죠)
이렇듯 서비스 전체에 대한 총 대기시간을 줄이고자 하는것이 목적이라면 이렇게 CSR형태로 개발하는 방법이 답이될 수 있겠습니다.
😧철수 : 그렇다면 CSR로 개발하면 무조건 효율적인건가요?
🐵:
그렇지 않습니다.
사실, CSR은 초기 도입시에 대한 대기시간(페이지로드시간)이 SSR형태의 서비스에 비해 깁니다.
그 이유는 CSR이 화면을 구성하기 위한 데이터를 미리 다 받아두고 이후 페이지 변화간에 기존에 받아두었던 데이터를 재 활용해서 화면을 구성해주기 때문입니다. 미리 데이터를 다 받아두기 때문에 서버로 부터 받는 데이터 크기 또한 다를 뿐더러 화면을 구성하기위해 JS코드를 해석하는등 이러한 추가적인 시간이 생기게됩니다.
이러한 상황에서는 우리가 최초 페이지 로드시간을 줄이는 방법은 여러가지가 있습니다.
일단 개발자를 이용한 개선방법부터 알아보겠습니다.
받아온 데이터를 해석하는데 걸리는 시간을 줄이기 위해서 평소 개발시 불필요한 코드를 정리하는 습관을 들이거나, 최대한 심플한 코드를 짜는 습관을 들이는 방법이 있겠습니다.
다음은 네트워크 측면에서 방법을 찾아보겠습니다.
서버로부터 보내진 데이터를 받기까지의 걸리는 시간 때문에도 대기시간이 생깁니다. 이러한 상황은 서버로부터 데이터를 빠르게 받는 방법을 통해 대기시간을 줄일 수 있는데요.
그 첫번째 방법으로는 단순하게 네트워크 속도 그 자체를 빠르게 만들어 주는겁니다. 하지만 이러한 방법은 개발측면에서 할 수 있는것이 아니기 때문에 쉬운 방법은 아닙니다.
두번째 방법으로는 서버로부터 보내는 데이터를 최대한 작게 만들어서 보내주는 방법이 있습니다. 개발이 완료된 소스코드의 들여쓰기나 빈 여백공간과 같이 소스코드 열람시 개발자의 가독성을 위한 데이터 부분들을 제거하는 등 소스코드 자체를 압축시키는 방법이 있습니다.
세번째 방법으로는 gzip을 이용한 전송데이터 압축인데요. 전송하고자 하는 데이터를 압축시켜서 전송시켜주고 이를 클라이언트가 받아서 압축을 풀어 사용하는 방식입니다. 이 방식은 데이터 크기 자체를 줄여 전송시켜주기 때문에 도착까지 걸리는 시간이 적습니다. 하지만 클라이언트가 압축을 해제후 사용해야 하기 때문에 크기가 다소 작은 데이터를 보낼때는 효율이 좋지 않을 수 있습니다.
CRA를 이용하여 React 프로젝트를 생성 후 실행하게되면 localhost:3000번으로 React 서버가 실행이 되어집니다. 그리고 같은 컴퓨터에서 서버를 개발하여 실행후 방금 만든 React 서버와 데이터를 잘 주고받나 테스트를 진행해야 하는데, 이때 이미 3000번 포트는 React 서버가 사용하고 있으니 서버는 다른 포트번호를 사용해야 합니다.
그래서 저는 보통 서버는 4000포트를 사용하고 있는데요. 이때 React서버에서 자신의 포트와 다른 4000번 포트(서버)로 특정 데이터(자원)를 요청해야 하는데, 이때 CORS가 밸생하게 됩니다. (다른 포트로 자원을 요청하니깐요!)
이러한 경우에는 request 객체의 header에 "Access-Control-Allow-Origin" 옵션을 추가해 주시면 됩니다.
📌 CORS Middleware 사용하기
모든 request마다 CORS를 위한 "Access-Control-Allow-Origin" 옵션을 추가하기는 어렵기 때문에 Node의 cors라는 미들웨어를 사용하여 이를 처리합니다.
npm 이나 yarn을 이용해서 설치합니다.
npm install --save cors
yarn add cors
그리고 express 서버 파일에서 다음과 같이 입력함으로서 쉽게 CORS를 허가해줄 수 있습니다.
const express = require('express');
const cors = require('cors');
const app = express();
app.use(cors()); // CORS 미들웨어 추가
...
하지만 앞서서 이야기를 드렸지만 브라우저가 CORS를 막는 이유는 보안상의 이유입니다. 이렇게 모든 요청마다 CORS를 허가해준다면 보안상으로 문제가 많아지게 됩니다.
이러한 이유로 React를 이용한 개발을 진행할때는 이런 방식으로 개발을 진행하는 것 보다는
"webpack-dev-server proxy" 기능을 사용하여 서버쪽 코드를 수정하지 않고 해당 이슈를 해결하는것이 바람직합니다.
요약하자면, 유저를 대신해 서버로부터 데이터를 보내거나 받아주고 또, 받아온 정보(데이터)를 GUI를 통해서 유저에게 보여주는 존재입니다.
여기서 우리가 알아볼 정보는 총 세가지 입니다.
브라우저는 데이터를 어떻게 받아 오는가?
브라우저는 데이터를 어떻게 전송하는가?
브라우저는 서버로부터 받아온 데이터를 화면에 어떤 방식으로 렌더링하는가?
차근차근 하나씩 공부하여 알아보도록 하겠습니다.
🐵 브라우저는 데이터를 어떻게 주고 받는가?
기본적으로 우리가 브라우저를 이용하여 서버와 데이터를 주고 받을때에는 HTTP라는 통신규약(프로토콜)을 이용하여 받아오게 됩니다.
(여기서 프로토콜이 무엇인지는 언급하지 않겠습니다)
그렇다면 HTTP를 통해 데이터를 받아오는 과정은 어떨까요?
서버와 브라우저가 데이터를 주고 받기는 이 과정을 Request(요청) 과 Response(응답)이라고 표현합니다. 이러한 방식을 Client-Server 방식이라고 부르는데요, 즉 서버에게 나 "~이런정보가 필요해 혹은 가져왔으니 받아줘" 라는 Request(요청)을 하면 서버가 요청을 이해하고 그에 알맞는 Response(응답)을 해주는 것입니다.
여기서 우리의 요청이 특정 서버에게 잘 도착하게 하기 위해서 브라우저의 URL에 해당 서버의 IP 주소 혹은 도메인 네임을 적어서 요청하게 됩니다. 그러면 우리의 컴퓨터(운영체제)는 일종의 요청서에 해당하는 Packet이라는 데이터를 만들어 그 안에 도착지(서버주소)와 자신의 IP주소를 적어 라우터에게 전달하게 됩니다.
(여기서부터 서버까지 도달하는 일은 라우터가 우리가 만든 해당 Packet을 해석해서 알아서 전달해주게 됩니다.)
(사실 이과정에서 바로 데이터를 보내주는것이 아니라 3Hand Shake라는 과정을 거쳐 서로가 네트워크 연결이 잘 되어있는지 확인하는 절차를 거친 후에 데이터를 주고 받습니다.)
🐵 브라우저 렌더링 방법은?
렌더링이란 논리적인 문서의 표현식을 그래픽 표현식으로 변형시키는 과정입니다. 즉 브라우저 렌더링은 서버로부터 받은 문서 혹은 파일을 그래픽 표현식으로 변형시켜주는 과정이라 볼 수 있겠습니다.
여기서 브라우저가 어떻게 렌더링을 하는것인가를 알아보기 전에 브라우저가 어떤 구조로 되어있는지 부터 알아보고 이야기를 시작하도록 하겠습니다.
브라우저는 아래의 내용으로 구성되어있습니다.
사용자 인터페이스 - 주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등. 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분이다.
브라우저 엔진 - 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어.
렌더링 엔진 - 요청한 콘텐츠를 표시. 예를 들어 HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시함.
통신 - HTTP 요청과 같은 네트워크 호출에 사용됨. 이것은 플랫폼 독립적인 인터페이스이고 각 플랫폼 하부에서 실행됨.
UI 백엔드 - 콤보 박스와 창 같은 기본적인 장치를 그림. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서, OS 사용자 인터페이스 체계를 사용.
자바스크립트 해석기 - 자바스크립트 코드를 해석하고 실행.
자료 저장소 - 이 부분은 자료를 저장하는 계층이다. 쿠키를 저장하는 것과 같이 모든 종류의 자원을 하드 디스크에 저장할 필요가 있다. HTML5 명세에는 브라우저가 지원하는 '웹데이터베이스'가 정의되어 있다.
아래의 사진을 보면 더 이해가 잘될텐데요,
(Naver D2 페이지에서 발췌한 사진입니다.)
Naver D2 페이지에서 발췌
즉 우리가 더 깊게 알아봐야할 부분이 렌더링 엔진! 이라는 겁니다. 브라우저가 "렌더링 엔진" 이라는 것을 이용해 렌더링을 수행하는 것인거죠.
렌더링 엔진
그럼 렌더링 엔진에 대하여 알아보겠습니다.
렌더링 엔진의 종류에는 파이어폭스를 만든 모질라에서 직접 제작한 게코엔진과 사파리와 크롬에서 사용되어지고 있는 웹킷엔진이 있습니다.
이러한 렌더링 엔진의 역할은 요청 받은 내용을 브라우저 화면에 표시하는 일입니다.
여기서 요청받아 표시하는 정보들에는 HTML, CSS, JS들이 있고 플러그인이나 브라우저 확장 기능을 이용해 PDF와 같은 다른 유형도 표시가 가능합니다.
자 이제 렌더링 엔진이 동작하는 과정을 살펴보겠습니다.
렌더링엔진은통신으로부터 요청한 문서의 내용을 얻는 것으로 시작하는데 문서의 내용은 보통8KB 단위로 전송되어집니다.
웹 브라우저가 원본 HTML 문서를 읽어들인 후, 스타일을 입히고 대화형 페이지로 만들어 뷰 포트에 표시하기까지의 과정을 “Critical Rendering Path”라고 합니다. Understanding the Critical Rendering Path 에서 다루듯이 이 과정은 여러 단계로 나누어져 있지만, 이 단계들을 대략 두 단계로 나눌 수 있습니다.
첫 번째 단계에서 브라우저는 읽어들인 문서를 파싱하여 최종적으로 어떤 내용을 페이지에 렌더링할지 결정합니다.
렌더링 엔진은 위에서 언급한 첫 번째 단계에 해당하는 HTML 문서를 파싱을 하고 "콘텐츠 트리"(DOM트리) 내부에서 태그를DOM노드로 변환합니다.
그 다음 외부 CSS 파일과 함께 포함된 스타일 요소도 파싱하는 과정을 거칩니다.
[렌더 트리 구축]
이때, 스타일 정보와 HTML 표시 규칙은 "렌더트리"라고 부르는 또 다른 트리를 생성하게 됩니다.
렌더 트리는 색상 또는 면적과 같은 시각적 속성이 있는 사각형을 포함하고 있는데 정해진 순서대로 화면에 표시됩니다.
[렌더 트리 배치]
렌더 트리 생성이 끝나면 배치가 시작되는데 이것은 각 노드가 화면의 정확한 위치에 표시되는 것을 의미합니다.
다음은 UI 백엔드에서 렌더 트리의 각 노드를 가로지르며 형상을 만들어 내는 그리기 과정입니다.
일련의 과정들이 점진적으로 진행된다는 것을 아는 것이 중요합니다. 렌더링 엔진은 좀 더 나은 사용자 경험을 위해 가능하면 빠르게 내용을 표시하는데 모든 HTML을 파싱할 때까지 기다리지 않고 배치와 그리기 과정을 시작합니다. 네트워크로부터 나머지 내용이 전송되기를 기다리는 동시에 받은 내용의 일부를 먼저 화면에 표시하는 것입니다.
아래의 사진은 렌더링 엔진 별 동작과정을 나타낸 이미지입니다.
(Naver D2페이지에서 발췌)
웹킷 동작 과정모질라의 게코 렌더링 엔진 동작 과정
웹킷과 게코가 용어를 약간 다르게 사용하고 있지만 동작 과정은 기본적으로 동일하다는 것을 위의 그림들을 통해 알 수 있습니다.
게코는 시각적으로 처리되는 렌더 트리를 "형상 트리(frame tree)"라고 부르고 각 요소를 형상(frame)이라고 하는데 웹킷은 "렌더 객체(render object)"로 구성되어 있는 "렌더 트리(render tree)"라는 용어를 사용합니다. 웹킷은 요소를 배치하는데 "배치(layout)" 라는 용어를 사용하지만 게코는 "리플로(reflow)" 라고 부릅니다. "어태치먼트(attachment)"는 웹킷이 렌더 트리를 생성하기 위해 DOM 노드와 시각 정보를 연결하는 과정입니다.
'검색엔진 최적화' 이하 'SEO'의 사전적 의미는 웹 페이지 검색엔진이 자료를 수집하고 매기는 방식에 맞게 웹 페이지를 구성해서 검색결과의 상위에 나올 수 있도록 하는 작업을 말합니다.
- 위키백과 참고
🐵:
우리가 궁금한것이 생겼을때 그 궁금증을 해결하기 위하여 주로 NAVER 나 GOOGLE 과 같은 검색포털사이트를 이용합니다. 이러한 회사들은 독자적으로 웹페이지 내에 있는 정보들 가령 Html 상에서 표시되는 내용들을 읽어들이고 어떤정보인지 분석하는 검색 엔진을 구축해 가지고 있습니다.
이러한 검색엔진들은 검색된 결과에 대하여 우선순위를 매기는 방식을 회사마다 다르게 가지고 있습니다.
예를들어 구글 등장 이후 검색 엔진들이 콘텐츠의 신뢰도를 파악하는 기초적인 지표로 다른 웹사이트에 얼마나 인용되었나를 사용하고있고, 이때 이 신뢰도에 따라서 결과물을 보여주는 우선순위가 달라지게 되어지는 것이죠.
(이러한 신뢰도 측정 방식 때문에 웹사이트들은 타 사이트에 인용되는 횟수를 늘리는 방향으로 최적화를 합니다.)
😧: 그렇다면 왜 SEO를 고려해야하는걸까요?
🐵:
그 이유는 간단합니다. 웹 사이트를 만든 회사나 소유주들이 자신의 사이트와 관련된 검색어로 검색했을때, 가장 먼저 결과로 나오기를 바라기 때문인데요.
예를 들어 우리가 쇼핑이라는 단어를 검색했을때, 쿠팡 위메프 등 정말 많은 포털로 연결되는 링크들이 나오지만 정작 그 결과물을 보는 우리는 상단에 있는 10개정도만 살펴보는 상황을 예로들 수 있겠습니다.
🤔: 오.. 그러면 어떻게해야 '검색엔진 최적화'를 적용할 수 있는건가요?
🐵:
기본적인 작업 방식은 특정한 검색어를 웹 페이지에 적절하게 배치하고, 앞서서 웹페이지의 신뢰성을 향상시키기 위해 다른 웹 페이지에서 우리 페이지로 링크가 많이 연결되도록 하는 것이 있겠습니다.
😀: 아! 이렇게 하면 모든 검색엔진에서 SEO가 지켜지는 거군요!
🐵:
꼭 그런것만은 아닙니다. 이렇게 한다고해서 모든 검색엔진에 대해 최적화 작업이 이루어지는것은 아닙니다.
앞서서 말씀드린 최적화 작업방식은 어디까지나 기본적으로 대부분의 검색엔진들이 신뢰도를 측정하는 방식으로 타 사이트에 인용되는 횟수를 이용하기 때문에 가능한 이야깁니다.
대부분의 검색엔진들은 검색결과에 대한 우선순위를 매기는 방식을 서로 다르게 가지고 있기 때문에 우리가 검색되고자 하는 주 타겟 검색엔진들을 잡아야 합니다.
예시로 한국인들이 자주 사용하는 검색엔진을 보유한 NAVER는 검색엔진의 우선순위 배치에 해외와 가른 기준을 적용하고 있는것을 알 수 있습니다. 이런 경우에는 보편적인 SEO를 적용시 오히려 스팸으로 분류될 수 있습니다.
😧: 그러면 한국에선 SEO를 하기위해 어떻게 해야하죠?
🐵:
보편적인 방식을 사용했을때 스팸으로 분류되는 이유는 NAVER가 자사 블로그에 노출 우선순위를 두었기 때문입니다. 즉, 한국의 검색 엔진에 노출되기 위해서는 사이트 콘텐츠가 웹문서가 아닌 블로그 포스트로 등록되는 방향으로 최적화 해야합니다.
이러한 이유로 많은 기업들이 흔히말하는 파워블로거에게 의뢰하여 후기들을 작성하는것을 의뢰하는 이유도 있지 않을까? 생각이 드네요 ^^
