Der Zweck der Front-End-Leistungsoptimierung besteht darin, das Laden der Seite zu beschleunigen und Benutzern ein besseres Benutzererlebnis zu bieten. Wie kann man also die Front-End-Leistung optimieren? Wie geht das konkret? Der folgende Artikel stellt Ihnen einige Wissenspunkte zur Front-End-Leistungsoptimierung vor.
Lesen Sie die folgenden drei Fragen immer wieder.
- Verschiedene Leute haben Sie gefragt: Was ist Front-End-Leistungsoptimierung?
- Verschiedene Interviewer haben Sie gefragt: Was haben Sie zur Optimierung der Front-End-Leistung getan? Haben Sie sich jemals gefragt: Jemand hat mich gefragt, welche
Antwort- bei der Optimierung der Front-End-Leistung lauten sollte? Haben Sie Ihre eigenen Antworten zum Thema
Leistungsoptimierung- ? Das kann dazu führen, dass technische Experten mit Ihnen darüber diskutieren, und es kann auch dazu führen, dass Anfänger zustimmend nicken.
Wenn ja, wo ist dann Ihre Antwort?
Lassen Sie uns zunächst eines besprechen, wie ein Frontend-Projekt von der Konzeption bis zur Umsetzung verläuft
Zum Beispiel die gesamte Tmall-Homepage. Es gibt viele Antworten. Schauen Sie, ob Ihnen eine einfällt.
以上，有命中你的某个点吗？ 不管有木有道理，这是你想到的点吗？是不是总感觉好像少了点什么？
本篇文章不细讲其它内容。 但到这了就得提一嘴，留个印象。
- 系统层设计
- 一个新系统留20%来满足当前已有业务。 剩下80% 用来系统演进。可以思考下，天猫首页一直变，却依然能保证性能达标。
- 业务层设计
- 已有业务是否与其它业务产生了耦合，是否存在前置业务，如果有那前置业务的权限又在哪里。已有业务是否能根据系统演进程度不断兼容新业务？
- 应用层设计
- 例如微前端，例如组件库，例如
npm install
- webpack优化
- 骨架屏
- 路有动态按需加载
- 代码层设计
- 写好高性能React 代码？如何利用好Vue3 时间切片？
- 不说了。太初级的浪费慢慢积累就好。
所以，你应该发现了“总感觉好像少了点什么” 是少在哪里了。对，前端性能优化不仅仅是应用层面、代码层的优化，更重要的是系统层、业务层的优化。
看了以上的心理预设，那接下来就进入正式进入主题吧。
性能优化流程
尝试着走完下面这个流程：
Zusammenfassung
Haben Sie nun ein umfassendes Verständnis der Front-End-Leistungsoptimierung? Wenn wir über Leistungsoptimierung sprechen, müssen wir oft zuerst darüber sprechen, wie die Leistung „diagnostiziert“ werden kann. In den meisten Fällen werden Sie nicht gefragt, wie die Leistung überwacht wird. (Die Stimme wird immer leiser...)
Als nächstes sprechen wir ausführlich über Optimierungsmethoden
Verschiedene Optimierungsmethoden zum Öffnen des ersten Bildschirms in Sekunden
1. Lazy Loading
Eine davon Die häufigsten Optimierungsmethoden.
Lazy Loading bedeutet, dass während des langen Seitenladevorgangs wichtige Inhalte zuerst geladen werden und unkritische Inhalte verzögert werden. Wenn wir beispielsweise eine Seite öffnen und deren Inhalt den sichtbaren Bereich des Browsers überschreitet, können wir zuerst den Inhalt des Front-End-sichtbaren Bereichs laden und dann den restlichen Inhalt bei Bedarf laden, nachdem er in den sichtbaren Bereich gelangt ist.
Gib mir eine Kastanie. Ausgewählt auf der Tmall-Homepage. Oben abgebildet.
Es ist zufällig das Tmall 618-Event. Dies ist eine Auswahl der IOS-Version der Tmall-Homepage. Wenn Sie die Tmall-Homepage-Auswahl häufig besuchen, werden Sie feststellen, dass sie fast unsichtbares Surfen ermöglicht. Lazy Loading wird hier sehr gut eingesetzt. Natürlich wird dieser Effekt nicht nur durch Lazy Loading erzielt.
Das ist nur Lazy Loading. Was bewirkt die Tmall-Homepage-Auswahl? Erraten Sie, was.
Lazy Loading
- Picture Lazy Loading
- Bilder werden von
native zwischengespeichert. native做过缓存的。
- 在可视区域出现才会加载
- 卡片预先加载（懒加载的时机改变）
- 并不是进入可视区域才加载卡片的。而是当上一张卡片进入可视区域就预先加载下一张卡片。 因为相对于图片，加载卡片UI会快得多。 这也是无痕浏览的保障之一。
- 动画懒加载
- 假如你快速的进行划屏滚动，
List滚动高度发生很大变化，那请求数据最终还是会敌不过你的高速滑动。也就是说，在没有新的数据之前你看不到下一张卡片了，这是你必须等待了。这时候就会有一个loading的动画显示，接着等拿到了新数据，新卡片就会出现并且自动完全滑入可视区域。
- 这里会有人说了，
IOS的阻尼本来就会使得动画、滚动效果更加顺畅。在这里为想说的是，Android
Die Karte wird nur geladen, wenn sie im sichtbaren Bereich erscheint
Die Karte ist vorgeladen (der Zeitpunkt des verzögerten Ladens ändert sich)Die Karte wird nicht geladen, wenn sie in den sichtbaren Bereich gelangt. Stattdessen wird die nächste Karte vorgeladen, wenn die vorherige Karte in den sichtbaren Bereich gelangt. Denn im Vergleich zu Bildern wird das Laden der Karten-Benutzeroberfläche viel schneller sein. Dies ist auch eine der Garantien für das Inkognito-Surfen.
Verzögertes Laden von Animationen
Es gibt zwei Formen der Seitenpräsentation in der App: die mit Native entwickelte Seitenpräsentation und die mit H5 entwickelte Seitenpräsentation. Wenn Native für Anfragen verwendet wird, ist es nicht erforderlich, bereits angeforderte Datenschnittstellen anzufordern. Wenn Sie H5 zum Anfordern von Daten verwenden, müssen Sie vor der Anforderung warten, bis WebView initialisiert ist (d. h. eine serielle Anforderung). Wenn Sie jedoch native Anforderungen stellen, können Sie mit der Datenanforderung beginnen, bevor WebView initialisiert wird (d. h. eine parallele Anforderung). was effektiv Zeit sparen kann.
Wie kann man also Schnittstellen über Native zwischenspeichern?
Um dies zu erreichen, können wir die SDK-Kapselung verwenden, das heißt, die ursprüngliche Datenschnittstellen-Anforderungsmethode ändern, um eine Axios-ähnliche Anforderungsmethode zu implementieren. Insbesondere sind die Schnittstellen einschließlich Post-, Get- und Request-Funktionen im SDK gekapselt. 🎜🎜🎜Wenn der Client eine Anfrage initiiert, ruft das Programm die SDK.axios-Methode auf, um die Anfrage abzufangen und zu prüfen, ob lokal ein Datencache in der App vorhanden ist Wenn nicht, fordert der Server zunächst die Datenschnittstelle an, ruft die Schnittstellendaten ab und speichert sie im App-Cache. 🎜🎜🎜🎜🎜Statisches Ressourcen-Caching🎜Schauen Sie sich zuerst das Bild an. 🎜🎜🎜🎜🎜🎜
91 Anfragen, 113 kB übertragen, 2,2 MB Ressourcen, Fertigstellung: 2,93 s, DOMContentLoaded: 177 ms. 2,2 Mio. Ressourcen, in Sekunden geöffnet. Schauen Sie sich die Spalte „Größe“ an und Sie sollten etwas verstehen. 91 requests，113 kB transferred, 2.2 MB resources,Finish: 2.93 s,DOMContentLoaded: 177 ms.2.2M的资源，达到秒开。看看Size那一列，你就应该好像领悟到什么了。
没错。HTTP缓存。 数据接口的请求一般来说较少，只有几个，而静态资源（如 JS、CSS、图片和字体等）的请求就太多了。以天猫首页为例，91 个请求中除了少数script外，其余都是静态资源请求。
那么，如何做静态缓存方案呢？这里有两种情况，一种是静态资源长期不需要修改，还有一种是静态资源修改频繁的。你可以尝试多刷新几次页面看看。
资源长期不变的话，比如 1 年都不怎么变化，我们可以使用强缓存，如 Cache-Control 来实现。具体来说可以通过设置 Cache-Control:max-age=31536000，来让浏览器在一年内直接使用本地缓存文件，而不是向服务端发出请求。
至于第二种，如果资源本身随时会发生改动的，可以通过设置 Etag 实现协商缓存。具体来说，在初次请求资源时，设置 Etag（比如使用资源的 md5 作为 Etag），并且返回 200 的状态码，之后请求时带上 If-none-match 字段，来询问服务器当前版本是否可用。如果服务端数据没有变化，会返回一个 304 的状态码给客户端，告诉客户端不需要请求数据，直接使用之前缓存的数据即可。当然，这里还涉及 WebView相关的东西，先不细讲。。。
3. 离线化处理
离线化是指线上实时变动的资源数据静态化到本地，访问时走的是本地文件的方案。
离线包就是一是离线化的一种方案，是将静态资源存储到 App 本地的方案，这里先不细讲。
但更复杂的另一种离线化方案：把页面内容静态化到本地。离线化一般适合首页或者列表页等不需要登录页面的场景，同时能够支持 SEO 功能。
那么，如何实现离线化呢？在打包构建时预渲染页面，前端请求落到 index.html 上时，已经是渲染过的内容。此时，可以通过 Webpack 的 prerender-spa-plugin 来实现预渲染，进而实现离线化。
Webpack 实现预渲染的代码示例如下：
// webpack.conf.js
var path = require('path')
var PrerenderSpaPlugin = require('prerender-spa-plugin')
module.exports = {
// ...
plugins: [
new PrerenderSpaPlugin(
// 编译后的html需要存放的路径
path.join(__dirname, '../dist'),
// 列出哪些路由需要预渲染
[ '/', '/about', '/contact' ]
)
]
}
// 面试的时候离线化能讲到这，往往就是做死现场，但风险和收益成正比，值得冒险。那就是，你有木有自己的预渲染方案。Nach dem Login kopieren
4. 并行化
如果说懒加载、缓存和离线化都是在请求本身搞事情，想尽办法减少请求或者推迟请求，那并行化则是在请求通道上优化问题，解决请求阻塞问题，进而减少首屏时间。
例如广州打疫苗排队，新闻上报道是如何如何阻塞。 那除了让群众错开打疫苗的时间，还可以增加打疫苗的医生数量。我们在处理请求阻塞时，也可以加大请求通道数量——借助于HTTP 2.0 的多路复用方案来解决。
HTTP 1.1 时代，有两个性能瓶颈点，串行的文件传输和同域名的连接数限制（6个）。到了HTTP 2.0 时代，因为提供了多路复用的功能，传输数据不再使用文本传输（文本传输必须按顺序传输，否则接收端不知道字符的顺序），而是采用二进制数据帧和流的方式进行传输。
其中，帧是数据接收的最小单位，流是连接中的一个虚拟通道，它可以承载双向信息。每个流都会有一个唯一的整数 ID 对数据顺序进行标识，这样接收端收到数据后，可以按照顺序对数据进行合并，不会出现顺序出错的情况。所以，在使用流的情况下，不论多少个资源请求，只要建立一个连接即可。
文件传输环节问题解决后，同域名连接数限制问题怎么解决呢？以 Nginx 服务器为例，原先因为每个域名有6个连接数限制，最大并发就是 100 个请求，采用 HTTP 2.0 之后，现在则可以做到 600，提升了 6倍。
你一定会问，这不是运维侧要做的事情吗，我们前端开发需要做什么？我们要改变静态文件合并（JS、CSS、图片文件）和静态资源服务器做域名散列这两种开发方式。
具体来说，使用 HTTP 2.0 多路复用之后，单个文件可以单独上线，不需要再做 JS 文件合并了。这里提一个保留问题，用过阿里系的Antd组件库吧？库每次更新都不是全部更新，可能这次只更新一个Button组件，再次只更新一个CardDas stimmt. HTTP-Cache. Im Allgemeinen gibt es weniger Anfragen für Datenschnittstellen, nur wenige, während es zu viele Anfragen für statische Ressourcen (wie JS, CSS, Bilder, Schriftarten usw.) gibt. Am Beispiel der Tmall-Homepage handelt es sich bei den restlichen 91 Anfragen bis auf einige Skripte um statische Ressourcenanfragen.
🎜Wie implementiert man also eine statische Caching-Lösung? Hier gibt es zwei Situationen: Zum einen müssen statische Ressourcen über einen längeren Zeitraum nicht geändert werden, zum anderen werden statische Ressourcen häufig geändert. Sie können versuchen, die Seite noch ein paar Mal zu aktualisieren, um sie anzuzeigen. 🎜🎜Wenn die Ressourcen über einen längeren Zeitraum unverändert bleiben, z. B. wenn sich in einem Jahr nicht viel ändert, können wir starkes Caching wie Cache-Control verwenden, um dies zu erreichen. Insbesondere können Sie Cache-Control:max-age=31536000 festlegen, um dem Browser zu ermöglichen, innerhalb eines Jahres direkt lokale Cache-Dateien zu verwenden, anstatt Anfragen an den Server zu stellen. 🎜🎜Was die zweite betrifft: Wenn sich die Ressource selbst zu irgendeinem Zeitpunkt ändert, können Sie durch Festlegen von Etag ein Aushandlungs-Caching erreichen. Insbesondere wenn Sie eine Ressource zum ersten Mal anfordern, legen Sie das Etag fest (verwenden Sie beispielsweise den MD5 der Ressource als Etag) und geben Sie den Statuscode 200 zurück. Spätere Anfragen enthalten das Feld „Wenn keine Übereinstimmung“, um nachzufragen dem Server, ob die aktuelle Version verfügbar ist. Wenn sich die Serverdaten nicht ändern, wird ein 304-Statuscode an den Client zurückgegeben, der ihm mitteilt, dass keine Datenanforderung erforderlich ist und er die zuvor zwischengespeicherten Daten direkt verwenden kann. Natürlich gibt es hier auch Dinge im Zusammenhang mit WebView, daher werde ich nicht zuerst auf Details eingehen. . . 🎜
3. Offline-Verarbeitung🎜
🎜Offline-Verarbeitung bedeutet, dass sich Ressourcendaten, die sich online in Echtzeit ändern, statisch auf die lokale Ebene übertragen und lokale Dateien verwendet werden wenn auf den Plan zugegriffen wird. 🎜🎜
Offline-Paket ist eine Offline-Lösung🎜 Es ist eine Lösung, um statische Ressourcen lokal in der App zu speichern. Ich werde hier nicht näher darauf eingehen. 🎜🎜Aber noch eine komplexere Offline-Lösung: Statisierung des Seiteninhalts lokal. 🎜Offline eignet sich im Allgemeinen für Szenarien wie Homepages oder Listenseiten, die keine Anmeldeseite erfordern, und kann auch SEO-Funktionen unterstützen. 🎜🎜Wie kann man also offline Erfolg haben? Die Seite wird während des Packens und Erstellens vorgerendert. Wenn die Front-End-Anfrage auf index.html fällt, handelt es sich bereits um den gerenderten Inhalt. Zu diesem Zeitpunkt können Sie das Prerender-Spa-Plugin von Webpack verwenden, um das Vor-Rendering zu implementieren und ein Offline-Rendering zu erreichen. 🎜🎜Webpack implementiert Pre-Rendering-Codebeispiele wie folgt: 🎜rrreee4. Parallelisierung🎜
🎜Wenn wir über Lazy Loading, Caching und offline Sie alle tun Dinge in der Anfrage selbst und versuchen mit allen Mitteln, die Anfrage zu reduzieren oder die Anfrage zu verzögern. Parallelisierung besteht darin, das Problem auf dem Anfragekanal zu optimieren, das Problem der Anfrageblockierung zu lösen und dann die erste Bildschirmzeit zu verkürzen. 🎜🎜🎜Zum Beispiel wurde in den Nachrichten berichtet, dass die Warteschlange für Impfungen in Guangzhou blockiert sei. Dies ermöglicht nicht nur eine zeitliche Staffelung der Impfzeit, sondern kann auch die Zahl der Ärzte erhöhen, die impfen können. Wenn wir uns mit der Anforderungsblockierung befassen, können wir auch die Anzahl der Anforderungskanäle erhöhen – und dieses Problem mithilfe der Multiplexing-Lösung von HTTP 2.0 lösen. 🎜🎜In der HTTP 1.1 -Ära gab es zwei Leistungsengpässe: die serielle Dateiübertragung und die Begrenzung der Anzahl der Verbindungen für denselben Domainnamen (6). Im Zeitalter von HTTP 2.0 wird die Textübertragung aufgrund der Multiplexfunktion nicht mehr zur Datenübertragung verwendet (die Textübertragung muss in der richtigen Reihenfolge übertragen werden, sonst kennt der Empfänger die Reihenfolge der Zeichen nicht). , aber Es werden binäre Datenrahmen und Streams übertragen. 🎜🎜🎜Unter diesen ist der Frame die kleinste Einheit des Datenempfangs, und der Stream ist ein virtueller Kanal in der Verbindung, der bidirektionale Informationen übertragen kann. Jeder Stream verfügt über eine eindeutige Ganzzahl-ID zur Identifizierung der Datensequenz, sodass der Empfänger die Daten nach dem Empfang der Daten der Reihe nach ohne Fehler in der Reihenfolge zusammenführen kann. Daher wird bei der Verwendung von Streams unabhängig von der Anzahl der Ressourcenanforderungen nur eine Verbindung hergestellt. 🎜🎜Wie kann das Problem der Begrenzung der Anzahl der Verbindungen mit demselben Domänennamen gelöst werden, nachdem das Dateiübertragungsproblem gelöst ist? Nehmen Sie als Beispiel den Nginx-Server. Da jeder Domänenname ursprünglich auf 6-Verbindungen beschränkt war, betrug die maximale Parallelität nach der Einführung von HTTP 2.0 kann nun <code>600 erreicht werden, was einer Steigerung um das 6-fache entspricht. 🎜🎜Sie müssen sich fragen, was die Betriebs- und Wartungsseite tun muss. Was müssen wir in der Front-End-Entwicklung tun? Wir müssen die beiden Entwicklungsmethoden der statischen Dateizusammenführung (JS, CSS, Bilddateien) und des Domänennamen-Hashings durch statische Ressourcenserver ändern. 🎜🎜Insbesondere nach der Verwendung von HTTP 2.0-Multiplexing kann eine einzelne Datei unabhängig online sein und es besteht keine Notwendigkeit, JS-Dateien zusammenzuführen. Ich möchte hier eine reservierte Frage stellen. Haben Sie jemals die 🎜Antd-Komponentenbibliothek von Alibaba verwendet? Jedes Mal, wenn die Bibliothek aktualisiert wird, werden möglicherweise nicht alle aktualisiert. Diesmal wird möglicherweise nur eine Button-Komponente aktualisiert, und nur eine Card-Komponente wird erneut aktualisiert. Wie erreicht man also separate Releases einzelner Komponenten? 🎜🎜Um die Blockierung des statischen Domänennamens zu lösen (Dies ist ein Leistungsengpass), muss der statische Domänenname in pic0-pic5 unterteilt werden, was die Fähigkeit zur Anforderungsparallelität verbessern kann.
Obwohl das Problem durch Hashing des Domänennamens der statischen Ressource gelöst wird, wird die DNS-Auflösungszeit viel länger und es sind zusätzliche Server erforderlich, um das Problem zu lösen. HTTP 2.0 Multiplexing löst dieses Problem.
Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Einführung in die Programmierung! !
Das obige ist der detaillierte Inhalt vonEinige Wissenspunkte zur Front-End-Leistungsoptimierung, die Sie kennen sollten (Teil 1). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
