バスハニャーンサービスのUXを改善する

*この記事は韓国語から翻訳したものです。不十分な部分があれば、いつでもフィードバックをいただければありがたいです！ ([オリジナル記事](https://blog.chungjungsoo.dev/dev-posts/pwa-ux-improvements/), 同じく私が作成しました。)*


[バスハニャーンサービス](https://hybus.app)の開発を総括しながらUXを改善するための様々な努力を書いてみたいと思います。

## Speed

![mobile_page_speed.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/0840cb58-4b2f-3b85-9bae-23705f2cc3fd.jpeg)


ウェブサービスでスピードは命だと思います。[Googleの研究結果](https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/)によると、モバイルウェブページの読み込み速度が増加するにつれて、ユーザーの離脱率がものすごく増加することが分かる。バスハニャーンサービスは、漢陽大学ERICAキャンパスのシャトルバスの時刻表を見ることができる簡単なウェブサービスで、ユーザーに素早く簡単に提供されなければならない。

バスハニャーンの接続速度を向上させるために、次のような最適化を行いました。

### Service Worker Caching

バスハニャーンはウェブサービスですが、アプリのメリットも活かすためにPWAのインストールをサポートします。PWAで最も核心的な部分であるService Workerの代表的な機能の一つがキャッシングです。サーバーから提供されるファイルをローカルにキャッシュしておくことで、読み込み速度を大幅に改善してくれる役割をします。 また、PWAをインストールしなければキャッシュができないわけではないので、サービスを何度も利用するユーザーの立場では、データ節約や速度向上が期待できます。

キャッシュをした場合のデメリットももちろん存在します。キャッシュされたファイルにより、サービスアップデートバージョンの配布後、ユーザーにアップデートがすぐに反映されない場合があります。このような場合は、Service Worker側でキャッシュが自動的に更新されるまで待つ必要があります。

バスハニャーンサービスは `Vite` を利用して作られています。Vite` には `vite-plugin-pwa` というプラグインがあり、Service Workerとmanifestファイルを自動で生成してくれます。

```typescript
import react from '@vitejs/plugin-react'
import { defineConfig } from 'vite'
import { VitePWA } from 'vite-plugin-pwa'

export default defineConfig({
  plugins: [
    VitePWA({
      // Service worker setting
      injectRegister: 'auto', // Service worker mode. This decides the injection method.
      registerType: 'autoUpdate', // New version update mode.
      workbox: {
        globPatterns: ['**/*.{js,css,html,ico,png,svg,woff2}'], // File regex to cache
      },
    }),
  ],
})
```

`vite.config.ts` で以下のように設定すれば完成です。Defaultとほぼ同じです。しかし、フォントファイルやアイコンリソースもキャッシュしたいので、拡張子パターンを追加しました。


![service_worker_result.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/2cc98f89-ef91-024f-6578-fbd1d5dcf5eb.png)


サービスへアクセスしてみると、Sizeタブで容量が測定されず、`(ServiceWorker)`と表示され、正常にローカルにキャッシュされてることが確認できます。また、画像の下部にある転送量を見ると、実際に転送された容量がリソースの容量に比べて圧倒的に少ないことが確認できます。

### Dynamic Subset Font

バスハニャーンサービスは[`Pretendard`](https://github.com/orioncactus/pretendard)というオープンソースライセンスのフォントを使用しています。このフォントを使う場合、ウェブ上でwoff2という圧縮されたフォント形式で提供されるのですが、そのフォント容量が2.2MBです。もちろん、インターネットが速い世の中なので2.2MBはすぐに読み込みますが、インターネットがもしかしたら遅い場合には、フォントが遅く読み込まれ、フォント適用前の文字が画面にレンダリングされた後、フォントの読み込みが終わると、フォントが変更される不思議な現象が発生することがあります。[(参考)](https://www.zachleat.com/web/mitt-romney-webfont-problem/)もちろん、Service Workerを使うのでキャッシュして次回アクセスする時は大きな問題はないが、基本的に私たちのサービスをアクセスするためのページリソース容量自体を減らしたいと思った。

Pretendard自体でDynamic subsetを提供していたので、適用は難しくなかったです。

```css
@import url("https://cdnjs.cloudflare.com/ajax/libs/pretendard/1.3.5/static/pretendard-dynamic-subset.css");
```

一般フォントの代わりにsubsetフォントを読み込めば終わりです。Dynamic Subset Fontが適用されると、ページをロードする時、次のようにフォントファイルが分割されてロードされることが確認できます。その結果、初期に読み込むフォントの容量をほぼ2MB近く減らすことができました。


![dynamic_font_subset.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/69453e42-f92e-d70a-74f6-3c93c5adff36.png)


### Partytime

バスハニャーンサービスで適用した技術の中で一番新しい技術です。このライブラリはウェブにあるサードパーティスクリプトをメインスレッドでロードさせず、Service Worker内部で実行するようにします。重いサードパーティースクリプトがある場合、メインページをローディングするスレッドから離れて別々にローディングをするため、より快適にウェブサイトをローディングすることができます。[(参考)](https://partytown.builder.io/)

代表的なサードパーティースクリプトとしてはグーグルアナリティクスとフェイスブックピクセルがあります。バスハニャーンサービスはグーグルアナリティクスを使うので、そのスクリプトをウェブページヘッダーでロードさせず、Partytimeを利用して実行することにしました。

[公式ホームページのガイドライン](https://partytown.builder.io/getting-started)を読んでみると、各フロントエンドライブラリごとにどのように適用する必要があるのかが書いてあります。バスハニャーンサービスはReactを使うので、次のように適用しました。

1.パッケージ追加
```
yarn add @builder.io/partytown
```

2.React側のメインコンポーネントにPartytownコンポーネントを追加(例)

   ```typescript
   import { Partytown } from '@builder.io/partytown/react';
   
   export function Head() {
     return (
       <>
         <Partytown debug={false} forward={['dataLayer.push']} /> // dataLayer.push -> GTAG only
       </>
     );
   }
   ```

3.スクリプトをPartytownに入れます。

   ```html
   <script src="https://www.googletagmanager.com/gtag/js?id=YOUR_GTAG_HERE" type="text/partytown"></script>
   <script type="text/partytown">
         window.dataLayer = window.dataLayer || [];
         function gtag(){dataLayer.push(arguments);}
         gtag('js', new Date());
         gtag('config', 'YOUR_GTAG_HERE');
   </script>
   ```

   Script typeが標準規格ではないので、IDEでもlintingされません。でも心配しないでください。
   
4.ビルド時に特定のディレクトリにPartytownのビルドされた成果物を移動するように設定する

   ```typescript
   import { partytownVite } from '@builder.io/partytown/utils'
   import path from 'path'
   import { defineConfig } from 'vite'
   
   export default defineConfig({
     plugins: [
       partytownVite({
         dest: path.join(__dirname, 'dist', '~partytown'),
       }),
     ],
     publicDir: './public',
   })
   ```

   ここまでやったら、適用は終わりです。


   もちろん、このライブラリのメリットはそれだけではありません。開発者ツールのネットワークタブを見ると、無数の `proxytown` リクエストが表示されます。これはPartytownとService Workerの間で通信するリクエストなので、ローカルで通信しているため、実際のパフォーマンスには影響しません。[(参考)](https://partytown.builder.io/trade-offs)

### Lazy Loading

バスハニャーンにはメインページと時刻表ページの2つのページしかありません。しかし、メインページをロードする時、全体ページも一緒にロードする必要があるのでしょうか？残念ながら、Routeの中に全体時刻表コンポーネントを入れると、メインページがロードされる時、Routeの中にある全体時刻表コンポーネントも一緒にロードされます。このように不要なコードを一度にロードすることを減らすためReact.lazyとSuspenseを使ってコードを分割することができます。

既存のコードを見てみると、次のような感じです。


```typescript
<Route path="/all" element={<FullTime />} />
```

ただRouteを使うとそのコードがあるtypescriptとそのRouteの中にあるコンポーネントも一緒に入ってロードします。


```typescript
import React, { lazy, Suspense } from 'react'
import { Route } from 'react-router-dom'

const FullTime = lazy(() => import('./app/components/FullTime'))

<Route
  path="/all"
  element={
    <Suspense fallback={<div />}>
    	<FullTime />
    </Suspense>
  }
/>
```

既存のコードを次のように変えればコード分割が完了します。全体時刻表ページを押したらtypescriptが別々にロードされることを開発者ツールのネットワークタブで確認することができます。

### 0-RTT Resumption


![tcp_with_tls.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/a668045b-784e-35f9-3687-c8ef563d9cc4.png)
「 https://blog.cloudflare.com/even-faster-connection-establishment-with-quic-0-rtt-resumption/ 」


2008年度に出た規格であるTLS 1.2では、安全な接続のためにTCPとTLSがHandshakingする過程で必要な相互間の通信回数が多かったです。しかし、2018年8月に新しく登場したTLS 1.3では、従来のTCPの代わりにQUICという新しいプロトコルを利用して、このHandshakingプロセスを大幅に削減しました。


![quic_request.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/d1193acc-8141-6bce-2ca6-719048c37ceb.png)
「 https://blog.cloudflare.com/the-road-to-quic/ 」


しかし、ここで終わりではありません。ユーザーが再接続した場合、保存したPSKをアプリケーションデータと一緒に送れば、別途の追加Handshakeが必要なく、サーバーから暗号化されたデータを再び受け取ることができます。Round trip回数がHTTPと変わらないので、これによって暗号化接続速度を向上させ、リソースの節約が可能です。


![quic_0_rtt.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/7a7f388e-e352-87f0-c0e4-5c201ab8254d.png)
「 https://blog.cloudflare.com/even-faster-connection-establishment-with-quic-0-rtt-resumption/ 」

0-RTTを使用すると、`replay attack`というネットワーク攻撃に脆弱になりますが、バスハニャーンが利用するAPIでサーバーの値を直接的に変更するAPIはなく、単に読み取るAPIだけなので、安心して0-RTTを有効にしました。


![hybus_quic.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/a12a4ff3-ee13-5b5d-df3b-1e1c501a1650.png)
「TLS 1.3を適用したバスハニャーン」


### Result

![pagespeed_result.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/6680f75f-8b54-a483-2f4a-50234b42fd75.png)
「実ユーザーのウェブページ接続経験結果統計」



[PageSpeed Insights](https://pagespeed.web.dev/)で実際のユーザーの経験を確認した結果です。コアウェブバイタル評価でかなり順守した評価を受けたことが分かります。


## SEO

![hybus_search.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/1e18b74e-8433-a667-c368-a8552fa46f27.png)


外部に公開されたサービスであるため、検索エンジンで検索した時もよく出てくるはずです。コアキーワードだけ登録して検索エンジンに露出させる[方法](https://developers.google.com/search/blog/2009/09/google-does-not-use-keywords-meta-tag)はGoogleがサポートしてないので、検索エンジンによく露出されるようにSEO最適化をしました。最適化はChrome開発者ツールに内蔵されたLighthouseを参考にしました。

### Lighthouse

Lighthouseは開発者ツールを開くとすぐに利用することができます。Lighthouseが案内する最適化の内容は次の通りです。


![seo_audits.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/5665c29a-20cd-60c9-2017-77768990ea62.png)


最初は該当しない項目がいくつかあったが、下に書く予定の項目を解決したら全部解決されました。

### Crawling

バスハニャーンサービスはシャトルバスの時刻表を表示するサービスなので、実質的にクロールできる内容があまりありません。しかし、検索エンジンにサービスで使われたアイコンや画像が画像タブに表示されるのは嫌なので、画像は収集しないようにクローラーに伝える`robots.txt`を作成しました。


```
User-agent: *
Allow: /
Disallow: /*.png$
Disallow: /*.svg$
Disallow: /*.jpg$
Disallow: /*.jpeg$
```

robots.txtは別にビルドする必要がなく、ビルドディレクトリrootに存在すればいいです。従って、ビルド結果物にこのファイルを含ませてくれます。


```typescript
import { defineConfig } from 'vite'
import { VitePWA } from 'vite-plugin-pwa'

export default defineConfig({
  plugins: [
    VitePWA({
      // Deployment
      includeAssets: [
        'favicon.svg',
        'favicon.ico',
        'robots.txt',
        'safari-pinned-tab.svg',
      ],
    }),
  ],
  publicDir: './public',
})
```

### Meta Tags / Opengraph

検索エンジンがサイトに関する情報を取得する部分がメタタグである。検索エンジンのクローラーはウェブページの `<head>` にあるメタタグを読むことでサイトをクロールする。かなり多くのメタタグがありますが、全てのメタタグを入れずに必要だと思ったタグだけ追加しました。

検索エンジン必須タグを除いて一番代表的でよく使われるタグがOpengraphタグです。Opengraphはメタタグの種類の一つであり、SNS共有、特にFacebookに最適化されているタグである。Opengraphタグに関する詳しい情報は[こちら](https://ogp.me/)で確認できる。

リニューアルされる前のバスハニャーンサービスのアナリティクスでreferral linkを分析してみた結果、SNSで共有される現象は非常に少なかった。 特に最近の大学生はFacebookをあまり使わない。

せめて広報を始めたEverytimeの流入が多いが、ここにはリンクのプレビューがない。 そのため、カカオのOpengraphの規格を一部使うことにした。


![referral_rank.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/7d37dcb1-c212-6942-664e-f8aba92ee596.png)


カカオトークのガイドラインを見ると、唯一ユニークな部分がOpengraph imageです。ここ[カカオdevtalk](https://devtalk.kakao.com/t/topic/24174)を確認してみると、Opengraphスクラップ画像の推奨サイズは800px * 800px、正方形です。この規格でOpengraph imageを入れると、カカオトークやカカオストーリーでリンクを共有した時、自動的にcropされてきれいに見えるそうです。したがって、このガイドラインに沿ってimageタグを挿入し、テストした結果、綺麗に表示されました。


![kakao_og_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/f198d7ad-8ef8-dbe9-f292-683518fcacf1.png)


適用する時、OGキャッシュを初期化しても適用されないバグがあり、大変苦労しましたが、カカオは共有されたリンクサイトのOpengraph imageタグを直接読まずにOpengraph urlタグにある値(リンク)のOpengraph imageを読み込みます。


## PWA

最後にPWAです。PWAもLighthouseで分析が可能です。PWAとは何かとPWAのサポート条件については以前の[記事](https://qiita.com/ChungJungSoo/items/ae53ec73a6f3e2b3bcc0)で説明したので、この記事では省略します。


![lighthouse_pwa.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/4730bd2c-db6e-6054-f4de-49641bc4e640.png)


ここで先ほど追加できなかったメタタグを追加します。


## Results


![lighthouse_final_result.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3896189/33134368-3ee5-a0c4-11fa-ef57859b8c4c.png)


たとえ、インターネットやパソコン環境によって点数のばらつきがあるものの、結果的にLighthouseでとても高いスコアを記録しました。

しかし、今回は開発者の立場から見たユーザーの利便性と性能だけを考慮して修正された。まだリニューアル版が配布されたばかりなので、今後、データを収集し、ユーザーの意見を取り入れてUXをさらに改善していきたいと思います。