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> Checklista wydajności Frontendu <br> </h1> <h4 align="center">🎮 Jedyna checklista wydajności Frontend, która działa szybciej, niż inne.</h4> <p align="center">Jedna prosta zasada: "Projektuj i koduj z wydajnością na uwadze"</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">Jak korzystać</a> • <a href="#contributing">Współtworzenie</a> • <a href="http://feedback.frontendchecklist.io/">Plan</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/mbiesiad/Front-End-Performance-Checklist">🇵🇱</a> </p> <p align="center"> <span>Inne checklisty:</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>

Spis treści

HTML
CSS
Czcionki
Obrazy
JavaScript
Serwer (w trakcie)
Frameworki JS (w trakcie)

Wprowadzenie

Wydajność jest sporym tematem, ale nie zawsze jest to tylko temat "backendu" lub "admina": to także odpowiedzialność frontendu. Lista kontrolna wydajności frontendu to wyczerpująca lista elementów, które powinieneś sprawdzić, a przynajmniej być jej świadomym, jako programista frontend i stosować to w swoim projekcie (osobistym i zawodowym).

Jak korzystać?

Dla każdej zasady będzie akapit wyjaśniający dlaczego ta zasada jest ważna i jak możesz to naprawić. Aby uzyskać więcej szczegółowych informacji, należy znaleźć linki, które będą wskazywać 🛠 narzędzia, 📖 artykuły lub 📹 media które mogą wypełnić listę kontrolną.

Wszystkie elementy w Checklista wyjdajności Frontend są niezbędne, aby osiągnąć najwyższy wynik wydajności, ale można znaleźć też wskaźnik, który pomoże w ustaleniu priorytetów niektórych zasad w stosunku do innych. Istnieją 3 poziomy priorytetu:

oznacza, że element ma niski priorytet.
oznacza, że element ma średni priorytet. Nie powinieneś unikać zajmowania się tą kwestią.
oznacza, że element ma wysoki priorytet. Nie można uniknąć przestrzegania tej zasady i wprowadzenia zalecanych poprawek.

Narzędzia wydajności

Lista narzędzi, których możesz użyć do testowania lub monitorowania swojej witryny lub aplikacji:

🛠 WebPagetest - Website Performance and Optimization Test
🛠 ☆ Dareboost: Website Speed Test and Website Analysis (użyj kuponu WPCDD20 dla -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 (Link do darmowej rejestracji)
🛠 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

Odnośniki

HTML

html

Zminifikowany HTML: Kod HTML jest minifikowany, komentarze, białe znaki i nowe wiersze są usuwane z plików produkcyjnych.

Czemu:

Usunięcie wszystkich niepotrzebnych spacji, komentarzy i atrybutów zmniejszy rozmiar kodu HTML i przyspieszy czas wczytywania strony w witrynie oraz oczywiście zmniejszy pobieranie pliku dla użytkownika.

Jak:

Większość frameworków ma wtyczki ułatwiające minifikację stron internetowych. Możesz użyć zestawu modułów NPM, które mogą wykonać zadanie automatycznie.
- 🛠 HTML minifier | Minify Code
- 🛠 Online HTML Compressor
- 📖 Experimenting with HTML minifier — Perfection Kills
Umieść tagi CSS zawsze przed tagami JavaScript: Upewnij się, że twój CSS jest zawsze ładowany przed kodem JavaScript.
```

<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>
```
Czemu:

Posiadanie tagów CSS przed JavaScriptem umożliwia lepsze równoległe pobieranie, co przyspiesza czas renderowania w przeglądarce.

Jak:

⁃ Upewnij się, że <link> i <style> w twoim <head> są zawsze przed twoim <script>.
- 📖 Ordering your styles and scripts for pagespeed
Zminimalizuj liczbę iframes: Używaj iframe tylko wtedy, gdy nie masz innych technicznych możliwości. Staraj się unikać iframe tak bardzo, jak potrafisz.
Optymalizacja wstępnego ładowania z pobieraniem wstępnym, dns-prefetch i prerender: Popularne przeglądarki mogą korzystać z dyrektywy tagu <link> i atrybutu "rel" z niektórymi słowami kluczowymi, aby wstępnie załadować określone adresy URL.

Czemu:

Pobieranie wstępne umożliwia przeglądarce ciche pobieranie niezbędnych zasobów potrzebnych do wyświetlenia treści, do których użytkownik może uzyskać dostęp w najbliższej przyszłości. Przeglądarka jest w stanie przechowywać te zasoby w pamięci podręcznej i przyspieszyć ładowanie stron internetowych, gdy używają różnych domen do zasobów strony. Po zakończeniu ładowania strony internetowej i upłynięciu czasu bezczynności przeglądarka rozpoczyna pobieranie innych zasobów. Gdy użytkownik przejdzie do określonego linku (już wstępnie pobranego), treść zostanie natychmiast wyświetlona.

Jak:

⁃ Upewnij się, że <link> w twojej sekcji <head>.

⬆ powrót do góry

CSS

css

Minifikacja: Wszystkie pliki CSS są minifikowane, komentarze, białe znaki i nowe wiersze są usuwane z plików produkcyjnych.

Czemu:

Po zminifikowaniu plików CSS zawartość ładuje się szybciej i do klienta wysyłanych jest mniej danych. Ważne jest, aby zawsze minifikować pliki CSS podczas produkcji. Jest to korzystne dla użytkownika, podobnie jak dla każdej firmy, która chce obniżyć koszty przepustowości i zmniejszyć zużycie zasobów.

Jak:

⁃ Użyj narzędzi, aby zminifikować pliki automatycznie przed kompilacją lub wdrożeniem lub w jej trakcie.
Konkatenacja: Pliki CSS są łączone w jednym pliku (nie zawsze dotyczy HTTP/2).
```

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


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

Jeśli nadal używasz protokołu HTTP/1, może być konieczne połączenie plików, mniej prawdopodobne jest, jeśli serwer używa protokołu HTTP/2 (należy wykonać testy).

Jak:

⁃ Użyj narzędzia online lub dowolnej wtyczki przed kompilacją plików lub podczas kompilacji lub wdrożenia, aby połączyć twoje pliki. <br> ⁃ Upewnij się oczywiście, że konkatenacja nie psuje twojego projektu.
- 📖 HTTP: Optimizing Application Delivery - High Performance Browser Networking (O'Reilly)
- 📖 Performance Best Practices in the HTTP/2 Era
Nieblokujące: Pliki CSS muszą być nieblokujące, aby nie dopuścić do poświęcenia czasu przez DOM.
```
<link rel="preload" href="global.min.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="global.min.css"></noscript>
```
Czemu:

Pliki CSS mogą blokować ładowanie strony i opóźniać jej renderowanie. Za pomocą preload można załadować aktualne pliki CSS, zanim przeglądarka zacznie wyświetlać zawartość strony.

Jak:

⁃ Musisz dodać atrybut rel z wartością preload i dodać as="style" w elemencie <link>.
Nieużywany CSS: Usuń nieużywane selektory CSS.

Czemu:

Usunięcie nieużywanych selektorów CSS może zmniejszyć rozmiar plików, a następnie przyspieszyć ładowanie zasobów.

Jak:

⁃ ⚠️ Zawsze sprawdź, czy we frameworku CSS, którego chcesz użyć, nie ma jeszcze kodu resetowania / normalizacji. Czasami możesz nie potrzebować wszystkiego, co znajduje się w pliku resetowania / normalizacji.
- 🛠 UnCSS Online
- 🛠 PurifyCSS
- 🛠 PurgeCSS
- 🛠 Chrome DevTools Coverage

CSS Critical: CSS critical (lub "above the fold") zbiera wszystkie CSS użyte do renderowania widocznej części strony. Jest osadzony przed głównym wywołaniem CSS i między <style></style> w pojedynczej linii (minifikowane, gdy możliwe).

Czemu:

Wprowadzenie critical CSS pomaga przyspieszyć renderowanie stron internetowych, zmniejszając liczbę żądań do serwera.

Jak:

Wygeneruj CSS critical za pomocą narzędzi online lub używając wtyczki takiej jak ta, którą opracował Addy Osmani.
- 📖 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

Osadzony lub wbudowany CSS: Unikaj używania wbudowanego lub osadzonego CSS wewnątrz swojego <body> (Nie dotyczy HTTP/2)

Czemu:

Jednym z pierwszych powodów jest to, że jest to dobra praktyka, aby oddzielić treść od projektu. Pomaga także w utrzymaniu kodu, który jest łatwiejszy w utrzymaniu i zapewnia dostęp do witryny. Ale jeśli chodzi o wydajność, to po prostu dlatego, że zmniejsza rozmiar pliku stron HTML i czas ładowania.

Jak:

Zawsze używaj zewnętrznych arkuszy stylów lub osadzaj CSS w swoim <head> (i postępuj zgodnie z innymi zasadami wydajności CSS)
- 📖 Observe CSS Best Practices: Avoid CSS Inline Styles
Analizuj złożoność arkuszy stylów: Analiza arkuszy stylów może pomóc w oznaczaniu problemów, redundancji i duplikowaniu selektorów CSS.

Czemu:

Czasami możesz mieć nadmiarowości lub błędy sprawdzania poprawności w swoim CSS, analiza plików CSS i usunięcie tych złożoności może pomóc ci przyspieszyć pliki CSS (ponieważ twoja przeglądarka będzie je szybciej czytać)

Jak:

Twój CSS powinien być zorganizowany, używanie preprocesora CSS może ci w tym pomóc. Niektóre narzędzia online wymienione poniżej mogą również pomóc w analizie i poprawieniu kodu.
- 🛠 TestMyCSS | Optimize and Check CSS Performance
- 🛠 CSS Stats
- 🛠 macbre/analyze-css: CSS selectors complexity and performance analyzer
- 🛠 Project Wallace jest jak CSS Stats ale przechowuje statystyki, abyś mógł śledzić zmiany

⬆ powrót do góry

Czcionki

fonts

📖 A Book Apart, Webfont Handbook

Webfont formats: Używasz WOFF2 w swoim projekcie lub aplikacji webowej.

Czemu:

Według Google, WOFF 2.0 Web Font format kompresji oferuje 30% średni zysk w porównaniu z WOFF 1.0. W takim przypadku dobrze jest użyć WOFF 2.0, WOFF 1.0 jako rezerwowego i TTF.

Jak:

Przed zakupem nowej czcionki sprawdź, czy dostawca podaje ci format WOFF2. Jeśli używasz darmowej czcionki, zawsze możesz użyć Font Squirrel, aby wygenerować wszystkie potrzebne formaty.
Używaj preconnect aby ładować twoje czcionki szybciej:
```
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
```
Czemu:

Po wejściu na stronę internetową urządzenie musi dowiedzieć się, gdzie znajduje się twoja witryna i z którym serwerem musi się połączyć. Twoja przeglądarka musiała skontaktować się z serwerem DNS i poczekać na zakończenie wyszukiwania przed pobraniem zasobu (czcionek, plików CSS...). Prefiksy i połączenia wstępne pozwalają przeglądarce wyszukać informacje DNS i rozpocząć nawiązywanie połączenia TCP z serwerem obsługującym plik czcionek. Zapewnia to wzrost wydajności, ponieważ zanim przeglądarka zacznie analizować plik css z informacjami o czcionce i odkryje, że musi zażądać pliku czcionki z serwera, będzie już wstępnie rozpoznawać informacje DNS i mieć otwarte połączenie do serwera gotowego w puli połączeń.

Jak:

⁃ Przed prefetchingiem twoich webfonts, użyj webpagetest, aby ocenić swoją stronę<br> ⁃ Poszukaj zapytań DNS w kolorze morskim i zwróć uwagę na żądany host <br> ⁃ Pobierz wstępnie twoje webfonts w <head> i ostatecznie dodaj te nazwy hostów, które powinieneś również pobrać
Rozmiar webfont: Rozmiary webfont nie przekraczają 300kb (zawarte wszystkie warianty)

📖 Font Bytes - Page Weight

Zapobiegaj Flashowi lub niewidocznemu tekstowi: Unikaj przezroczystego tekstu, dopóki Webfont jest ładowany

⬆ powrót do góry

Obrazy

images

📖 Image Bytes in 2018
Optymalizacja obrazów: Twoje obrazy są zoptymalizowane, skompresowane bez bezpośredniego wpływu na użytkownika końcowego.

Czemu:

Zoptymalizowane obrazy ładują się szybciej w przeglądarce i zużywają mniej danych.

Jak:

⁃ Spróbuj użyć efektów CSS3, gdy jest to możliwe (zamiast małego obrazu) <br> ⁃ Jeśli to możliwe, używaj czcionek zamiast tekstu zakodowanego na obrazach <br> ⁃ Użyj SVG <br> ⁃ Użyj narzędzia i określ poziom kompresji poniżej 85.
Format obrazów: Wybierz odpowiedni format obrazu.

Czemu:

Aby mieć pewność, że twoje obrazy nie spowalniają twojej witryny, wybierz format, który będzie odpowiadał twojemu obrazowi. Jeśli jest to zdjęcie, JPEG jest w większości przypadków bardziej odpowiedni, niż PNG lub GIF. Ale nie zapomnij spojrzeć na formaty nex-gen, które mogą zmniejszyć rozmiar twoich plików. Każdy format obrazu ma zalety i wady, ważne jest, aby je znać, aby umożliwić jak najlepszy wybór.

Jak:

⁃ Użyj Lighthouse w celu ustalenia, które obrazy mogą ostatecznie wykorzystać formaty następnej generacji (np. JPEG 2000m JPEG XR lub WebP) <br> ⁃ Porównaj różne formaty, czasem użycie PNG8 jest lepsze niż PNG16, a czasem nie.

Użyj obrazu wektorowego vs rastra/bitmapy: Preferuj używanie obrazu wektorowego zamiast obrazów bitmapowych (jeśli to możliwe).

Czemu:

Obrazy wektorowe (SVG) są zwykle mniejsze niż obrazy, a pliki SVG są responsywne i idealnie skalowane. Te obrazy mogą być animowane i modyfikowane przez CSS.

Wymiary obrazów: Ustaw atrybuty width i height na <img> jeśli znany jest ostateczny rozmiar renderowanego obrazu.

Czemu:

Jeśli ustawiona jest wysokość i szerokość, wymagana przestrzeń dla obrazu jest rezerwowana podczas ładowania strony. Jednak bez tych atrybutów przeglądarka nie zna rozmiaru obrazu i nie może zarezerwować dla niego odpowiedniej przestrzeni. Efektem będzie zmiana układu strony podczas ładowania (podczas ładowania obrazów).
Unikaj używania obrazów Base64: Możesz w końcu przekonwertować małe obrazy na base64, ale tak naprawdę nie jest to najlepsza praktyka.
Lazy loading: Obrazy poza ekranem są ładowane leniwie (zawsze dostępna jest rezerwowa kopia noscript).

Czemu:

Poprawi to czas odpowiedzi bieżącej strony, a następnie pozwoli uniknąć ładowania niepotrzebnych obrazów, których użytkownik może nie potrzebować.

Jak:

⁃ Użyj Lighthouse aby określić, ile obrazów jest poza ekranem.<br> ⁃ Użyj wtyczki JavaScript takiej jak poniżej, aby lazyloadować swoje obrazy. Pamiętaj, aby kierować reklamy tylko na obrazy poza ekranem. <br> ⁃ Upewnij się także, że alternatywne 'leniwe ładowane' obrazy są wyświetlane po najechaniu myszką lub po wykonaniu innych czynności przez użytkownika.
Responsywne obrazy: Pamiętaj, aby wyświetlać obrazy zbliżone do twojego rozmiaru wyświetlacza.

Czemu:

Niewielkie urządzenia nie potrzebują obrazów większych niż ich okno poglądu. Zalecane jest posiadanie wielu wersji jednego obrazu w różnych rozmiarach.

Jak:

⁃ Utwórz różne rozmiary obrazów dla urządzeń, na które chcesz kierować reklamy. <br> ⁃ Użyj srcset i picture aby dostarczyć wiele wariantów każdego obrazu.
- 📖 Responsive images - Learn web development | MDN

⬆ powrót do góry

JavaScript

javascript

Minifikacja JS: Wszystkie pliki JavaScript są pomniejszone, komentarze, białe znaki i nowe wiersze są usuwane z plików produkcyjnych (nadal ważne, używając HTTP/2).

Czemu:

Usunięcie wszystkich niepotrzebnych spacji, komentarzy i podziałów zmniejszy rozmiar plików JavaScript i przyspieszy czas wczytywania strony w twojej witrynie i oczywiście zmniejszy pobieranie pliku dla użytkownika.

Jak:

⁃ Skorzystaj z sugerowanych poniżej narzędzi, aby automatycznie zminimalizować pliki przed kompilacją lub wdrożeniem lub w jej trakcie.

Brak JavaScript w środku: (Dotyczy tylko witryny internetowej) Unikaj osadzania wielu kodów JavaScript w środku ciała (body). Zgrupuj kod JavaScript w plikach zewnętrznych lub ewentualnie w <head> lub na końcu strony (przed </body>).

Czemu:

Umieszczanie kodu JavaScript osadzonego bezpośrednio w twoim <body> może spowolnić twoją stronę, ponieważ ładuje się podczas budowania DOM. Najlepszą opcją jest użycie plików zewnętrznych z async lub defer aby uniknąć blokowania DOM. Inną opcją jest umieszczenie niektórych skryptów w twoim <head>. Przez większość czasu kod analityczny lub mały skrypt, który należy załadować, zanim DOM przejdzie do głównego przetwarzania.

Jak:

Upewnij się, że wszystkie twoje pliki są ładowane przy użyciu async lub defer i mądrze zdecyduj, jaki kod będziesz musiał wprowadzić w <head>.
- 📖 11 Tips to Optimize JavaScript and Improve Website Loading Speeds
Nieblokujący JavaScript: Pliki JavaScript są ładowane asynchronicznie za pomocą async lub odroczone za pomocą atrybutu defer.
```

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


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

JavaScript blokuje normalne parsowanie dokumentu HTML, więc gdy parser osiągnie znacznik <script> (szczególnie znajduje się w <head>), przestaje go pobierać i uruchamiać. Dodanie async lub defer jest wysoce zalecane, jeśli twoje skrypty są umieszczone na górze strony, ale mniej wartościowe, jeśli są tuż przed tagiem </body>. Ale dobrą praktyką jest zawsze używanie tych atrybutów, aby uniknąć problemów z wydajnością.

Jak:

⁃ Dodaj async (jeśli skrypt nie opiera się na innych skryptach) lub defer (jeśli skrypt opiera się na skrypcie asynchronicznym lub na nim polegał) jako atrybut tagu skryptu. <br> ⁃ Jeśli masz małe skrypty, możesz użyć wbudowanego skryptu zamiast skryptów asynchronicznych.
- 📖 Remove Render-Blocking JavaScript
- 📖 Defer loading JavaScript
Zoptymalizowane i zaktualizowane biblioteki JS: Wszystkie biblioteki JavaScript używane w twoim projekcie są konieczne (preferowana Vanilla JavaScript dla prostych funkcjonalności), zaktualizowane do najnowszej wersji i nie przytłaczają JavaScript niepotrzebnymi metodami.

Czemu:

W większości przypadków nowe wersje są dostarczane z optymalizacją i poprawką bezpieczeństwa. Powinieneś użyć najbardziej zoptymalizowanego kodu, aby przyspieszyć swój projekt i upewnić się, że nie spowolnisz swojej witryny lub aplikacji bez przestarzałej wtyczki.

Jak:

Jeśli twój projekt używa pakietów NPM, npm-check jest całkiem interesującą biblioteką do upgrade'u / aktualizacji bibliotek. Greenkeeper może automatycznie szukać zależności i sugerować aktualizację za każdym razem, gdy wychodzi nowa wersja.
- 📖 You may not need jQuery
- 📖 Vanilla JavaScript for building powerful web applications

Sprawdź limit wielkości zależności: Upewnij się, że korzystasz mądrze z zewnętrznych bibliotek, przez większość czasu możesz używać lżejszej biblioteki dla tej samej funkcjonalności.

Czemu:

Możesz mieć ochotę skorzystać z jednego z 745 000 pakietów, które możesz znaleźć z npm, ale musisz wybrać najlepszy pakiet dla swoich potrzeb. Na przykład MomentJS jest niesamowitą biblioteką, ale z wieloma metodami, których nigdy możesz nie użyć, właśnie dlatego utworzono Day.js. To tylko 2kB vs 16,4kB gz dla Moment.

Jak:

Zawsze porównuj i wybieraj najlepszą i lżejszą bibliotekę dla swoich potrzeb. Możesz także użyć narzędzi takich jak npm trends aby porównać liczbę pobrań pakietów NPM lub Bundlephobia aby poznać rozmiar swoich zależności.
JavaScript Profiling: Sprawdź problemy z wydajnością w swoich plikach JavaScript (i CSS).

Czemu:

Złożoność JavaScript może spowolnić działanie środowiska wykonawczego. Zidentyfikowanie tych możliwych problemów jest niezbędne, aby zapewnić jak najbardziej płynną obsługę.

Jak:

Użyj narzędzia Timeline Tool w Chrome Developer Tool, aby ocenić zdarzenia związane ze skryptami i znaleźć takie, które mogą zająć zbyt dużo czasu.
Zastosowanie Service Workers: Korzystasz z Service Workers w swoim PWA do buforowania danych lub wykonywania możliwych ciężkich zadań bez wpływu na komfort użytkowania aplikacji.

⬆ powrót do góry

Serwer

server-side

Twoja strona korzysta z HTTPS:

Czemu:

HTTPS jest przeznaczony nie tylko dla witryn e-commerce, ale dla wszystkich witryn, które wymieniają dane. Dane udostępniane przez użytkownika lub dane udostępniane podmiotowi zewnętrznemu. Współczesne przeglądarki ograniczają funkcjonalność witryn, które nie są bezpieczne. Na przykład: geolokalizacja, powiadomienia wypychane i pracownicy usług nie działają, jeśli Twoja instancja nie używa HTTPS. A dzisiaj łatwiej jest skonfigurować projekt z certyfikatem SSL niż wcześniej (i za darmo dzięki Let's Encrypt).

Waga strony < 1500 KB (idealnie < 500 KB): Zmniejsz rozmiar strony + zasoby tak bardzo, jak to możliwe.

Czemu:

Najlepiej jest spróbować kierować reklamy na <500 KB, ale stan sieci pokazuje, że mediana kilobajtów wynosi około 1500 KB (nawet na urządzeniach mobilnych). W zależności od docelowych użytkowników, połączenia sieciowego i urządzeń ważne jest, aby maksymalnie zmniejszyć całkowitą liczbę kilobajtów, aby zapewnić jak najlepszą obsługę.

Jak:

⁃ Wszystkie zasady znajdujące się na liście kontrolnej wydajności frontendu pomogą ci maksymalnie ograniczyć zasoby i kod.
- 📖 Page Weight
- 🛠 What Does My Site Cost?
- 🛠 web - Measure full page size in Chrome DevTools - Stack Overflow
Czasy ładowania strony < 3 sekund: Skróć maksymalnie czas ładowania strony, aby szybko dostarczać treści użytkownikom

Czemu:

Im szybsza jest twoja strona internetowa lub aplikacja, tym mniejsze prawdopodobieństwo wzrostu odrzuceń, innymi słowy masz mniejsze szanse na utratę użytkownika lub przyszłego klienta. Dowodem na to są wystarczające badania na ten temat.

Jak:

Użyj narzędzi online, takich jak Page Speed Insight lub WebPageTest aby przeanalizować, co może cię spowalniać, i skorzystaj z Listy kontrolnej wydajności frontendu, aby skrócić czas ładowania.
Time To First Byte < 1.3 sekund: Skróć maksymalnie, ile możesz, czas oczekiwania przeglądarki przed otrzymaniem danych.

Rozmiar cookie: Jeśli używasz plików cookie, upewnij się, że każdy plik cookie nie przekracza 4096 bajtów, a nazwa domeny nie zawiera więcej, niż 20 plików cookie.

Czemu:

Pliki cookie są wymieniane w nagłówkach HTTP między serwerami internetowymi, a przeglądarkami. Ważne jest, aby rozmiar plików cookie był jak najniższy, aby zminimalizować wpływ na czas reakcji użytkownika.

Jak:

Wyeliminuj niepotrzebne pliki cookie.

Minimalizowanie żądań HTTP: Zawsze upewnij się, że każdy zażądany plik jest niezbędny dla twojej witryny lub aplikacji.

📖 Combine external CSS
📖 Combine external JavaScript

Użyj CDN, aby dostarczyć swoje assety: Skorzystaj z CDN, aby szybciej dostarczać treści na cały świat.

Serwuj pliki z tego samego protokołu: Unikaj wyświetlania w witrynie plików pochodzących ze źródła za pomocą protokołu HTTP w witrynie, która używa na przykład HTTPS. Jeśli witryna korzysta z HTTPS, pliki zewnętrzne powinny pochodzić z tego samego protokołu.
Podaj pliki osiągalne: Unikaj żądania plików nieosiągalnych (404).

📖 How to avoid bad requests

Ustaw poprawnie nagłówki pamięci podręcznej HTTP: Ustaw nagłówki HTTP, aby uniknąć kosztownej liczby zwrotów między przeglądarką, a serwerem.

📖 Using cache-control for browser caching

Kompresja GZIP / Brotli jest włączona: Użyj metody kompresji, takiej jak Gzip lub Brotli, aby zmniejszyć rozmiar plików JavaScript. Dzięki plikowi o mniejszych rozmiarach użytkownicy będą mogli szybciej pobierać zasób, co poprawi wydajność.

⬆ powrót do góry

Wydajność i frameworki JS

Angular

📖 Angular Performance Checklist

React

Vue

📖 Vue - Useful Links|Style Guide and Performance

Wydajność oraz CMS

WordPress

🛠 Test Your Website Speed | WordPress Hosting by @WPEngine

Artykuły

Zalecane wtyczki

Tłumaczenia

Checklista wydajności frontend chce być dostępna również w innych językach! Nie wahaj się przesłać swojego wkładu!

🇵🇹 portugalski: fernandofawkes/Front-End-Performance-Checklist
🇨🇳 chiński: JohnsenZhou/Front-End-Performance-Checklist
🇷🇺 rosyjski: lex111/Front-End-Performance-Checklist
🇫🇷 francuski: WilliamDASILVA/Front-End-Performance-Checklist
🇰🇷 koreański: ParkSB/Front-End-Performance-Checklist
🇪🇸 hiszpański: dagerzuga/Front-End-Performance-Checklist
🇻🇮 wietnamski: huynhan147/Front-End-Performance-Checklist
🇵🇱 polski: mbiesiad/Front-End-Performance-Checklist

Współtworzenie

Otwórz issue lub stwórz pull request, aby zasugerować zmiany lub uzupełnienia.

Wsparcie

Jeśli masz jakieś pytania lub sugestie, nie wahaj się skorzystać z Discord lub Twittera:

Autor

Stworzone z ❤️ od David Dias

Współtwórcy

Ten projekt istnieje dzięki wszystkim ludziom, którzy wnoszą swój wkład. [Współtworzenie]. <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

Podziękowania dla wszystkich naszych backers! 🙏 [Zostań backer]

Sponsorzy

Wesprzyj ten projekt, zostając sponsorem. Twoje logo pojawi się tutaj wraz z linkiem do Twojej witryny. [Zostań sponsorem]

Licencja

MIT

Wszystkie ikony są dostarczane przez Icons8

⬆ powrót do góry

Stworzone przez: @thedaviddias polska wersja od @mbiesiad