- Today
- Total
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- map
- deep dive
- 모던 자바스크립트 deep dive
- 프론트엔드
- js
- 네트워크
- async
- error
- 상태관리
- Angular
- get
- 이터러블
- Java Script
- 백준 실버
- 자바스크립트
- 그림으로 배우는 http&network
- 백준
- 알고리즘
- 비동기
- git
- html
- C++
- 모던 자바스크립트
- React
- 웹
- 에러처리
- JavaScript
- git error
- http
- es6
목록Front-End (74)
sharingStorage

서론최근 성능에 대한 관심을 보이면서 몇몇 글모임의 상세페이지에서만 유독 좋지 않은 LCP지표를 보이고 있는 것을 확인하였습니다. 이것에 대한 원인을 유추하던 중 presigned url을 활용하여 서비스를 운영하며 10MB에 육박하는 대용량 이미지가 아무런 전처리나 최적화 작업 없이 S3에 업로드되었고 이것이 곧 LCP의 Load Time과 전체 Network 요청 리소스에 큰 영향을 주고있는 것을 확인하였습니다. 이러한 문제를 NEXT JS에서는 모든 이미지를 WebP로 변환하는 과정을 통해 이미지 최적화를 진행한다는 것에서 착안하여 업로드 과정에서 이미지 최적화를 진행하여 개선해보려고 합니다. 위에서 말씀드린 성능에 대해 조금 더 자세히 확인해보자면 아래와 같이 유독 LCP점수만 낮게 측정된 것을..

이 글은 한 초보 개발자의 간단한 질문에서 부터 시작되었다. 헤더헤더 123123123 위 코드는 header의 fixed를 통해 상단에 고정시키고 main에 컨텐츠를 담기 위해 간단한 작업을 할 때 사용하는 코드인데 위 코드를 실행하면 우리가 의도한 바대로 작동하지 않는다. 위 코드를 실행해본 결과이다 body의 위치를 이해하기 쉽도록 green을 주었다. 분명 main에 margin-top을 주었는데 왜 형제 요소인 fixed 헤더까지 내려올까?? 문제점 1 fixed에 offset값을 넣지 않았다.너무나 당연한 답입니다.fixed는 뷰포트 기준으로 top, left, rigth, bottom에 의해 결정되는데 이를 적용하지 않았을 때 초기위치에 absolute값과 동일하게 적용..

들어가며이전 시간엔 web성능에서 중요한 지표인 core web vitals와 성능을 확인할 수 있는 도구인 Lighthouse를 알아보았으니 이를 통해 현재 서비스중인 mile의 성능을 확인하고 개선해보려고 합니다.가장 먼저 Lighthouse로 현재 mile의 성능을 측정해본 결과 main페이지부터 아래와 같은 엄청나게 성능이 좋지 않다는 것을 확인했고 vite-bundle-visualizer 와 같은 도구로 번들사이즈를 확인하며 데모데이를 향해 달려가면서 놓친 부분과 크고 작은 실수들을 바로 잡으면서 성능을 개선해보겠습니다.성능 확인과 번들사이즈 확인아래와 같이 Lighthouse로 엄청나게 좋지 않은 메인페이지의 성능을 확인하였고 이와 관련해서 vite-bundle-visualizer를 사용하여 ..

이번엔 웹서비스의 성능지표 core web vitals를 공부해보고 lighthouse의 성능지표에는 무엇이 있는지 알아보겠습니다.웹 성능 개선을 고려해야하는 이유웹 성능은 객관적인 측정치(로딩 시간, 초당 프레임 수, 상호작용에 반응할 수 있게 되는 시간)와 유저의 주관적인 경험(콘텐츠의 로딩 시간이 얼마나 길게 느껴지는지)이 포함됩니다. 우리는 웹 성능 개선을 왜 고려해야할까요?웹성능 지표는 비지니스에도 많은 영향을 주기 때문입니다. 일반적으로 빠른 로딩은 좋은 사용자경험(UX)을 제공하고 반대로 사용자가 웹사이트에 들어갔을 때 하얀 화면을 노출시키거나 로딩이나 지연이 길게 발생하면 사용자는 자연스럽게 이탈하게 됩니다.아래는 2017년 Google 모바일 부문 글로벌 제품 리드인 Daniel An이 ..

원래의 mile 서비스는 다음과 같이 각 페이지 폴더 내에 커스텀훅을 모아두는 페이지 상단에 객체로 키를 정의해두었습니다.“커스텀훅을 사용해서 관심사를 분리하고, 객체 키를 사용해서 오타나 중복 등의 휴먼에러를 줄인다.” 라는 접근으로 키를 구성하였지만 이런 과정에서 두가지 놓친 부분이 있습니다. 쿼리키의 hierarchy 구조를 잘 활용하지 못하는 방향으로 구성되어있었고 , 키를 따로 분리해서 관리하여 다른 페이지(컴포넌트)와의 쿼리키는 여전히 중복 가능성이 존재한다는 것입니다. 이로인해 쿼리키를 invalidate할때 관련된 여러 쿼리를 invalidate하는데에 어려움있고 키가 고유해야한다는 가장 중요한 부분을 놓칠 수도 있다는 문제점이 발생하였고 이제는 MVP를 구성하고 데모데이에 우리의 서비스..

null과 undefined의 차이는 이미 알고있었지만 현재 진행하고있는 ASAP(최적의 회의시간 도출 서비스)에 대한 코드리뷰를 진행하던 중 팀원이 string타입인 시작시간을 undefined로 초기화하면 안되는 이유에 대해 물어보았을 때 설명하면서 내 지식에 공백이 있음을 느꼈다.그래서 undefined와 null을 deep dive해보고 그 두개를 정확히 구분하지 않았을 때 발생하는 side Effect에 대해서 고민해보는 시간을 가져보려고 한다. null과 undefined를 한줄 요약하면개발자가 의도적으로 "값이 없음"을 나타내기 위해 할당하는 값은 null값이 초기화되지 않음을 자바스크립트 엔진이 표현한 값은 undefined이다. MDN이 말하는 null과 undefined일단 본인이 자명..

useId 접근성 속성에 전달되는 특별한 ID를 만드는 hooks import { useId } from 'react'; function PasswordField() { const passwordHintId = useId(); Usage 접근성 attributes 를 위한 특별한 ID를 만들기 위해 몇개의 관련된 elements 에 대한 ID를 만들기 위해 모든 생성된 ID들에 대한 접두사를 지정하기 위해 클라이언트와 서버가 같은 접두사 ID를 사용하기 위해 Parameters useId는 어떠한 parameter도 존재하지 않습니다. Returns useId는 컴포넌트 내에 useId 호출과 관련된 특별한 ID string을 반환합니다. 주의 사항 useIdHook이므로 컴포넌트의 최상위 수준 이나 자..

들어가기전에.. nextjs는 13버전 이전과 13버전 이후가 완전히 다른 프레임워크라고 해도 무방할 정도로 큰 차이가 있습니다. 일반적으로 나와있는 아티클들은 구버전일 가능성이 높아서 공부하실 때 nextjs 공식문서 - Using App Router부분을 참고해서 크로스체크하시는걸 추천드립니다! 또한 제가 작성한 아티클이 틀린 부분이 없는지, 버전이 맞는지 잘 검수하려고 노력했지만 혹시 구버전에 대한 설명이 있다면 피드백주시면 감사하겠습니다. What? Next.js란 풀 스택 어플리케이션을 개발하기 위한 리액트 프레임워크입니다. Next.js는 번들링, 컴파일 등과 같이 React에 필요한 도구를 추상화하고 자동으로 구성하고 이는 곧 개발자에게 애플리케이션 개발에 집중하도록 도와줍니다. How? A..

React 커스텀훅 what ? 컴포넌트간의 hook 로직을 공유하기 위해 사용하는 사용자가 커스텀한 hook입니다. 다음은 공식문서에서 발췌한 예시 코드입니다. import { useState, useEffect } from 'react'; export default function StatusBar() { const [isOnline, setIsOnline] = useState(true); useEffect(() => { function handleOnline() { setIsOnline(true); } function handleOffline() { setIsOnline(false); } window.addEventListener('online', handleOnline); window.addEve..

쿠키를 사용한 상태관리 HTTP는 stateless 프로토콜이기 때문에 과거에 교환했던 리퀘스트와 리스폰스의 상태를 관리하지 않습니다. 이는 과거 상태를 근거로 한 현재 리퀘스트 처리는 어렵다는 것을 뜻합니다. 쿠키 이러한 stateless한 특성으로 인해 발생하는 문제를 해결하기 위해 도입된 시스템. 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트 상태를 파악하기 위한 시스템 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 쿠키를 클라이언트에 보존하고 다음 리퀘스트 요청에 자동으로 쿠키 값을 넣어서 송신 이로 인해 서버는 클라언트가 보낸 쿠키를 확인하여 어느 클라이언트가 접속했는지나 서버상의 기록을 확인할 수 있다. 쿠키 추가 공부 쿠키는 브라우저에 저장되는 작은 크기의 문자열로, ..