OGP対応はLambda@Edgeでダイナミックレンダリングする。contentSSRをやめる。OGP対応はLambda@Edgeでダイナミックレンダリングする。update.2018.11.20求めていることSSRは極力やりたくない。SSRのメリットは初回読み込み時のブラウザレンダリング速度向上とSEO・OGP対応と言われる。レンダリング速度をシビアに要求されてない。SEOもgooglebotが対応してればいいや〜。twitter)の為だけにSSRを選ぶことになる。SPAの静的配信って大きなメリットなので、それを捨ててまでSSR...なんとかOGP対応だけしてSSRを避けられないものか。対応するページが少なければPrerender-SPA-Plugin等を使ってビルド時に全ページ出力するのが早いが、ここではCGM/UGCのようにページ数増加が激しいサイトを想定する。結論ダイナミックレンダリングする。Googleが公式に認める方法なのでクローキングに当たる心配も無さそう。Lambda)で実装する。HostingだろうとNetlifyだろうと対応可能。SPAサービスをS3に配置して静的ホスティングするこの例ではvueプロジェクトを新規作成して、S3にアップする。CloudFrontとS3をつなぐのに静的ホスティングは本来必要ないが、Lambda@Edgeの実装を簡易にするために利用する。buildAWSマネジメントコンソールで、S3の管理画面から新規バケット。パブリックアクセスを有効にする(4つのチェックを外す)。リージョンはどこでも。静的ホスティング設定で表示されるエンドポイントにアクセスする。codeが403になっているはず。Distributionボタン新規作成時の設定項目多いが、基本デフォルトのままなので、変えるところのみを記述する。クリックするとS3のバケットが表示されるが、それは使わない。S3の静的ホスティング設定で得たエンドポイントをコピペする。Nameの項目にhttpsをつけてアクセスするhttps://hogehoge.cloudfront.net/というURLになるはず。/aboutともにダイレクトアクセス出来るCloudFrontのデプロイまで多少時間かかる。ここまでが通常の静的配信セッティングとなる。serverlessを利用してLambda@Edgeを2種作成Lambda@Edgeを使って、クローラやbotによる、htmlページへのアクセスの場合にダイナミックレンダリングをする。Lambda@Edgeは、CloudFrontのDistribution単位ではなく、Behavior単位での設定になる。Behaviorは、指定されたURLパスにマッチしたときのキャッシュの振る舞い。Lambda@Edgeは次の2種作り、次のフローで処理する。同一Behaviorに設定する必要がある。(後述)ビューワーリクエストをトリガーに、ダイナミックレンダリング要否を判定する。このイベントは当てはまるBehaviorへのリクエストが発生した時まずはじめにトリガーされるダイナミックレンダリングが必要な場合は、httpヘッダx-need-dynamic-renderが"true"に設定される。request);};デプロイ実行。serverlessによりもろもろ設定した上でlambdaを追加・更新してくれる。handler....");};デプロイ実行。serverlessによりもろもろ設定した上でlambdaを追加・更新してくれる。[対象のLambda]を選択し、詳細画面へアクションからLambda@Edgeへのデプロイを選択ダイアログを下図の様に入力CloudFrontイベントがオリジンリクエストになっているが、それぞれ対象のイベント(ビューワーリクエスト、オリジンリクエスト)を設定する。deployで新しいlambdaをデプロイするたびに、このLambda@Edgeデプロイフローを実施する。agentをGooglebot等に切り替えてアクセス。responseのhtml構造が変わっている(が表示は変わらない)ことや、crawler時に追加したhtmlタグのdata属性data-le="1"が付いていることを確認できる。以外と難しくないし、シンプルな構成かつサーバレスなので運用楽そう。chromeの動作が安定するのか不明Lambdaのコールドスタートに時間がかかるので、実際使う場合はserverless-plugin-warmupとか使ってウォームアップするLambda起動の条件をもっと絞る必要があるCloudFrontのBehaviorでのみそれが出来る。patternのさらに上に*.htmlを設定してLambdaをDefault(*)同様に設定すれば対応可能か。料金Lambdaの実際の運用時コストはいまいちわからない。試算したところ、viewer-reqが100万req/日で月10ドル程、origin-reqが3万req/日で月3ドル程S3がパブリック・アクセスできる問題S3をプライベートにして、LambdaでS3のファイルを取得、headless-chromeでそれを読み込むことは出来なくは無さそうだけど、未確認S3ホスティングのエンドポイント漏洩で問題になるのってアクセス大量に来たときの料金くらい?それならS3バケットのレプリカを作ってCloudFrontですぐ切り替えられるようにしとけば、変なアクセスきたらバケット入れ替えて削除、とかで対応は出来るか。Behaviorでカスタム設定する必要があるのか。SSRの代用になるかも一般ユーザのアクセスもダイナミックレンダリングしちゃえば、後付SSRになる。SPAは通常通り静的配信できるので便利。認証部分とか検討対応が必要そうなところはありそう。対応serverlessまわり全体的に超参考にさせてもらいました。ありがとうございます。upLoginユーザーは見つかりませんでした。