5/21（月）のWe Are JavaScripters!でWordPressのフロントエンドにGatsbyを採用した話をしてきました。 前回のRoppongi.js#2でGatsby + Netlifyの爆速開発をLTしてきたのですが、その続編の話になります。 スライド https://speakerdeck.com/mottox2/wordpress-gatsby モチベーション 内製出来る体制がありフロントエンドエンジニアがWordPressを担当していると前提の元でのお話です。 エンジニアの工数が割けない状態であればWordPress単体で使い続けるのがいいと思います。 簡単に言うとWordPressはCMSとして想定された使い方以外をされると非常にしんどい と思っています。 単純なブログならWordPressは非常にマッチしていると思うのですが、サービスのランディングページやコーポレートサイトなど、更新系のページ（ニュースやブログ）だけでは収まりません。おそらくトップページやサービスの価格ページ、経営者の声やアクセスページなども存在すると思います。 WordPressには「固定ページ」という機能もあり、そういったページを管理出来るのですが、WordPress上で編集する必要があるためちゃんとやろうとするとしんどさが残ります。また、昨今の雰囲気であればGitなどのバージョン管理システム上で管理したいでしょう。npmのライブラリを使えたら便利です。 そういったしんどさから抜け出すために、WordPressは記事編集とAPIによる記事の出力に特化してもらうと話が楽になっていきます。 JSフレームワーク上で開発する WordPressにはREST APIが用意されているため、APIを叩けば記事は取得出来ます。そうなるとViewをどういった方法で開発していくかを考えることになります。 サービス開発でも使われるReact, Vueのスタックに合わせていくのがよいでしょう。 しかし、ログインを伴わないWebサイトはSEOの都合を考える必要があります。つまりSSR（サーバーサイドレンダリング）が要件に入ってくるでしょう。 SSRを実装することはそんな大変ではありませんが、サービスLPやコーポレートサイトのようなサイトのために独自設計するのはコスパが悪いし、引き継ぐ時も大変になってきます。なので、SSRに対応したフレームワークを利用するのが現実的な選択になっていきます。 ここで出てくる選択肢というのは、ほぼ2択だと思っていてReactベースで実装されている静的サイトジェネレーターのGatsbyか、VueベースのフルスタックWebフレームワークのNuxt.jsです。 ※ 最近、WebフロントエンドエンジニアでjQueryを使ったことがない方に合ったことがあるので、jQueryの経験がないWebフロントエンドエンジニアは増えていくと思われます。 なぜGatsbyを選択したのか 単純に会社でRailsのWebpackerでReactが動いていたという点が大きいのですが、Nuxtより書き方が揺れないという点を評価しています。 Nuxt.jsは非常に便利で、今自分が新規事業をやるとしたら十分選択肢に入ってくるものだと思います。 自分がサーバーサイドを書くときはRuby on Railsを好む理由である、実装する時に書き方を迷わないのが大きな利点だと感じています。フロントエンドにレールを敷いてくれそうなフレームワークだとは思っています。 ただ、今回のスコープである、サービスのLP、コーポレートサイトに関しては少しスコープが広すぎると感じました。 一方Gatsbyは静的サイトに特化していることもあり機能と拡張性は劣ってい ます。 以下のスクショはGatsbyの公式サイトで紹介されている図なのですが、Data SourceはGraphQLを使ってViewに取得するという設計になっています。 何が嬉しいかというと、データの取得ロジックとViewが明確に分けられる点です。 明確に分けられるので、データの取得ロジックは基本的にPlugin経由で取得するのが主流になっており、取得したデータを使ってViewを開発することだけ気にすればサイトが出来上がる、というフレームワークになっています。 Viewを開発するだけでいいので、基本的に書き方が統一されます。Reactを使った人なら苦もなく読めます。 そういった判断から、WordPressのフロントエンドにGatsbyを選択しました。 ただ、記事数が多い・更新頻度が多いという状況だと毎回のビルドがネックになりNuxt（というか動的サイト）の優位性が勝つことになると思います。 次にGatsby化を予定しているサイトは900記事弱・更新頻度は2日に1記事程度ですが、ビルドは3分弱なのでGatsbyを使える判断をしています。 「10000記事のサイトでビルドが長すぎる」みたいなIssueをGatsbyのリポジトリで見かけましたが、そういったサイトであれば動的サイトにした方がいいでしょうｗ 導入のメリット ざっくりまとめると以下のようなメリットがありました。 単純に開発が楽 今まではdocker-composeで頑張ってた もう yarn dev でOK。 高速化が楽 Gatsbyがblazing-fastなので早い。 移行の際にいらないコードを消せた。jQueryも消し去ることが出来ました。 デプロイ方法に悩まなくなった 静的サイトなので簡単デプロイ WordPressのセキュリティに対する不安も弱くなった 静的サイトだからWordPressが外に露出させる必要がない 移行してみて 開発環境、高速化、デプロイ方法、セキュリティなど今まで考えなければいけなかったポイントが減って非常に楽です。 開発環境もいい感じにリロードしてくれたり、eslint, prettierが動いてくれるので雑に書いても整形してくれるあたりは普段のサービス開発に追いついた気がします。 これでページの修正や追加があっても、重い気分になることなくマークアップに集中出来ます！ またGatsbyをやっていると、フレームワークはどのように高速化をしているのかについても知ることができ、他のサービスにも活かせる知識になります。早速別の会社で触っているRailsアプリケーションを高速化していきたいと思います。 ここまでいいことしか言っていませんが、もちろん懸念点もあって、静的サイトの生成速度は記事数が増えるにつれて当然遅くなっていきます。 デプロイ速度と読み込み速度のトレードオフの問題が生まれてきます。手元で計測したところ1000記事程度でBuildが2分半ちょっと、DeployがNetlify環境で約10分に達します。 許容出来なくなったタイミングで静的サイトから動的サイトへの変更を考えねばならないので、もしそうなった場合の検討も必要だと感じています。 ただ、記事数が少ないうちはほぼ何も考えずに導入できるのはGatsbyのいいところなので、Gatsbyが使われるべきサイトにはしっかり導入して、そうでない場合はその状況にあったものをしっかり提案出来るようにしていきたいところです。（コーポレートサイト・サービスサイトであればGatsbyで良さそうという見解です） また、分離が進むとWordPressの必要性が薄くなっていきます。新規のサイトであれば別のCMSを提案したいので、このあたりのツールも探っていきたいところです。 個人的には、esa.ioやkibe.la、Qiita:Teamなど普段使っているツールから更新出来るのがいいかと思っています。 何度もしつこいですが、このサイトはesa.ioの投稿をそのままブログ記事として扱っています。本当に便利です。 WeJSの運営の皆様、LTの機会を頂きありがとうございました！ 他の方のLTも楽しく聞かせていただきました。 実際にGatsbyを試してみたいという方は公式サイトを見て、Gatsby.js Tutorial | GatsbyJSを行いましょう。 また、WordPressをGatsbyで使いたい場合は gatsby new project_name https://github.com/ericwindmill/gatsby-starter-wordpress を実行して、gatsby-config.jsの設定を書き換えることで始めることが出来ます。

Googleが公開しているProgressive Web App Checklistをサラッと読んでまとめてみました。 思ったより普通で、Webでいい体験を提供しましょうというニュアンスが強めだった。 Baseline Lighthouseで計測可能。基本的なチェックリスト。 Site is served over HTTP Pages are responsive on tablets & mobile devices レスポンシブ対応をすること All app URLs load while offline オフラインでも読み込みが出来ること ServiceWokerによってオフライン対応が可能 Metadata provided for Add to Home screen HomeScreenに追加する時のmeta情報を提供すること manifest.jsonに記述するやつ First load fast even on 3G 3Gとかでも早く表示すること 日本にいると気にする機会が少ないかも PageSspeed Insightで85点以上を目指しましょうとのこと Site works cross-browser クロスブラウザで動作すること Page transitions don’t feel like they block on the network ページ遷移がネットワーク状況によってブロックされていないように見えること SPA実装するなり、スケルトンスクリーンを実装するなりして対応してくれよのこと Each page has a URL ページは固有のURLを持つこと SPAとかでURLが迷子になってしまったりするけど、そういうのはなし 模範的なPWA Lighthouseで未実装。自分で実行する必要があるもの。 Indexability & social Site’s content is indexed by Google サイトがGoogleにインデックスされるようにすること 基本的にJavaScriptを実行して検索エンジンにIndexしているが、FetchAPIのような新しいブラウザAPIはPolyfillを使うこと Schema.org metadata is provided where appropriate いわゆる構造化データの実装をすること パンくずとか、Article、Recipeなど Social metadata is provided where appropriate TwitterやFacebookでシェアされる時のmetaデータを入れること Canonical URLs are provided when necessary meta=canonicalが必要な場合は入れること URLの正規化の話 Pages use the History API HistoryAPIを使ってURLを操作すること mottox2.com/#posts/123 のようなIDを使ったルーティングをしてはいけない（昔vue cliで作ったアプリケーションがこの形だった気がする） User Experience Content doesn’t jump as the page loads ページを読み込む時に、要素がカクつくのを防ぐこと width, heightのない要素やiframe, 広告埋め込みとかで発生しやすい 画像の読み込み中はplaceholderを入れるなどの対応 Pressing back from a detail page retains scroll position on the previous list page 戻るボタンを押した時に、遷移前のスクロール位置に復帰すること 体感としてInfinite Loadingを実装したサイトとかでスクロール位置を保持していない場合が多い When tapped, inputs aren’t obscured by the on screen keyboard フォーカスがあたっている要素が画面上にあらわれている状態にすること（キーボードの下に要素を隠れないようにする） Content is easily shareable from standalone or full screen mode Add to HomeScreenの”standalone”モードではブラウザのUIが隠れるので、簡単にシェアを出来るようにしておくこと Site is responsive across phone, tablet and desktop screen sizes スマホでもタブレットでもPCでも適切なレスポンシブUIを実装すること Any app install prompts are not used excessively アプリインストールのバナーは適切に表示すること The Add to Home Screen prompt is intercepted Add to Home Screeenのプロンプト（「ホーム画面に追加」ボタン）の処理を割り込ませないこと 独自バナーを出してキャンセルをなかったことにする手法をやらないでって解釈（Web Pushでよく使われているevilな手法） Performance First load very fast even on 3G PageSpeed Insightで85点以上を目指しましょうとのこと 遅延ロード出来るscriptにはasync属性をつける、クリティカルレンダリングパスに対する理解を深めるなど Caching Site uses cache-first networking Cacheが利用できる場合にはNetworkより優先すること。ServiceWorker絡み Site appropriately informs the user when they’re offline Cache Firstでページを読み込みして、Offline状態である時はOfflineであることを適切に通知すること Push notifications Provide context to the user about how notifications will be used Push通知がどういう時に行われるか伝えること Best Practices for Push Notifications Permissions UX - Google ドキュメント UI encouraging users to turn on Push Notifications must not be overly aggressive. プッシュ通知を有効化を過度に促さないこと Site dims the screen when permission request is showing Permissionの要求の時は画面を暗くすること（モーダルの出し方のことだと思われる） Push notifications must be timely, precise and relevant プッシュ通知は、タイムリーで正確、関連性のあるものにすること セグメントを切らない通知は辞めろってこと Provides controls to enable and disable notifications 通知のON/OFFの切り替えを出来るようにすること Additional features User is logged in across devices via Credential Management API Credential Management APIを通してログインできるようにすること User can pay easily via native UI from Payment Request API. Payment Request APIを使って簡単に決済を行えるようにすること

Gatsbyを始めた時に「速いサイトはよい」というシンプルな気持ちになったので、どんなサイトでも高速化したい気持ちで「超速! Webページ速度改善ガイド」を購入しました。 本の内容と学び この本の中では「ネットワーク処理、レンダリング周り、スクリプト周りの高速化」の3つのポイントによる高速化の知識と方法が紹介されています。 ネットワーク処理は今までも、リクエスト数の削減や、リソースのサイズ削減などには取り組んでいました。 それでも、HTTP2になって並列リクエストが可能になってCSSスプライトはdeprecatedな感じになっていたり、クリティカルレンダリングパスの改善手法（ページの描写を妨げる要素を解決していく）など意外と知らないことや感覚に頼って曖昧な箇所がありました。 また、ChromeのDeveloperToolsも詳しく解説されており、感覚だけで弄っていたものが「ああ、なるほど」と腑に落ちる気持ちになりました。日本語でここまで丁寧に解説されているのを始めて見た気がします。 また、クリティカルレンダリングパスの調査と改善手法はインパクトが大きいにも関わらずあまりやってこなかったので、Gatsbyでの高速化をやってるうちに「なるほど」と腑に落ちました。 レンダリング周りの高速化は今まで手をつけていなかった箇所で、「JSでアニメーションさせるのは重いからCSS Animationでいいだろ」ぐらいの気持ちでした。反省。 JSで書いたアコーディオンやハンバーガーメニューの反応が鈍い！みたいな事例の改善が出来たり、どのCSSを変更するとレイアウトの再計算が起こるのか、どのJSのDOM APIを使用するとレイアウトの再計算が起こるのかみたいな点が分かります。 スクリプティング周りの高速化は、SPA作ってるけど遅いと感じた時に見るべき項目です。しっかり調査方法を抑えておくことで、いざという時に使えるのが大事だと思います。 画像の高速化はめちゃくちゃ大切 画像はHTML, JS, CSSと比べてもファイルサイズが大きく最も大きいリソースです。 画像のフォーマットに関する知識の紹介や、具体的な高速化手法として画像の最適化レスポンシブイメージなどが紹介されています。 個人的には画像の最適化がされていないWebページは多く、これらの知識を抑えた上でImageFlux)、imgixのような画像配信SaaSの利用をすると、めちゃくちゃ高速化に効くと感じています。 この本が合いそうな人とまとめ 一度でも高速化に取り組んだことがある。けれども、あまり自信をもって高速化を成し遂げたわけではないという人に相性がよさそうです。 逆に、「ほとんど高速化を意識したことがない」ような状態であると知らないことが多すぎてツライかもしれません。 Gatsbyとこの本の知識を組み合わせて超速Webページを作ったので後日紹介できればと思います。 個人的な感覚でいえば、クリティカルレンダリングパスと画像の最適化さえ行えばどのサイトでもある程度の速度は出る印象です。 めちゃくちゃためになる本でした。 なおこのブログに関しては低予算運用を心がけているため、画像配信のSaaSを利用しておりません。（仕事ではちゃんと使って高速化してます）

仕事でもNetlifyを使うにあたって日本語URLがちゃんと使えるか知っておく必要があったので検証しました。 まとめ Netlifyで日本語URLは問題なく使えました。 日本語ファイルは普通に使える。 リダイレクトに関してはエンコードを忘れないこと。 経緯 何度もいいますが、このブログはNetlifyにホスティングされています。静的サイトなので、基本的にメンテフリーになり運用が非常に楽です。 仕事でもNetlifyが使えてメンテフリーになればよりストレスレスな状態で働けるようになるので、仕事で作っているサイトもNetlifyにホスティングしたいと考えています。 その上で、考慮しないといけないことが「日本語URL」の扱いです。 ということで調べました。 日本語ファイルは普通に使える 普通に日本語ファイルを公開ディレクトリに置いておけば問題なく動きました。 リダイレクトに関してはエンコードが必要 Netlifyでは_redirectsというファイルに指定の形式で書くことで、リダイレクトを行うことが出来ます。(Docs) 日本語URLに関しては、エンコードが必要です。と言ってもブラウザのアドレスバーからコピペするとエンコードされたものがペーストされるのであまり意識する必要はありません。 設定例 /%E3%83%AA%E3%83%80%E3%82%A4%E3%83%AC%E3%82%AF%E3%83%88 /新URL 301 また、小文字・大文字は区別されるので注意しましょう。自分は最初に小文字でエンコードしてしまい気づくまで時間を使ってしまいました。

このブログを作っていた時、迷ったことの1つとして「スタイルのリセットどうするか？」というものがあります。 ご存知の通り、各ブラウザは標準に当ててくるスタイルが違います。特に有名なのが、Safariでは明朝体がデフォルトでそれ以外はゴシック体になるというものだと思います。 この差分を解消するためにすべてのスタイルをリセットするアプローチのreset.css、有用なスタイルは残して表示を統一するnormalize.cssという大きく2つのアプローチがありました。 僕はreset.cssとnormalize.cssのいいとこ取りなress.cssを使うことに決めました。以下選択の背景です。 normalize.cssのツライところ 自分がWeb開発を始めた2012年ごろはreset.css一択で、いつの間にかnormalize.cssの勢いが増してきてnormalize.cssをCSSリセット手法として扱うUIフレームワークも増えていきました。 normalize.cssは基本的にスタイルをいじらないCSSフレームワークに使うのは便利なのですが、少しでも新しいものを書こうとすると次のようなmargin, paddingをリセットしてから本来書きたいスタイルを書くということが多くなっていきます。 .hoge { margin: 0; padding: 0; /* 本来書きたいスタイル */ } normalize.cssを使うプロジェクトでは、標準のスタイルを残しているので、マークアップを変更するとfont-sizeやmargin, paddingが変わってしまうのが原因です。 近年では、Component単位でHTML, CSSを書いていこうという流れがあるように思えます。その際にマークアップによって変わるスタイルは邪魔になることでしょう。 ress.css そこで、a modern CSS resetを謳っているress.cssが候補に上がっていきます。以下のような特徴を持っています。 Apply box-sizing: border-box; in all elements. Reset padding and margin in all elements. Specify background-repeat: no-repeat in all elements and pseudo elements. Inherit text-decoration and vertical-align to ::before and ::after. Remove the outline when hovering in all browsers. Specify font-family: monospace in code elements. Reset border-radius in input elements. Specify font inheritance of form elements. Remove the default button styling in all browsers. Specify textarea resizability to vertical. Apply cursor: pointer to button elements. ざっくり言うといいとこ取りなreset.cssという解釈で問題ありません。ress.cssをベースにスタイルを書いていくとmargin, paddingが基本的についていないので非常にCSSが書きやすくなります。 特にAtomicDesignやReactでComponent書く時もとりあえず0からのスタートで書けるので非常に相性がいいです。 もちろんnpmでも配信されているので、ReactやVueのプロジェクトで使いたい場合は npm install --save ressでインストールしてimport 'ress'とかで導入できます。 変更する内容がないので当然とは言えますがlast commitが2017年2月で止まっています。使う時は自己責任で。 余談ですが、ライブラリ比較記事みたいな記事はたくさんあるんで、「僕はこれを選びました」みたいな記事をちゃんと書いていきたいと思っています。 比較記事は比較記事で価値はあるのですが、その人の選定理由をみたいと思うことが多いのでこういう記事を書いていきます。

4/24（火）にメルカリ社で行われたRoppongi.js #2でGatsby + NetlifyについてLTしてきました。 ちょっと遅くなってしまいましたが、ブログを作ったので書いておきます。 Gatsbyめっちゃいいですよ。 スライド https://speakerdeck.com/mottox2/create-fast-site-with-netlify-and-gatsby 雑に作ってもLightHouseで90点台が出せるという導入から、Gatsbyでの開発の雰囲気を知ってもらう流れになっています。 最後にWordPress置き換えたいけど、ビルドが遅いって話をして終わりました。 WordPressのView開発しんどすぎるので、早くGatsbyに置き換えたいです。 狙い 「簡単なことしかやってなさそうなのにめっちゃ速いサイトが出来ていること」を知ってGatsbyを触ってもいいかなという感情を生むことを目標にスライドを作りました。 キッカケ 昔から縁のある場所である六本木でJSのイベントがあるということなので、LT枠に申し込んでました。 抽選に落ちてしまって諦めていたのですが、前日の夜にLT枠が繰り上がりということだったので、急いで準備したのが上のスライドです。 明日のroppongi.js、2時間前ぐらいに繰り上がってLT枠に入ってしまった。間に合うかな…— もっとx2 (@mottox2) April 23, 2018 何を発表するか迷っていて、自作のToDoアプリケーションを作った話をしようかと思ったのですが叩かれるのが怖かったので、直近で触り始めたGatsbyについて話すことにしました。 明日のLTの題材にするためのアプリケーション作った。23:07がFirst Commitだから4時間でぱぱっと書けた。— もっとx2 (@mottox2) April 23, 2018 ただ、説明するだけでは説得力がなさそうだったので4時間ぐらいで、このブログのベースとなるesa.ioからブログを作るテンプレートを作ってそれに基づいた発表を作りました。 生まれたもの mottox2/gatsby-source-esa Gatsbyでesa.ioのデータを扱うためのプラグインです。このブログでも使ってます。 mottox2/gatsby-starter-esa Gatsbyでesa.ioのブログを作るためのテンプレートです。このブログもこのリポジトリをベースに作ってます。

2018年になってブログを始めることにしました。 都内でWebサービスを作るフリーランスをしている @mottox2 です。 Note、Medium、Qiita、はてブロなど既にあるプラットフォームで書けばより多くの人に読まれるでしょう。 しかし、アウトプットは続けることの方が重要だと考えており、自分への負荷を軽くするという点で自作のブログを使っていくことにしました。 アウトプットを続けていくこと 自分は2018年5月現在フリーランスのWebエンジニア・デザイナーをやっています。 フリーランスは会社員より自由が効くことが多く、常に自分の出来ることを続けてしまいがちだし、仕事にならないことはおろそかにしがちだと思います。それがいいところでもあるのですが、常に同じことをやっていると周りの人たちとの差はどんどん開いてしまいます。 差別化出来ないフリーランスというのは、価格競争にさらされ安い単純労働に向かってしまうと考えています。 だからこと会社員の人達以上に自制心を持ってアウトプットを続けていくことが重要だと考えています。 このブログで発信したいこと 自分が日々学んだこと、呼んだ本の感想、勉強会のレポート、誰かに伝えたいことを書いていきたいと思います。 技術面ではRuby on Rails, React.js, TypeScript周りのトピックが多くなると思います。デザイン面ではAtomicDesign、Sketch周りのトピックが多いと思います。 また、このブログの構築に使用しているGatsby.js周りも書くかもしれません。 なぜ自作のブログなのか このBlogはesa.ioというドキュメント管理サービスとつながって出来ており、ドキュメントが更新されるとブログも更新されるようになっています。 エンジニアの中には「Githubのリポジトリでブログを書いたら更新する」という仕組みを作っている方もいるようでしたが、GithubやCodeEditorで文章は書きづらく、普段書いているドキュメント管理のテンションで書いた方が、負荷が少なくブログが続けられると考えています。 ちょっと前まではQiitaやnoteでブログを書いていましたが、次のような不満を持っていました。 note Markdownが使えない APIが提供されていない アクセス解析が難しい Qiita 非公開にされる基準が曖昧で自由に書けない。 ポエムな記事がPickupされていて少しモヤっとする こういった不満を持つよりは自分で作ってしまって、気持ちよくブログを始めたいと考えました。 勢いで書いていきましたが、このぐらいのテンションで続けていこうと思います。 ブログの構築周りの話はまた後日書いていきます。