H5 ページを数秒で開く最適化と実践に重点を置く

この記事では、H5 に関する関連知識をお届けします。主に、H5 ページを数秒で開くための最適化と実践について説明します。一緒に見てみましょう。皆さんのお役に立てれば幸いです。

背景

3月に主要なオンラインH5プロジェクトの即時開封率管理を実施し、H5ページの最適化を通じて1.5秒の開封率を向上させる方法を段階的に紹介していきます。

なぜ最適化する必要があるのでしょうか?

• ユーザーの観点から見ると、最適化によりページの読み込みが速くなり、ユーザー操作により迅速に応答し、より良いユーザー エクスペリエンスを提供できます。ユーザー エクスペリエンスを向上させ、ユーザー チャーン レートを減らすことは非常に重要です。その中でも、Global Web Performance Matters for ecommerce レポートでは、最適化の重要性についても具体的に説明しています。
• 企業の観点から見ると、最適化によりページ リクエストの数が減ったり、リクエストが占有する帯域幅が削減されたりするため、リソース コストが大幅に節約され、最終的には収益変換が増加します。

最適化目標

上の図からわかるように、一部のドメイン名は 90% 未満である可能性があり、最も高いドメイン名でも 90% 未満である可能性があります。 96% には達しておらず、設定された目標である 98% とはまだ一定のギャップがあります。

H5 パフォーマンス分析

分析ツール

• Lighthouse
• Chrome DevTools
• gtmertrix オンライン ビジュアル分析ツール

Webview による H5 の読み込み

通常、次の段階に分かれています。

1. Webview の初期化。
2. 新しいページに到着し、ネットワークに接続し、サーバーから html、css、js をダウンロードすると、ページには白い画面が表示されました。
3. ページの基本フレームが表示され、js がページ データを要求し、ページが読み込み状態になります。
4. 必要なデータが表示され、ページ全体のレンダリングが完了し、ユーザーが操作できるようになります。 H5 の起動プロセスをグラフィックで視覚的に確認します。

これらのプロセスの時間をいかに短縮するかが、H5 のパフォーマンスを最適化する鍵となります。次に、各段階における最適化の注意点を詳しく見ていきましょう。

最適化計画

次の側面から開始します:

• 読み込み戦略の最適化
• スケルトン画面の追加
• リソース要求の最適化(静的リソース、画像と WebP、画像の遅延読み込み、コンポーネントのオンデマンド読み込み)
• パッケージ化リソースの最適化
• CDN とキャッシュ

次のステップそれらを 1 つずつ分析することです

読み込み戦略の最適化

最初に画像を見てください:

developers.google.com/web/fundame… )これから この図でわかることは、次の 4 つの点に大まかに要約できます:

• デフォルトの状況: HTML 解析、次に JS の読み込み、この時点で HTML 解析は中断されます。次に JS が実行され、最後に JS の実行が完了して HTML 解析が再開されます。
• defer case: HTML と JS は連携しており、JS は最後に実行されます (js スクリプトはすべての要素がロードされた後に実行され、js スクリプトで宣言された順序で実行されますが、そうではありません)すべての dom ドキュメントが解析されるまで実行されます)。
• 非同期の場合: HTML と JS は連携しており、HTML が解析される前に JS の実行が完了する場合があります (特定の条件が満たされている限り、宣言した順序に関係なく、JS スクリプトは順不同で実行されます)。 js スクリプトがロードされ、すぐに実行されます)。
• モジュールの場合: 遅延の場合と似ていますが、抽出プロセス中に複数の JS ファイルがロードされる点が異なります (es6 のモジュールのインポートおよびエクスポート構文を受け入れるために acript タグの type="module" 属性を宣言し、ロードします)また、複数の JS ファイルをロードできる点を除いて、defer に似ています)。

プロジェクトの実践例:

##プリロード

プリフェッチとプリロード

preload は、ブラウザのメインのレンダリング メカニズムが開始される前に、ページ ライフ サイクルの早い段階で指定したリソースを確実にロードする新しい Web 標準です。

具体的な使用法は次のとおりです:

    <scirpt></scirpt>
    
    <scirpt></scirpt>复制代码

注: プリロードはタイトルの横に配置され、最も早く介入できるようになります。

prefetch 是提示浏览器，用户在下次导航时可能会使用的资源（HTML，JS，CSS或者图片等），因此浏览器为了提升性能可以提前加载、缓存资源。prefetch 的加载优先级相对较低，浏览器在空闲的时候才会在后台加载。用法与 preload 类似，将 rel 的值替换成 prefetch 即可。

preload 是告诉浏览器页面必定需要的资源，浏览器一定会加载这些资源，而 prefetch 是告诉浏览器页面可能需要的资源，浏览器不一定会加载这些资源。所以建议：对于当前页面很有必要的资源使用 preload，对于可能在将来的页面中使用的资源使用 prefetch。

注意：用 preload 和 prefetch 情况下，如果资源不能被缓存，那么都有可能浪费一部分带宽，请慎用。非首页的资源建议不用 preload，prefetch 作为加载下一屏数据来用。

dns-prefetch 和 preconnect

dns-prefetch

DNS 请求需要的带宽非常小，但延迟较高，这点特别是在手机网络上比较明显。预读取 DNS 能让延迟明显减少一些（尤其是移动网络下）。为了帮助浏览器对某些域名进行预解析，你可以在页面的html标签中添加 dns-prefetch 告诉浏览器对指定域名预解析。

dns-prefetch 是一项使浏览器主动去执行域名解析的功能。dns-prefetch 应该尽量的放在网页的前面，推荐放在后面。具体使用方法如下：

<link>复制代码

洗车项目中有体现：

注意：dns-prefetch需慎用，推荐首屏加载资源添加DNS Prefetch

preconnect

和 DNS prefetch 类似，preconnect 不仅会解析 DNS，还会建立 TCP 握手连接和 TLS 协议（如果是https的话）。用法如下：

preconnect 允许浏览器在 HTTP 请求实际发送到服务器之前建立早期连接。可以预先启动 DNS 查找、TCP 握手和 TLS 协商等连接，从而消除这些连接的往返延迟并为用户节省时间。

<link>复制代码

骨架屏

从图上可以看出有白屏情况，FCP 时间超过了 1秒多，解决下来就用了骨架屏来解决白屏情况 并提升 FCP。

骨架屏就是在页面资源尚未加载完成以及渲染尚未完成时，需要先给用户的展示页面大致结构。直到资源加载完成以及渲染完成后，使用渲染的页面。骨架屏处理方案也很多，常用方案有以下几种：

• 首屏：可以在index.html模版中手写骨架屏相关代码。
• 其他页面：可以利用UI提供SVG图
• 作为SPA中路由切换的loading：需自己编写骨架屏，推荐两个成熟方便定制的svg组件去定制骨架屏-   react-content-loader和vue-content-loader。
• 骨架图渲染前不要出现任何网络请求，在此之前 HTML 内容不要超过 4KB。

我这里采用了固定的骨架屏SVG打包自动注入到模板方式。并产出了基于vite 的自动化注入骨架屏和无阻塞缓存资源文件@auto/vite-plugin-cdn私有插件。

举个?：

リソース リクエストの最適化

画像圧縮と webp

画像は、Web サイトのパフォーマンスの最適化で重点を置く必要がある方向です。なぜそんなことを言うのですか？画像を見てみましょう: 通常、UI で提供されるカット画像は非圧縮画像であるため、開発プロセス中に再度圧縮する必要があります。圧縮されたイメージが依然として 500 KB を超える場合は、イメージを複数の部分に分割することを検討してください。 現在、多くの画像圧縮方法が市場に出回っていますが、便利なツール (docsmall) をおすすめします。あらゆる種類の画像を一括圧縮できます。

#WebP の利点は、より優れた画像データ圧縮アルゴリズムを備えていることです。これにより、肉眼で画質の違いが認識されない場合、画像サイズが小さくなるという利点が得られます。可逆圧縮モードと非可逆圧縮モードの両方、アルファ透明度およびアニメーション機能があり、JPEG と PNG への変換効果は非常に優れており、安定していて均一です。画像リソースは内部的に提供され、フロントエンド アクセラレーション サービスまたは フロントエンド静的リソース サービスにアップロードできます。内部リソース ライブラリは自動的に WebP 形式を生成し、format= を追加できます。プロジェクトをパッケージ化するときに画像を処理する場合。webp で十分です。インターフェイスの動的画像は、@auto/img-crop プライベート パッケージを使用して切り取ることができます。Webp も動的にサポートでき、キャッシュ時間は次のように設定できます。パラメーター。

webp 前後の比較: 比較結果から、webp を使用すると同じ画像のサイズが少なくとも 50% 削減され、画像が大きくなるほど最適化率が高くなります。 。ファイル サイズが大幅に縮小され、読み込み時間が短縮され、大きなページ画像や多数の画像が含まれるシナリオでは、ページのレンダリング速度が大幅に向上します。

CDN とキャッシュ

前述のように、フロントエンド アクセラレーション サービスまたは フロントエンド静的リソース サービスの内部サービスはすべて CDN 機能を統合します。特定の状況については、使用上のドキュメントを参照してください。

上記の 2 つのサービスを組み合わせたアプリケーションは、リソースの問題をうまく処理できます。現在、新しい SPA プロジェクトはすべてフロントエンド アクセラレーション サービスにリリースされています。図に示すように: リソース ファイルは自動的にキャッシュされます

Uncovered CDN

図から、左側の図はキャッシュにヒットしませんが、右側の図はキャッシュにヒットしません。画像がキャッシュにヒットします。多くのプロジェクトでは、ドメイン名インターフェイスが Web インターフェイスと同じであるため、CDN はキャッシュを有効にしません。ドメイン名のパスを使用して CDN キャッシュを有効にします。

パッケージ化リソースの最適化

サードパーティ ライブラリの抽出

通常、ほとんどのサードパーティ ライブラリのコードは、バージョンをアップグレードしない限り変更されません。 DllPlugin: 再利用性の高いサードパーティ ライブラリをまとめてパッケージ化するため、アップグレードしない場合に再パッケージ化する必要がありません。

これを行う利点:

• 提取的第三方库生成的资源版本号（资源的访问连接）不会变，提高了缓存的利用；
• 避免打包出单个文件的大小太大，不利于加载；
• 每次构建只重新打包业务代码，提高打包效率。

为了让前端页面性能更优， App WebView 中针对 React、Vue、Zepto 三大常用框架相关资源及 Polyfill 进行了预加载处理，所以我们把这些固定的资源调整为无阻塞的预加载地址。具体如何使用 App H5提供了 webpack的相关配置说明。

这里针对 vite 的配置做些说明：

import { defineConfig, loadEnv } from 'vite';
import react from '@vitejs/plugin-react';
import legacy from '@vitejs/plugin-legacy';
import createExternal from 'rollup-plugin-external-globals';
import cdn from '@auto/vite-plugin-cdn'; 
export default ({ mode }) => {
  process.env = { ...process.env, ...loadEnv(mode, process.cwd()) };
  const { VITE_USER_NODE_ENV = 'mock' } = process.env;
  const plugins: Array<any> = [];
  const isProduction = process.env.NODE_ENV === &#39;production&#39;;
  if (isProduction) {
    // 设置预加载的 react 等包为 external
    plugins.push(
      createExternal({
        react: &#39;React&#39;,
        &#39;react-dom&#39;: &#39;ReactDOM&#39;,
        history: &#39;HistoryLibrary&#39;,
        &#39;react-router&#39;: &#39;ReactRouter&#39;,
        &#39;react-router-dom&#39;: &#39;ReactRouterDOM&#39;,
        immer: &#39;immer&#39;,
        axios: &#39;axios&#39;,
        &#39;js-cookie&#39;: &#39;Cookies&#39;,
      }),
    );
    plugins.push(
      cdn({
        enableModule: true,
      }),
    );
  }
  // https://vitejs.dev/config/
  return defineConfig({
      legacy({
        targets: [&#39;> 0.05%&#39;, &#39;not dead&#39;, &#39;not op_mini all&#39;],
      }),
      ...plugins,
    ],

    build: {
      rollupOptions: {
        external: [
          &#39;react&#39;,
          &#39;react-dom&#39;,
          &#39;history&#39;,
          &#39;react-router&#39;,
          &#39;react-router-dom&#39;,
          &#39;axios&#39;,
          &#39;js-cookie&#39;,
        ],
       
      },
    },
  });
};

这里@auto/vite-plugin-cdn私有插件中提供正常骨架屏、预加载资源、处理资源加载顺序

示例：

优化打包资源

我们来看一组图：

从图上看优化前后，文件数从295 个减少到 214 个， 大小从 1.63MB 减少到439.88KB，大小降了73.6460%

webpack 和 vite 配置

设置预警来检验打包文件

资源(asset)是从 webpack 生成的任何文件。此选项根据单个资源体积(单位: bytes)，控制 webpack 何时生成 性能提示。 用法：

//  webpack 设置单个静态资源文件的大小最大超过300KB则会给出警告
module.exports = {
  //...
  performance: {
    maxAssetSize: 1024 * 300 
  }
};

// vite 设置
build: {
      chunkSizeWarningLimit: 300 // 块大小警告的限制（以 kbs 为单位）默认 500
    }

将打包后的静态资源控制在 300KB 以内，最终通过 Gzip 压缩后，基本都在 100KB 以内。其他的优化包括提取第三方库、移除调试和无用代码、Tree Shaking 等。

总结

经过以上的一系列的优化实施，我们来看一下优化前后数据的对比：从2月底开始实施优化，上图可以很明显看出数据的变化，秒开率虽然已经做到了95%以上，达到 98%的只有个别项目，还需要在迭代过程中关注性能以及持续的优化，这里也感谢为H5页面秒开做出贡献的同学。如有什么问题和想法欢迎留言区评论交流。

如果你读完了也不妨点个赞哟，万分感谢!

以上がH5 ページを数秒で開く最適化と実践に重点を置くの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。