Track 1. 장한보람
# Webtech
크롬포함 웹 업데이트
웹 한계 > 구글이 이를 극복하기 위해 하는일
# 업데이트 내용
1. Instant 신속
2. Powerful 확장성
3. Safe 안정성
-> 사용자 경험 중시
# V8
자바스크립트 엔진 업데이트 -> 적은 메모리로 빠른 처리
# 모던웹 : 초기 렌더링 이슈
Ex. Image-lazy-loading : 사용자가 보는 화면만 로딩, 스크롤 내리면 이미지 추가 로딩
<img src ...
loading=“lazy”
...
<iframe ...
loading=“lazy”
크롬 카나리아에서 위 코드 테스트 가능
. 크롬 = 프로덕션
. 크롬 카나리아 = 알파 베타 버전
# Portal
컨텐츠를 웹페이지 최상위 레이어로 삽입 가능
크롬 카나리아에서 위 개념 테스트 가능
# Lighthouse
웹사이트 현재 상태 진단하고 문제점에 따른 해결책 가이드
Performace budget
Budger.json에 파일 작성
웹사이트의 타입별로 각 리소스가 지정된 예산만큼 사용하는지 확인 가능
Ex. 타입
Third-party
Img
Font
http://www.performancebudget.io
위 사이트에서 테스트 가능
https://developers.google.com/web/tools/lighthouse/audits/budgets
# Web perception toolkit
1. Sensing
2. Meaning
3. Rendering
# Sharing api
1. Native app
2. Web
# Duplex on the web
Google assitant + web
Ex. 렌트카 빌릴때 사용자의 기존 정보를 어시스턴트가 자동으로 입력해주어 사용자의 시간을 절약할 수 있게 해줌
# Same site coookie
다른 도메인의 쿠키 값을 읽을 수 없게 함
sameSite:strict
# Fingerprinting protection
광고회사 등에서 불필요하게 사용자의 정보를 요구하는것을 (막음?)
# App gap
Web vs native app
Ex. 모바일 디바이스에서 사용자의 파일시스템에 접근, 사용자의 전화번호에 접근
-> 이 한계를 부수기 위해 하고 있는일 = 복어
네이티브에서 잘되는 기능을 사용자의 보안에 해를 끼치면서 까지 가지고 오면 안된다, 그래서 복어
Ex.
window.Badge.set(42)
어플리케이션 상단 우측에 새로운 소식이 있으면 노티를 해주는 기능을 웹의 api화함
네트워크가 느리거나 인터넷이 끊겼을때 웹은 아무런 대처도 하지 못하는게 치명적
-> progressive web app PWA
Chrome 76버전 이상부터는 데스크탑도 가능
# 단일 코드베이스에서 여러 디바이스를 커버하게 진화하는 중 = PWA, Flutter
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
Track 2. 김석용
# 리액트네이티브 - js bridge 퍼포먼스 이슈
# 크로스 플랫폼 = 하나의 코드로 다양한 플랫폼에서 사용가능
기존에는 사용자의 경험을 해치는 등의 트레이드오프가 있었음
# Fuchsia
구글에서 공개한 오픈소스 프로젝트
전통적인 리눅스 커널os가 아닌 지르콘zircon 마이크로커널을 사용
# 안드로이드 어플리케이션 실행이 가능 2019 1월 부터
작년 12월 플러터 1.0이 나옴
Dart 2.1도 같이 발표함 (지금은 dart2.3)
# Skia 안드로이드 내부 화면에서 사용하는 2d 그래픽 엔진
# 플러터 하위호환성
안드로이드 젤리빈 4.1 ~
Ios 8 (아이폰 4) ~
# 플러터 컴포넌트
Material (aos??)
Cupertino(ios)
플랫폼에 따라 위의 그리는걸 분기태우면됨
즉 소스는 두벌
Ex.
Platform.isAndroid ...
Material
Else
Cupertino
# Statelesswidget (한번그리면 변경없음)
Statefullwidget
# Ui 모듈화 작업을 계속 해줘야함
코드의 계층구조로인해..
# 그럼 왜 계층구조로 플러터를 만들었는가??
플러터 컨셉
최상위 트리 위젯과 하위의 타이트한 결합도로인해 Css를 최소화 할 수 있다
고도의 최적화 가능
# main.dart 파일에 앱에 관한 작성, 이곳에 90프로이상의 시간을 쓰게될것이다...
Pub.dev -> 플러터에서 사용할 패키지 검색하여 버전 확인가능한 사이트
# 생명주기
# 참고
https://itsallwidgets.com
https://pub.dev
https://flutter.dev
# 복잡한 화면구성이 없는 토이프로젝트에 사용 추천
# Flutter desktop architecture
# Flutter web engine이 js로 포팅하여 동작
Skia대신 dart2js가 돌고있음
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
Track 3. 조은
# 콘텐츠를 자바스크립트로 생성한다
Api로 서버에서 호출하여 데이터를 가지고와야 페이지가 완성된다 -> 구글봇은 페이지의 콘텐츠를 이해하기가 어려워졌다. Api 호출전에는 웹페이지 예측 불가
구글봇+크롬 41버전 -> 웹페이지 렌더링하여 데이터를 크롤링해야겠다
# 랜더링만 체크 = 구글봇+퍼페티어(purppeteer)
따라서 single page application도 구글봇이 잘 검색할수 있다.
# Robots.txt - 구글봇의 크롤링 필터 정의 가능
Disallow: /
라고 정의하면 구글봇에서 루트 하위 크롤링하지 않아서 검색하면 하위 검색못함이라고 뜸
# Robots.txt는 public이되어야 구글봇이 읽을 수 있다. 이때 도메인 하위 경로를 작성하면 해킹당할 여지가 있음.
위 배드케이스를 방지하려면,
1. 도메인을 아예 분리하여 크롤링 예외처리를 한다.
2. 인증을 거치게 한다면 구글봇이 크롤링하지 않음.
# (구글 검색페이지에 잘나오게하려면)
올바른 title을 페이지 별로 사용해야한다.
<title> 치킨 페이지 - 레시피 </title>
<title> 족발 페이지 - 레시피 </title>
적절하게 콘텐츠를 설명하는 제목을 사용하면서도, 사이트를 잘 설명하고 있는 타이틀을 사용해야한다
단, 타이틀은 너무 길지않게 짓기 위해 서비스명을 짧게 짓자
# 올바른 description을 선언해야 검색 노출이 올바른 정보로 된다
og:title만 선언하는것도 안좋다
<meta name=“description” content=“이사이트는 무엇무엇입니다”>
# 올바른 html 태그를 사용하는 것도 구글 검색 노출에 도움이 됨.
구글봇은 a 요소로 홈페이지 색인을 한다.
<a href=“page”>페이지이동</a>
구글봇은 페이지내의 a 요소를 전부 클릭하며 페이지들을 크롤링해온다
따라서 <button onClick ... , <div onClick ...으로 navigate하지 마세요
# 제목의 h1 ... h6까지 써서 작성해라
크롤링시 내용의 중요도를 정의한다
<div class=”h1”> 제목 1</div> 는 크롤링시 좋지 않아요
# 반응형 웹디자인시 모바일을 지원하는 페이지를 우선적으로 노출된다 (검색시 우선순위로 ++)
# Structured data
Html 뿐만 아니라 이 컨텐츠가 무엇인지 정의해줌
<div ..
<h1 ..
<p ..
<ol ..
<li ....
<li ....
...
Html만으로는 문서를 표현할뿐 문서의 내용을 표현하기는 어렵다. 따라서 itemtype에 http://schema.org/Recipe를 넣고 아래에 itemprop을 지정하여 구글봇이 html에 어떤 내용이 있는지 알 수 있게 해줄 수 있다
-> 상위 노출되고 , 다른 ui와 다르게 노출된다.(교촌치킨) 따라서 structured data를 사용하면 이점이 있다
Google search structured data구글링으로 정의방식은 참고할것
# Lighthouse 도구로 웹페이지 종합 검사를 할 수 있다
Audit 탭에서 돌리면 퍼포먼스, 접근성, 검색엔진최적화(SEO)를 볼 수 있다.
Web.dev에 들어가면 위 항목들을 어떻게 활용할 수 있는지 나옴
# 구글은 1초 내로 모든 컨텐츠가 랜더링 되어야한다. 네트워크가 안좋아도 최대 3초.
성능이 좋다의 판단기준.
# 나무위키가 ... 구글검색 최상위의 best practice임. (망고플레이트도...)
yelp , apple 사이트에서 description 참고
festa 도 참고
위 사이트들에서 seo best pratice 참고가능
# 구글의 search console에 등록하면 24~72h 내에 검색노출됨
크롤링 스케줄은 정확히 알수없음
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
Track 4. 3인3색
# 기술에 대한 진입장면을 낮추는것... 세미나의 이유
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
Track 5. 플러터와 다트2.0
#
1. 다트란?
자바스크립트를 대처할 수 있는 언어를 만들어낸게 다트 (ES6 까지 자바스크립트가 별로여서..)
# 다트 엔진 신규개발
Dart to js를 만드는 방식으로 선회
구글 어낼리틱스 대쉬보드는 다트를 사용함
# 브라우저 전용 언어 아니냐?-> 태생은 멀티플랫폼 언어임,
멀티플랫폼 개발을 위한 도구 중 하나,
강한 type시스템을 가지고 있음
ex.int에 long을 넣을 수 없는것
컴파일러의 type 추정 수준은 코틀린/스위프트 수준으로 올라옴
Ui를 조정하는 코드는 안드로이드 네이티브 보다는 좋음...(ui표현하기 편리)
(코틀린은 앙코라고...dsl 언어가 있음(ui 표현..))
# 문법비교 - 다트/코틀린/스위프트
등...
# 널러블/넌널러블 구분을 다트에도 넣을예정(null-safety)
# 다트의 매력
1. 일급함수지원 : typedef operation(val1, val2)
2. 상수 정규화(constant canonicalisation)
3. Mixin : smalltalk의 개념, 상속개념(수진적, 타입 재활용) mixin은 수평적/코드재활용
# 왜 플러터는 다트를 선택하였는가?
1. JIT/AOT 모두 지원 : jit=hot(stateful) reload, aot = production 최적화
2. UI 표현에 최적화된 문법
3. 기타 등등
# Jit는 프로그램 실행중 빨라짐 (실행 구간이 많아져야 빨라짐),
Aot는 프로그램 실행전
다트는 실제 바이너리화 되면 aot됨
'memo' 카테고리의 다른 글
github 명령어 (0) | 2018.11.18 |
---|---|
bit bucket (0) | 2018.11.09 |