Awesome

<h1 align="center"> <br> <a href="https://github.com/thedaviddias/Front-End-Performance-Checklist"><img src="https://raw.githubusercontent.com/thedaviddias/Front-End-Performance-Checklist/master/images/logo-front-end-performance-checklist.jpg" alt="Front-End Performance Checklist" width="170"></a> <br> <br> 프론트엔드 성능 체크리스트 <br> </h1> <h4 align="center">🎮 더 빠르게 작동하는 프론트엔드 성능 체크리스트</h4> <p align="center">한가지 단순한 규칙: "성능을 고려한 설계와 코드"</p> <p align="center"> <a href="http://makeapullrequest.com"> <img src="https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square" alt="PRs Welcome"> </a> <a href="https://discord.gg/btHQRkm"> <img src="https://img.shields.io/badge/chat-on_discord-4837E2.svg?style=flat-square" alt="Discord"> </a> <a href="https://opensource.org/licenses/MIT"> <img src="https://img.shields.io/badge/license-MIT-blue.svg?style=flat-square" alt="Licence MIT"> </a> </p> <p align="center"> <a href="#how-to-use">How To Use</a> • <a href="#contributing">Contributing</a> • <a href="http://feedback.frontendchecklist.io/">Roadmap</a> • <a href="https://www.producthunt.com/posts/front-end-performance-checklist">Product Hunt</a> </p> <p align="center"> <a href="https://github.com/JohnsenZhou/Front-End-Performance-Checklist">🇨🇳</a> <a href="https://github.com/WilliamDASILVA/Front-End-Performance-Checklist">🇫🇷</a> <a href="https://github.com/ParkSB/Front-End-Performance-Checklist">🇰🇷</a> <a href="https://github.com/fernandofawkes/Front-End-Performance-Checklist">🇵🇹</a> <a href="https://github.com/lex111/Front-End-Performance-Checklist">🇷🇺</a> <a href="https://github.com/GameWith/Front-End-Performance-Checklist">🇯🇵</a> </p> <p align="center"> <span>Other Checklists:</span> <br> 🗂 <a href="https://github.com/thedaviddias/Front-End-Checklist#---------front-end-checklist-">Front-End Checklist</a> • 💎 <a href="https://github.com/thedaviddias/Front-End-Design-Checklist#front-end-design-checklist">Front-End Design Checklist</a> </p>

소개

성능은 거대한 주제지만, 항상 "백엔드"나 "어드민"에만 국한되는 주제는 아닙니다: 프론트엔드도 성능에 대한 책임이 있습니다. 프론트엔드 성능 체크리스트는 프론트엔드 개발자로서 최소한 알아야하거나 체크해야할 요소들의 목록이며, 프로젝트에 적용해야 하는 것입니다.

어떻게 사용하나요?

각 규칙은 왜 이 규칙이 중요하고 어떻게 고칠 수 있는지 설명하고 있습니다. 만약 더 자세한 정보를 얻고 싶다면, 체크리스트를 완성시킬 수 있는 🛠 툴, 📖 아티클, 📹 미디어를 가리키는 링크를 찾아야 합니다.

프론트엔드 성능 체크리스트의 모든 항목은 최고의 성능을 내는데 필수적이지만, 일부 규칙의 우선 순위를 정하는데 도움을 주기 위해 우선 순위/영향을 3가지 레벨로 구분했습니다:

는 해당 항목이 프로젝트에 낮은 우선 순위와 영향을 가진다는 의미입니다.
은 해당 항목이 프로젝트에 중간 정도의 우선 순위와 영향을 가진다는 의미입니다. 이 항목에 대해 고민하는 것을 피해선 안 됩니다.
는 해당 항목이 프로젝트에 높은 우선 순위와 영향을 가진다는 의미입니다. 이 규칙을 피할 수 없으며, 권장되는 수정 사항을 적용해야 합니다.

성능 도구

웹사이트나 어플리케이션을 모니터링하고 테스트할 때 사용할 수 있는 도구들입니다:

🛠 WebPagetest - Website Performance and Optimization Test
🛠 ☆ Dareboost: Website Speed Test and Website Analysis (use the coupon WPCDD20 for -20%)
🛠 Treo: Page Speed Monitoring
🛠 GTmetrix | Website Speed and Performance Optimization
🛠 PageSpeed Insights
🛠 Web.dev
🛠 Pingdom Website Speed Test
📖 Make the Web Faster | Google Developers
🛠 Sitespeed.io - Welcome to the wonderful world of Web Performance
🛠 Calibre
🛠 Website Speed Test | Check Web Performance » Dotcom-Tools
🛠 Website and Server Uptime Monitoring - Pingdom (Free Signup Link)
🛠 Uptime Robot
🛠 SpeedCurve: Monitor front-end performance
🛠 PWMetrics - CLI tool and lib to gather performance metrics
🛠 Varvy - Page speed optimization
🛠 Lighthouse - Google
🛠 Checkbot browser extension - Checks for web performance best practices
🛠 Yellow Lab Tools | Online test to help speeding up heavy web pages
🛠 Speedrank - Web Performance Monitoring
🛠 DebugBear - Monitor website performance and Lighthouse scores
🛠 packtracker.io - Check your webpack bundle size on every pull request.
🛠 Exthouse - Analyze the impact of a browser extension on web performance

참고자료

HTML

html

HTML 압축: HTML 코드를 압축하고, 최종 파일에서 주석, 공백, 줄바꿈을 제거합니다.

왜:

불필요한 공백, 주석, 속성을 제거하면 HTML의 크기를 줄이고 페이지의 로딩 속도를 높일 수 있으며 사용자의 다운로드 시간을 줄일 수 있습니다.

어떻게:

대부분의 프레임워크에는 웹페이지를 압축시키는 플러그인이 있으며, 여러 NPM 모듈을 사용해 이 작업을 자동으로 처리할 수 있습니다.
- 🛠 HTML minifier | Minify Code
- 🛠 Online HTML Compressor
- 📖 Experimenting with HTML minifier — Perfection Kills
CSS 태그를 자바스크립트 태그 앞에 두기: CSS가 항상 자바스크립트 코드 전에 로드되는지 확인하세요.
```

<script src="jquery.js"></script>
<script src="foo.js"></script>
<link rel="stylesheet" href="foo.css"/>


<link rel="stylesheet" href="foo.css"/>
<script src="jquery.js"></script>
<script src="foo.js"></script>
```
왜:

자바스크립트 전에 CSS 태그를 두면 브라우저의 렌더링 속도를 높이는 병렬 다운로드가 가능해집니다.

어떻게:

<head>의 <link>와 <style>이 <script> 앞에 있는지 확인하세요.
- 📖 Ordering your styles and scripts for pagespeed
iframe 최소화: 다른 기술적 가능성이 없을 때만 iframe을 사용하고, 최대한 iframe을 사용하지 않도록 하세요.
Pre-load optimization with prefetch, dns-prefetch and prerender: Popular browsers can use directive on <link> tag and "rel" attribute with certain keywords to pre-load specific URLs.

Why:

Prefetching allows a browser to silently fetch the necessary resources needed to display content that a user might access in the near future. The browser is able to store these resources in its cache and speed up the way web pages load when they are using different domains for page resources. When a web page has finished loading and the idle time has passed, the browser begins downloading other resources. When a user go in a particular link (already prefetched), the content will be instantly served.

How:

⁃ Ensure that <link> is in your <head> section.

⬆ back to top

CSS

css

CSS 압축: CSS 파일을 압축하고, 최종 파일에서 주석, 공백, 줄바꿈을 제거합니다.

왜:

CSS 파일을 압축하면 클라이언트에게 더 적은 데이터를 전송하게 되며, 콘텐츠가 더 빨리 로드됩니다. 운영에서 CSS 파일을 압축하는 것은 중요한 일입니다. 이는 대역폭과 리소스 사용을 줄이고자 하는 모든 비즈니스에 있어 사용자에게 도움이 됩니다.

어떻게:

개발이나 빌드 중, 또는 그 전에 파일을 자동으로 압축해주는 툴을 사용하세요.
합치기: 여러 CSS 파일들을 하나의 파일로 합치세요. (HTTP/2 에서는 항상 유효하진 않습니다.).
```

<link rel="stylesheet" href="foo.css"/>
<link rel="stylesheet" href="bar.css"/>


<link rel="stylesheet" href="foobar.css"/>
```
왜:

여전히 HTTP/1을 사용하고 있다면 파일을 합칠 필요가 있습니다. 다만 서버가 HTTP/2라면 꼭 그렇지 않습니다. (테스트를 해봐야 합니다.)

어떻게:

개발이나 빌드 중, 또는 그 전에 파일을 합쳐주는 온라인 툴, 플러그인을 사용하세요. <br> ⁃ 물론 합치는 작업이 프로젝트를 방해하지는 않도록 하세요.
- 📖 HTTP: Optimizing Application Delivery - High Performance Browser Networking (O'Reilly)
- 📖 Performance Best Practices in the HTTP/2 Era
Non-blocking: DOM이 로드되는데 시간이 걸리지 않도록 CSS 파일은 non-blocking 되어야 합니다.
```
<link rel="preload" href="global.min.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="global.min.css"></noscript>
```
왜:

CSS 파일은 페이지 로드와 렌더링을 지연시킬 수 있습니다. preload를 통해 브라우저가 페이지의 콘텐츠를 보여주기 전에 CSS 파일을 로드할 수 있습니다.

어떻게:

rel 속성의 값을 preload로 주고, as="style"를 <link> 태그에 넣습니다.
Unused CSS: Remove unused CSS selectors.

왜:

사용하지 않는 CSS 선택자를 지우면 파일의 크기를 줄일 수 있으며, 로딩 속도를 높일 수 있습니다.

어떻게:

⚠️ 항상 사용하려는 CSS 프레임워크에 이미 reset / normalize 코드가 포함되어있지 않은지 체크하세요. 경우에 따라 reset / normalize 파일에 있는 것이 필요하지 않을 수도 있습니다.
- 🛠 UnCSS Online
- 🛠 PurifyCSS
- 🛠 PurgeCSS
- 🛠 Chrome DevTools Coverage

CSS 크리티컬: CSS 크리티컬 (또는 "어보브 더 폴드")은 페이지의 보이는 부분을 렌더링하는 데 사용되는 모든 CSS를 수집합니다. 이는 주요 CSS 호출 전, 그리고 <style></style> 사이에 한 줄로 임베디드됩니다. (가능하면 압축됩니다.)

왜:

중요한 CSS를 인라인으로 넣으면 서버 요청을 줄여 웹 페이지의 렌더링 속도를 높일 수 있습니다.

어떻게:

온라인 툴이나 Addy Osmani가 개발한 것과 같은 플러그인을 사용해 CSS 크리티컬을 생성하세요.
- 📖 Understanding Critical CSS
- 🛠 Critical by Addy Osmani on GitHub automates this.
- 📖 Inlining critical CSS for better web performance | Go Make Things
- 🛠 Critical Path CSS Generator - Prioritize above the fold content :: SiteLocity
- 📖 Reduce the size of the above-the-fold content

외부 또는 인라인 CSS: 외부 또는 인라인 CSS를 <body> 안에 두지 마세요. (HTTP/2에서는 유효하지 않습니다.)

왜:

이렇게 해야하는 첫 번째 이유는 디자인에서 콘텐츠를 분리하는 것이 좋은 관행이기 때문입니다. 또한 이는 코드 유지보수를 쉽게 만들고 사이트 접근성을 높이는 데도 도움이 됩니다. 성능과 관련해서는, 이것이 HTML 페이지의 파일 크기와 로딩 시간을 줄이기 때문입니다.

어떻게:

항상 외부 스타일 시트를 사용하거나 CSS를 <head>에 임베드하세요. (그리고 다른 CSS 성능 규칙을 따르세요.)
- 📖 Observe CSS Best Practices: Avoid CSS Inline Styles
스타일시트 복잡도 분석: 스타일시트를 분석하는 것은 불필요한 중복 CSS 선택자를 찾는 데 도움이 됩니다.

왜:

종종 중복, 또는 유효성 에러가 CSS 코드에서 발생할 수 있는데, CSS 파일을 분석하고 복잡성을 해결하면 CSS 파일의 속도를 높일 수 있습니다. (브라우저가 더 빨리 읽어 들이기 때문이죠.)

어떻게:

CSS 전처리기를 사용해 CSS를 조직해야 합니다. 아래에 나열된 일부 온라인 툴이 코드를 분석하고 바로 잡는데 도움이 될 수도 있습니다.
- 🛠 TestMyCSS | Optimize and Check CSS Performance
- 🛠 CSS Stats
- 🛠 macbre/analyze-css: CSS selectors complexity and performance analyzer
- 🛠 Project Wallace is like CSS Stats but stores stats over time so you can track your changes

⬆ back to top

Fonts

fonts

📖 A Book Apart, Webfont Handbook

웹폰트 포맷: 웹 프로젝트 또는 어플리케이션에서 WOFF2를 사용하세요.

왜:

Check before buying your new font that the provider gives you the WOFF2 format. If you are using a free font, you can always use Font Squirrel to generate all the formats you need.

어떻게:

새로운 폰트를 구매하기 전에 제공자가 WOFF2 포맷을 제공하는지 체크하세요. 만약 무료 폰트를 사용한다면, Font Squirrel을 통해 필요한 포맷을 생성할 수 있습니다.
폰트를 더 빨리 로드하기 위해 preconnect를 사용:
```
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
```
왜:

웹 사이트에 접속하면, 디바이스는 사이트의 위치와 연결해야 하는 서버를 찾아야 합니다. 브라우저는 DNS 서버를 찾고, 리소스 (폰트, CSS 파일...) 수집이 끝나기 전, 조회가 완료될 때까지 대기해야 합니다. 이때 prefetches와 preconnects는 브라우저가 DNS 정보를 찾고 폰트 파일을 호스팅하는 서버에 대한 TCP 연결을 허용합니다. 이렇게 하면 브라우저가 폰트 정보와 서버에 요청해야 하는 폰트 파일이 담긴 css 파일을 파싱할 때 미리 DNS 정보를 확인하고, 커넥션 풀에 있는 서버에 대한 개방형 연결을 준비함으로써 성능을 높일 수 있습니다.

어떻게:

⁃ 웹폰트를 사전 수집하기 전에, 웹사이트를 평가하기 위해 웹 페이지 테스트를 사용하세요. <br> ⁃ teal colored DNS를 찾고 요청 중인 호스트를 확인하세요. <br> ⁃ <head>에 둔 웹폰트를 사전 수집하고 함께 사전 수집할 호스트네임을 추가하세요.
웹 폰트 크기: 웹폰트 크기가 300kb를 넘지 않도록 하세요. (모든 파생 요소 포함)

📖 Font Bytes - Page Weight

플래시 또는 보이지 않는 텍스트 방지: 웹폰트가 로드될 때까지 투명한 텍스트를 사용하지 마세요.

⬆ back to top

Images

images

📖 Image Bytes in 2018
이미지 최적화: 이미지는 최적화되어야 하며, 최종 사용자에게 영향을 미치지 않는 선에서 압축되어야 합니다.

왜:

압축된 이미지는 브라우저에서 더 빨리 로드되고, 보다 적은 데이터를 소비합니다.

어떻게:

⁃ 가능하다면 CSS3 효과를 사용하세요. (작은 이미지 대신) <br> ⁃ 가능하면, 이미지에 인코딩된 텍스트 대신 폰트를 사용하세요. <br> ⁃ SVG를 사용하세요. <br> ⁃ 툴을 사용하고 압축 레벨을 85 미만으로 하세요.
이미지 형식: 적절한 이미지 형식을 선택하세요.

왜:

To ensure that your images don't slow your website, choose the format that will correspond to your image. If it's a photo, JPEG is most of the time more appropriate than PNG or GIF. But don't forget to look a the nex-gen formats which can reduce the size of your files. Each image format has pros and cons, it's important to know these to make the best choice possible.

어떻게:

⁃ Lighthouse를 사용해 이미지가 최종적으로 차세대 포맷(JPEG 2000m JPEG XR 또는 WebP)을 사용할 수 있는지 확인하세요. <br> ⁃ 다른 포맷을 비교하세요. 어떨 때는 PNG8을 사용하는 것이 PNG16을 사용하는 것보다 낫고, 어떨 때는 그렇지 않습니다.

벡터 이미지 vs 래스터/비트맵: 비트맵 이미지보다는 벡터 이미지를 사용하세요. (가능하다면)

왜:

벡터 이미지 (SVG)는 다른 이미지보다 작고, SVG는 반응성이 뛰어나며 완벽하게 크기가 변할 수 있습니다. 벡터 이미지는 CSS에 의해 수정되거나 움직일 수 있습니다.

이미지 크기: 최종적으로 나타나는 이미지 크기를 안다면 <img>에 width와 height 속성을 명시하세요.

왜:

높이와 너비가 설정되어 있으면 페이지가 로드됐을 때 이미지가 필요로하는 공간이 예약됩니다. 하지만, 이 속성이 없다면, 브라우저는 이미지의 크기를 알 수 없고, 적절한 공간을 예약해 둘 수 없습니다. 그러면 페이지를 로딩하는 중에 레이아웃이 변하는 현상이 발생합니다. (이미지를 로드하는 동안)
Base64 이미지 사용 지양: base64를 통해 결과적으로 작은 이미지를 얻을 수 있지만, 이것이 최고의 방법은 아닙니다.
레이지 로딩: 이미지를 레이지 로딩시키세요. (noscript 폴백이 언제나 제공됩니다.)

어떻게:

⁃ Lighthouse를 사용해 얼마나 많은 이미지가 오프스크린되는 지 확인하세요. <br> ⁃ 이미지를 레이지 로드시켜주는 자바스크립트 플러그인을 사용하세요. Make sure you target offscreen images only. <br> ⁃ Also make sure to lazyload alternative images shown at mouseover or upon other user actions.
반응형 이미지: 디스플레이 크기에 맞는 이미지를 사용하세요.

왜:

작은 디바이스에서는 뷰포트보다 큰 이미지가 필요하지 않습니다. 서로 다른 크기의 이미지를 여러 버전으로 제공하는 것을 추천합니다.

어떻게:

⁃ 원하는 타겟 디바이스에 따라 다른 크기의 이미지를 만드세요. <br> ⁃ srcset과 picture를 사용해 각 이미지의 여러 버전을 제공하세요.
- 📖 Responsive images - Learn web development | MDN

⬆ back to top

JavaScript

javascript

JS 압축: JavaScript 파일을 압축하고, 최종 파일에서 주석, 공백, 줄바꿈을 제거합니다. (HTTP/2에서도 여전히 유효합니다.)

왜:

불필요한 공백, 주석, 개행을 제거하면 자바스크립트 파일의 크기를 줄이고 페이지의 로딩 속도를 높일 수 있습니다.그리고 사용자의 다운로드 시간을 줄일 수 있습니다.

어떻게:

개발이나 빌드 중, 또는 그 전에 파일을 자동으로 압축해주는 툴을 사용하세요.

JavaScript 안에 두지 않기: (웹사이트에서만 유효합니다.) 여러 자바스크립트 코드를 바디 중간에 두지 마세요. 자바스크립트 코드를 다시 그룹화해 외부 파일이나 <head> 또는 페이지의 마지막(</body> 이전)에 두도록 하세요.

왜:

자바스트립트 임베디드 코드를 <body>에 두면 DOM이 구성되는 과정에서 코드가 로드되기 때문에 페이지 속도를 떨어뜨릴 수 있습니다. 가장 좋은 옵션은 외부 파일을 async 또는 defer 속성과 함께 사용하여 DOM 로딩을 막지 않도록하는 것입니다. 또 다른 옵션은 스크립트를 <head>에 두는 것입니다. 대부분의 시간 분석 코드 또는 DOM이 주요 처리부분에 도달하기 전에 로드되어야 하는 작은 스크립트를 둘 수 있습니다.

어떻게:

모든 파일이 async 또는 defer를 통해 로드되는지 확인하세요. 그리고 <head>에 삽입할 코드를 현명하게 결정하세요.
- 📖 11 Tips to Optimize JavaScript and Improve Website Loading Speeds
Non-blocking 자바스크립트: 자바스크립트 파일을 비동기적으로 로드하기 위해 async를 사용하거나 지연시키기 위해 defer 속성을 사용하세요.
```

<script defer src="foo.js"></script>


<script async src="foo.js"></script>
```
왜:

자바스크립트는 HTML 문서의 파싱을 차단하기 때문에, 파서는 <script> 태그에 도달할 때 (특히 <head> 안에 있을 때) 파싱을 멈추고 스크립트를 실행합니다. 스크립트를 페이지의 상단에 두는 경우 async 또는 defer를 사용하는 것이 적극 권장됩니다만, 만약 </body> 태그 바로 앞에 스크립트를 두는 경우 중요도가 떨어집니다. 하지만 언제나 이 속성을 사용하여 성능 이슈를 피하는 것은 좋은 습관입니다.

어떻게:

⁃ async (만약 스크립트가 다른 스크립트에 의존하지 않을 경우) 또는 defer (만약 스크립트가 비동기 스크립트에 의존할 경우) 속성을 스크립트 태그에 추가하세요. <br> ⁃ 만약 스크립트가 작다면, 비동기 스크립트 위에 인라인 스크립트를 둘 수도 있습니다.
- 📖 Remove Render-Blocking JavaScript
- 📖 Defer loading Javascript
최적화와 JS 라이브러리 업데이트: 프로젝트에는 라이브러리가 필요하며 (단순한 기능을 위해 바닐라 자바스크립트를 지향하세요.), 이들을 최신버전으로 업데이트하고 불필요한 메소드들이 당신의 자바스크립트 코드를 압도하지 않도록 하세요.

왜:

대부분의 경우, 새로운 버전은 최적화되고 보안 패치가 적용됩니다. 페이지의 속도를 높이기 위해 코드를 최적화해야 하며, 웹사이트나 앱을 느리게 만들지 않기 위해 오래된 플러그인을 사용하지 않는지 확인해야 합니다.

어떻게:

만약 프로젝트가 NPM 패키지들을 사용한다면, npm-check가 라이브러리를 업그레이드 / 업데이트하는 데 유용할 것입니다. Greenkeeper can automatically look for your dependencies and suggest an update every time a new version is out.
- 📖 You may not need jQuery
- 📖 Vanilla JavaScript for building powerful web applications

디펜던시 크기 제한: 외부 라이브러리를 현명하게 사용하세요. 대부분의 경우, 똑같은 기능을 하지만 더 가벼운 라이브러리를 찾을 수 있습니다.

왜:

745 000 패키지 중 사용하려는 패키지 하나를 npm에서 찾을 수 있습니다. 하지만 가장 좋은 패키지를 골라야 합니다. 예를 들어, MomentJS는 굉장한 라이브러리지만, 많은 메소드를 사용하지 않을 것입니다. Day.js가 만들어진 이유죠. Day.js 2kB vs Moment 16.4kB gz 입니다.

어떻게:

항상 더 가볍고 좋은 라이브러리를 찾기 위해 비교하세요. npm trends와 같은 툴을 이용해 NPM 다운로드 수를 비교하거나 Bundlephobia를 통해 디펜던시의 크기를 알 수 있습니다.
JavaScript 프로파일링: 자바스크립트 파일의 성능 문제를 체크하세요. (CSS도 같이 체크하세요.)

왜:

자바스크립트 복잡도는 런타임 성능을 떨어뜨릴 수 있습니다. 위험성이 있는 이슈를 확인하는 것은 매끄러운 사용자 경험을 제공하는 데 필수적입니다.

어떻게:

크롬 개발자 도구의 타임라인 툴을 이용해 스크립트 이벤트를 테스트하고 너무 오랜 시간을 소모하는 이벤트를 찾아내세요.
Use of Service Workers: You are using Service Workers in your PWA to cache data or execute possible heavy tasks without impacting the user experience of your application.

⬆ back to top

Server

server-side

Your website is using HTTPS:

Why:

HTTPS is not only for ecommerce websites, but for all websites that are exchanging data. Data shared by a user or data shared to an external entity. Modern browsers today limit functionalities for sites that are not secure. For example: geolocation, push notifications and service workers don't work if your instance is not using HTTPS. And today is much more easy to setup a project with an SSL certificate than it was before (and for free, thanks to Let's Encrypt).

웹페이지 크기 < 1500 KB: (이상적인 크기 < 500 KB) 페이지의 크기 + 리소스를 최대한 줄이세요

왜:

500 KB 미만이 이상적이지만 웹의 상태에 따라 킬로바이트의 중앙값이 1500 KB 정도로 표시됩니다. (모바일에서도 그렇습니다.) 최상의 사용자 경험을 제공하려면 타겟 사용자, 네트워크 연결, 디바이스에 따라 총 킬로바이트를 최대한 줄여야 합니다.

어떻게:

프론트엔드 성능 체크리스트의 모든 규칙들은 리소스와 코드를 최대한 줄이도록 하고 있습니다.
- 📖 Page Weight
- 🛠 What Does My Site Cost?
- 🛠 web - Measure full page size in Chrome DevTools - Stack Overflow
페이지 로드 시간 < 3초: 페이지 로드 시간을 최대한 줄여 사용자에게 콘텐츠가 빠르게 전송되도록 하세요.

왜:

웹사이트나 앱이 빨라질수록 바운스 증가 가능성이 줄어듭니다. 한편 사용자나 미래의 클라이언트를 잃을 가능성도 줄어듭니다. 이 주제에 대한 많은 연구가 이를 증명합니다.

어떻게:

Page Speed Insight 또는 WebPageTest와 같은 온라인 툴을 이용해 무엇이 페이지를 느리게 만드는지 분석하고, 프론트엔드 체크 리스트를 이용해 로드 시간을 개선하세요.
첫 번째 바이트 시간(TTFB) < 1.3초: 브라우저가 데이터를 받기 전까지 대기하는 시간을 최대한 줄이세요.

쿠키 크기: 만약 쿠키를 사용한다면 각 쿠키가 4096 바이트를 넘어서는 안 되며, 도메인 네임이 20개 이상의 쿠키를 가져서는 안 됩니다.

왜:

쿠키는 HTTP 헤더에서 웹 서버와 브라우저 사이에 교환됩니다. 사용자의 응답 시간에 미치는 영향을 최소화하기 위해서는 쿠키의 크기를 최대한 줄여야 합니다.

어떻게:

불필요한 쿠키를 제거하세요.

HTTP 요청 최소화: 항상 모든 파일의 요청이 웹사이트나 어플리케이션에 필수적인지 확인하세요.

📖 Combine external CSS
📖 Combine external Javascript

CDN을 통한 어셋 제공: 전 세계에 콘텐츠를 더 빠르게 제공하기 위해 CDN을 사용하세요.

동일한 프로토콜에서 파일 제공: Avoid having your website serving files coming from source using HTTP on your website which is using HTTPS for example. If your website is using HTTPS, external files should come from the same protocol.
연결 가능한 파일 제공: 연결 불가능한 파일(404)을 요청하지 마세요.

📖 How to avoid bad requests

올바른 HTTP 캐시 헤더 설정: 브라우저와 서버 사이 비용이 큰 왕복을 피하도록 HTTP 헤더를 설정하세요.

📖 Using cache-control for browser caching

GZIP / Brotli 압축 활성화: Use a compression method such as Gzip or Brotli to reduce the size of your JavaScript files. With a smaller sizes file, users will be able to download the asset faster, resulting in improved performance.

⬆ back to top

Performances and JS Frameworks

Angular

📖 Angular Performance Checklist

React

Vue

📖 Vue - Useful Links|Style Guide and Performance

Performances and CMS

WordPress

🛠 Test Your Website Speed | WordPress Hosting by @WPEngine

Articles

Plugins recommended

Vue

Performances and CMS

WordPress

Articles

Plugins recommended

Translations

프론트 엔드 성능 체크리스트가 다른 언어로 읽히길 바랍니다! 컨트리뷰션을 망설이지 말아주세요!

🇵🇹 Portuguese: fernandofawkes/Front-End-Performance-Checklist
🇨🇳 Chinese: JohnsenZhou/Front-End-Performance-Checklist
🇷🇺 Russian: lex111/Front-End-Performance-Checklist
🇫🇷 French: WilliamDASILVA/Front-End-Performance-Checklist
🇰🇷 Korean: ParkSB/Front-End-Performance-Checklist
🇵🇹 Portuguese: fernandofawkes/Front-End-Performance-Checklist
🇨🇳 Chinese: JohnsenZhou/Front-End-Performance-Checklist
🇷🇺 Russian: lex111/Front-End-Performance-Checklist
🇫🇷 French: WilliamDASILVA/Front-End-Performance-Checklist
🇰🇷 Korean: ParkSB/Front-End-Performance-Checklist
🇪🇸 Spanish: dagerzuga/Front-End-Performance-Checklist
🇻🇮 Vietnamese : huynhan147/Front-End-Performance-Checklist
🇯🇵 Japanese: GameWith/Front-End-Performance-Checklist
🇵🇱 Polish: mbiesiad/Front-End-Performance-Checklist

Contributing

이슈를 열거나 풀 리퀘스트를 보내 변경 사항이나 추가점을 제안하세요.

Support

질문이나 제안이 있다면 Gitter나 트위터 사용을 망설이지 마세요:

Author

**Build with ❤️ by David Dias

Contributors

This project exists thanks to all the people who contribute. [Contribute]. <a href="https://github.com/thedaviddias/Front-End-Performance-Checklist/graphs/contributors"> <img src="https://opencollective.com/front-end-checklist/contributors.svg?width=890" /> </a>

Backers

Thank you to all our backers! 🙏 [Become a backer]

License

MIT

All icons are provided by Icons8

⬆ back to top

Awesome

목차

소개

어떻게 사용하나요?

성능 도구

참고자료

HTML

CSS

Fonts

Images

JavaScript

Server

Performances and JS Frameworks

Angular

React

Vue

Performances and CMS

WordPress

Articles

Plugins recommended

Vue

Performances and CMS

WordPress

Articles

Plugins recommended

Translations

Contributing

Support

Author

Contributors

Backers

Sponsors

License