모바일 대응 방법
- 반응형(RWD : Responsive Web Design) - 가로 크기에 변화를 줄 때, 콘텐츠들이 웹브라우저의 가로 사이즈에 맞춰 유동적으로 재배치되는 형태. 장점 - 개발자 혼자서 해결하기 적합함. 단점 - 개발 난이도가 올라감.
- 적응형(AWD : Adaptive Web Design) - m.naver.com처럼 사용자가 브라우저의 가로 크기를 변경해서 디자이너가 지정한 해상도에 도달하면 레이아웃이 재배치되는 형태. 장점 - 정해진 화면에 최적화된 코드가 작성되기 때문에 속도가 반응형보다 조금 더 빠름. 단점 - 일의 양이 많음. 개발자, 디자이너, 기획자 모두 필요. 적응형으로 디자인되면 반응형으로 개선이 어려움.
반응형 제작시 사용하는 속성
- 미디어쿼리(@media) - PC to mobile인지, mobile to PC인지 생각해야 함. 이 중요도에 따라 가감되는 것들이 생김. 개발 난이도에 따라 요소를 조절해야 함.
- flex, wrap, grid, autofill, autofit 등 - 웹브라우저의 가로 넓이에 따라 유동적으로 변하는 유동형 레이아웃.
- %, rem, em - 일반적으로 반응형 웹은 % 단위를 사용하여 각 디자인의 폭에 유동적으로 반응하여 콘텐츠의 크기가 줄거나 커지고 오브젝트 배열도 변경함. 하지만 이는 디자이너에게 익숙하지 않아 8gird, 16grid로 제작하는 방법도 생김. %나 rem은 상위 요소를 기준으로 크기를 결정하고, em은 자기 자신 또는 상위 부모의 폰트 사이즈를 기준으로 함.
크로스 브라우징
웹 페이지 제작 시 모든 브라우저에서 의도한 대로 올바르게(호환성) 나오게 하는 작업.

- 체크 시 점유율 높은 곳은 반드시 확인하기.
- 브라우저마다 ul 태그, h 태그 등의 기본 설정된 옵션이 다르기 때문.
- 브라우저에 따라 사용하지 못하는 JS가 있으니 체크 필수. 1차로 체크하고 실행이 안될 경우, 2차로 캔아이유즈 등 기술을 지원하는지 확인 후 수정하기.
- CSS 초기화 작업하기.
SEO 작업
무료 작업
- 구글, 네이버 등 검색 포털에 검색 등록하기. 이때 robots.txt(검색엔진 크롤러가 어디까지 접근할지), sitemap.xml(크롤링 bot이 접근할 수 있는 것중에 사이트 URL을 크롤링 함)도 작성하면 검색 엔진이 어떤걸 봐야할지 알려줄 수 있음.
- 인덱싱 처리 - 정보를 읽기 편한 방식으로 나누는 것.
- 랭킹 - 메타태그를 통해 키워드를 표시함. 1) 캐노니컬 태그 (Canonical tag) - 사이트 내 URL 주소는 다르지만 동일한 내용의 중복된 페이지가 있을 때 페이지에 코드를 삽입하여 검색엔진에 대표가 되는 URL 주소를 알려주는 역할을 하는 태그. 구글은 URL에 '?id&' 뒤에 오는 문자는 무시하기 때문에 이 표시가 중요하다면 캐노니컬 태그를 작성해주어야 함. 2) open graph 태그 - 링크의 미리보기 제목, 설명, 이미지를 결정. 3) 키워드를 나타내는 h1, h2 태그와 이미지 태그의 alt 값. 이때 alt 이름을 서술형으로 쓰는 것이 좋음. ex) 강아지 이미지x, 파란색 강아지가 풀밭을 놀고 있음o. 4) Image Lazy Loading 기법 - 기존의 모든 이미지를 그대로 유지한 채 페이지 사이즈를 줄이고 페이지 로딩 시간을 향상시킬 수 있는 기술. 스켈레톤 이미지를 의미함.
유료 작업
- 백링크(backlink) - 한 웹사이트가 다른 웹사이트를 언급하면서 그 사이트로 연결해 주는 링크. 구글은 백링크가 많을수록 좋은 웹사이트라고 판단하기 때문.
- 광고
Google 애널리틱스
- 파이어베이스에서 지원.
- 해외, 국내, 일접속자 등 간단하고 쉽게 사용할 수 있음.

QA
- blackbox test - 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식. ex) 로그인 입력창 작성 후 엔터, 이름 글자수 제한, 이메일 형식은 갖추되 이상한 주소일 경우

- whitebox test - 응용 프로그램의 내부 구조, 동작을 디테일하게 검사하는 테스트 방식. 장점 - 튼튼한 코드, 단점 - 제작 기간이 길어짐.

사이트 수정
📑 결과보기
피드백
- NPM으로 firebase tools를 설치하면 aws nginx에 반영이 안될 수 있음.
- if로 시작하면 끝은 else로 끝나는 습관 기르기.
- init의 시작이 하단부터라면 주석으로 남겨놓는 등 코드의 흐름을 수립할 필요가 있음.
- woff 등 직접 폰트를 적용하면 더 빠르게 웹사이트가 동작함.
도메인 받아 호스팅하기




모바일 대응 (반응형 디자인)

- 미디어쿼리를 사용한 반응형 제작.
스켈레톤 이미지 삽입


- await로 로딩이 길어지기 때문에 await가 일어나기 전에 HTML을 생성하여 스켈레톤 이미지 삽입.
- 원래 들어가야 하는 값에 null 삽입.
- if(!data)로 data가 null일 경우 스켈레톤 HTML을 반환하도록 함.
QA
- 프로필 이미지 업로드 용량 제한 - byte 단위로 제한해야 함.
- 댓글 개수 제한하기 🤔for문을 사용하여 commentCnt를 올리는 방식을 사용했는데 매우 비효율적임..
- 로그인 형식 제한하기 - firebase에서 제공하는 규격에 따른 error를 유저에게 보여줌.
마치며
이제 지브리 포뇨가 막바지를 달리고 있다. 확실히 스켈레톤 이미지나 QA를 하니 웹사이트의 완성도가 올라간 기분이다. 아직 SEO 작업은 못하긴 했는데.. 실제 서비스를 할게 아니라 하기 싫다..ㅋㅋ 그래도 이번에 지브리 포뇨를 만들면서 JS에 대해 알게됐다. 요즘은 예전에 잠깐 멈췄던 모던 JS 튜토리얼 블로그를 다시 보고있다. 확실히 한번 알고 보니까 좀 더 디테일한 부분까지 보고 이해하는 것 같다. 빨리 react로 다시 만들어보고 싶다.
🤔 리액트로 지브리 포뇨 다시 구현하기