PWAが流行らない理由はstart_url:”/”にある?「サイトをアプリ化」という固定観念



当サイト、オリジナルWordPressプラグイン「OJapp PWA Marketing」を使用しています。

各記事は専用アイコンでホーム画面に追加できます。ぜひお試しください。

PWAのManifestを見ていると、start_urlに/を指定している構成をよく見かけます。

{
  "start_url": "/",
  "display": "standalone"
}

これは仕様として間違っているわけではありません。

でも、自分はこのstart_url: "/"があまり好きではありません。

理由は単純です。

見ていたページをホーム画面に追加したのに、次にアイコンを押したらトップページが開く。

自分がユーザーとしてPWAを使ったとき、この挙動を便利だと思わなかったからです。

もちろん、サイト全体を1つのアプリとして設計して、どこから追加されてもトップから起動させたいという意図は理解できます。

ただ、「仕様として間違っていない」ことと、「そのサービスにとって本当に正しい設計なのか」は別の話です。

PWA LABでいろいろなホーム画面追加を試しているうちに、むしろこんな疑問を持つようになりました。

ユーザーが自分で選んだURLを、なぜホーム画面に追加した瞬間に崩す必要があるんだろう?

この記事では、start_url: "/"を技術的な間違いとして批判するつもりはありません。

そうではなく、「PWAとはサイトをアプリ化するもの」という前提そのものを、一度疑ってみたいと思います。

start_url:”/”にすると何が起きるのか

start_urlは、ホーム画面からPWAを起動するときの開始URLを指定するManifestの項目です。

例えば、こんなサイトがあるとします。

https://example.com/
https://example.com/news/
https://example.com/products/item-a/

ユーザーが商品Aを見つけて、「これまた見そうだな」と思い、そのページを見ている状態でホーム画面へ追加したとします。

ところがManifestがこうなっていたらどうでしょう。

{
  "start_url": "/"
}

ホーム画面のアイコンから起動するときの入口は、サイトのトップです。

ここで面白いのは、開発者とユーザーで「何を追加したのか」の認識が違う可能性があることです。

開発者側では、「example.comというサイトのPWAをインストールした」と考えている。

でもユーザー側では、「いま見ている商品Aをホーム画面に置いた」と感じているかもしれない。

そして次にアイコンを押す。

商品Aではなくトップページが開く。

ここに、開発者が定義したAppと、ユーザーが選んだ入口のズレがあります。

アッピン
このページから追加したのに、なんでトップに戻るん?って話だね👻

PWAには「どこから追加したか」という文脈がある

ここはネイティブアプリとの大きな違いだと思っています。

ネイティブアプリなら、App StoreやGoogle Playでそのアプリを探してインストールします。

その時点では「この商品ページからインストールした」「このプロフィールを見ながらインストールした」というURLの文脈は基本的にありません。

だからアプリを起動して、サービス側が決めたホームやフィードが表示されるのは自然です。

でもPWAは違います。

多くの場合、ユーザーはすでにWebサイトを見ています。

しかも、ただサイトにいるだけではありません。

ある特定のURLを開いている状態で、「ホーム画面に追加」という操作をしています。

記事を読んでいたのかもしれない。

商品を見ていたのかもしれない。

好きな人のプロフィールを見ていたのかもしれない。

便利なWebツールを使っていたのかもしれない。

つまりPWAには、追加された瞬間からすでに「ユーザーがどのURLを選んでいたか」という文脈があります。

start_url: "/"を指定するということは、その文脈よりも「このサイトは1つのアプリだから、ここから起動してほしい」という開発者側の設計を優先することでもあります。

それが必要なサービスはあるでしょう。

でも、本当にすべてのPWAでそれをする必要があるのでしょうか。

ネイティブアプリと同じなら、PWAを使う理由は何だろう

ここで、SNSのようなサービスを例に考えてみます。

例えば、ネイティブアプリをインストールしてアイコンを押すと、おすすめフィードやホームが開く。

これは普通です。

アプリそのものをインストールしたのだから、サービス側が用意した入口から始まることに違和感はありません。

では、同じサービスのPWAを考えてみます。

好きなアカウントを見ている。

そのページからホーム画面へ追加する。

でもアイコンを押すと、ネイティブアプリと同じようにサービスのトップが開く。

もちろん、それでもPWAとして成立します。

ただ、自分ならこう思います。

それならネイティブアプリでよくない?

PWAがネイティブアプリと同じ入口、同じような使い方を目指すだけなら、すでにネイティブアプリがあるサービスではPWAを選ぶ理由が弱くなります。

では逆に、PWAだけ違うことができたらどうでしょう。

好きなアカウントを見ている。

そこからホーム画面へ追加する。

そのアカウントを入口としてホーム画面に置ける。

次から、その人を起点にサービスを開ける。

これならネイティブアプリとは違う使い方になります。

もちろん、「前回見ていたアカウントを毎回開くべき」という話ではありません。

普通にサービスを起動したならトップでいい。

重要なのは、ユーザー自身がそのページを見ながら「ここをホーム画面に追加する」という操作をした場合まで、その入口をトップへ置き換える必要があるのかということです。

「サイトをアプリ化する」が固定観念になっていないか

PWAは長い間、「Webサイトをアプリのようにする技術」と説明されてきました。

そう考えると、サイト全体を1つのアプリとして扱い、トップページを起動地点にするのは自然です。

でも、それを突き詰めてネイティブアプリと同じ体験を再現しようとすると、別の疑問が出てきます。

ネイティブアプリを再現するだけなら、PWAである必要はどこにあるのか。

Webには、ネイティブアプリとは違う強みがあります。

URLです。

記事にもURLがある。

商品にもURLがある。

プロフィールにもURLがある。

ツールにもURLがある。

場合によってはqueryやfragmentを使って、設定された状態やページ内の位置までURLとして表現できます。

それなのにPWA化した瞬間、すべての入口をサイトトップへ集約してしまう。

それはある意味、Webが最初から持っている「入口を細かく選べる」という強みを、自分から捨ててネイティブアプリへ寄せているとも考えられます。

以前の記事でも、PWAにはサイト全体を1つのAppとして扱う1S1Aと、ページ単位で扱う1P1Aという2つの設計が考えられると整理しました。

start_url:”/”が間違いなのではなく、本当に必要なのかを考えたい

ここまで書くと、かなりstart_url: "/"を嫌っているように見えると思います。

実際、自分はあまり好きではありません。

でも、技術的に間違っていると言いたいわけではありません。

例えば、サイト全体を1つのサービスとして使わせたい場合。

管理画面やWebメールのように、どこから追加されても決まった入口から始めること自体に意味がある場合。

そういうサービスなら、/を起動地点として選ぶ意図は理解できます。

ただし、そこで「だから/が正しい」とまでは言いたくありません。

仕様として有効であることと、そのユーザー体験にとって正しいことは同じではないからです。

/を選ぶなら、ユーザーが追加したURLを捨ててでもトップへ戻す理由があるのか。

逆に、そのページ自体に価値があるなら、ユーザーが選んだ入口を残した方が便利ではないのか。

start_urlは、そんな天秤にかけて決めるものだと思っています。

ユーザーが選んだURLを、そのまま入口として尊重する

PWA LABでは、この部分を実際に試してきました。

そこで重要になったのが、現在のページを基準に起動するstart_url: "."です。

詳しい挙動は、start_url:”.”が最強説|PWAで“入れたページに戻る”を成立させる考え方でもまとめています。

考え方はかなり単純です。

ユーザーがそのページを見ている。

そのページでホーム画面に追加する。

だったら、次にそのアイコンを押したときも、そのページを入口にする。

ユーザーが選んだURLを、ホーム画面でもそのまま入口として尊重する。

自分には、この方がWebらしく感じました。

そこから1P1Aが生まれた

この考え方から、OJappで検証している1P1A(One Page. One App.)という設計思想につながりました。

1P1Aは「/は間違いだから全部.にしよう」という話ではありません。

サイト全体を1つのAppとして考える1S1A(One Site. One App.)もあります。

ディレクトリや機能群を1つの単位として扱う1G1A(One Group. One App.)という考え方もできます。

そのうえで1P1Aは、「ページそのものを1つのAppの単位として考えてみよう」という設計です。

商品ページなら、その商品を開くアイコン。

プロフィールなら、その人を開くアイコン。

タイマーなら、そのタイマーを開くアイコン。

記事なら、その記事へ戻ってくるアイコン。

新しい入口を無理に作っているというより、Web上ですでにユーザーが選んでいたURLを、ホーム画面でも活かしているという方が近いと思っています。

PWAが流行らない理由はstart_url:”/”なのか

もちろん、「PWAが広く使われない原因はstart_url: "/"だ」と証明できるわけではありません。

OSやブラウザの仕様差、インストール導線、ユーザー認知など、PWAが普及するかどうかにはいろいろな要因があります。

でも、自分は一人のユーザーとしてこう感じました。

追加したページではなくトップページが開くPWAを、便利だとは思わなかった。

そして、ネイティブアプリと同じようにサービスのトップを開くだけなら、「それならネイティブアプリでいい」とも感じます。

だからこそ、PWAはもっとWeb側の強みを使ってもいいんじゃないかと思っています。

WebにはURLがあります。

そしてPWAには、ユーザーがそのURLを見ている状態からホーム画面へ追加できるという特徴があります。

以前、PWAをユーザー側から考えると、ホーム画面に追加する理由そのものを設計する必要があるという話を書きました。

start_urlも、その体験を決めるかなり重要な一行だと思っています。

ユーザーがホーム画面に追加したのは、本当に「サイト」なのか。

それとも、いま見ている「ページ」なのか。

「サイトをアプリ化する」だけがPWAではない。

ネイティブアプリを再現することから少し離れて、Webがもともと持っているURLという強みをホーム画面まで持っていく。

そう考えると、PWAにはまだかなり違う使い方が残っているんじゃないかと思っています。

GoogleでOJapp Tipsを優先する情報源に追加

今後、Google検索でOJapp Tipsの記事を見つけやすくできます。


OJapp FREE · 1P1A

Turn Any Web Page into a Home Screen App

Skip complex PWA setup. Add one line of code and turn your
web page into an installable home screen app.


OJapp FREE - One Page. One App.


OJapp FREE · 1P1A

Webページをホーム画面アプリに

複雑なPWA設定やmanifest.jsonの作成は不要。
1行のコードを追加するだけで、Webページをホーム画面へ追加できるアプリに変えられます。


OJapp FREEでWebページをホーム画面アプリに

最新情報をチェックしよう!
    OJapp Tips  -  PWA・ホーム画面追加の実機検証ブログ

    OJapp Tips  -  PWA・ホーム画面追加の実機検証ブログ

    OJapp Tipsは、 公式ドキュメントをなぞるだけでは分かりにくい挙動を、実際にiPhone・Android・PCで検証しながら記録しています。

    特に、manifest.json、Service Worker、Web App Manifest、WebClip、アイコンキャッシュ、ホーム画面追加の挙動など、 Webサイトを「アプリのような入口」として使うためのノウハウを中心に扱っています。

    OJapp Tipsの記事は、PWA LABでの実機検証や、OJapp・Petal・OJ-Passなど自作ツールの開発で詰まったことを元にしています。 きれいな理論だけではなく、「実際にはここでハマる」という現場寄りの知識を残すための場所です。