みんかぴ 
12月7日(土)に、WordCamp Osaka 2019 に参加しました！ので、珍しく参加レポートとこっちにも投稿します。
上の写真は、受付でもらったクリアファイルとしおりです。そして、マイクロスポンサーとして参加登録したので、可愛い限定パーカーもゲットしました。普段使いできそう…！！
これまでも WordCamp や Meetup(旧WordBench)には何度も参加してきていたのですが、報告はたいていFacebookで済ませていました。
今回もそうしようと、ちまちまFacebookを更新していたのですが、「シェアできないからブログ記事にして！」とありがたいお言葉を頂いたのでした。確かに。記事にすればええやんな。
金曜日の夜から前日入り
今年の WordCamp Osaka 2019 は、金土の2日開催。金曜日がコントリで、土曜日がセッションです。
金曜日はお仕事があったので、残念ながら不参加。仕事終わりにそのまま新幹線で向かいました。
おともは柿の葉寿司です( “´༥`” )
こういう時にしか食べられないので、新幹線で食べるお弁当は、押し寿司率が高めです。
ホテルに着いたのは12時くらい。ほとんど何もせずに寝ました_(-ω-_[▓▓]
次からは日曜日、セッションデイの1日を書いていきます。
Kiteさん 「WordPress でも大丈夫！実例で見るウェブパフォーマンス改善」
最初に、Kite Kogaさんのセッションを聞きにいきました！「WordPress でも大丈夫！実例で見るウェブパフォーマンス改善」です。
スライドも公開されています。
ここのところ業務でWEXALを用いた高速化ばかりやっているので、そういったエンジンを利用しない場合の改善施策や、新しい手法を知りたくて聞きに行きました。
今はJavaScriptで実現するしかないlazyloadですが、先日属性付与だけで実現できるようになるかも！？という記事を読んで、わくわくしたものです。
まだChromeだけなんですね…早く他ブラウザも対応して欲しい…！！
以下はFacebookに投稿した、箇条書きメモです。
調査と計測
- WordPress5.1のサイトヘルス
- Lighthouse（CIも）
- Chrome Audit
- PageSpeed Insights（過去1週間くらいのChromeのエクスペリエンスレポートもデータに反映）
- Site kit
- WebPageTest
- Test My Site
コーディングなし改善施策
- サーバ（ロリポがLiteSpeedプラン提供開始、第4のWebサーバ）
- nginx、LiteSpeed 、HTTP/2などなど
- 不要プラグインのアンインスト（1千万レコード、1.4GBまでデータを溜め込んでいるプラグインに遭遇）
- 最適な画像形式の選択。色数少ないならsvg、多いならjpg…可能ならWebP。
- SVG書き出しは、イラレはスクリーン用に書き出しで。他はそのままでもOK。
- WordPressはセキュリティの観点から、デフォルトではSVGのアップロードを許可していない。Safe SVGプラグイン。
- og:○○系がSVGに対応してないので、別途jpgやpngを用意する必要あり。
- オフスクリーン画像の遅延読み込み。loading=”lazy”属性付与がおすすめだが、今はChromeのみサポート（最近デフォルトで対応してくれるようになった）。native lazyloadプラグイン、Google製。他ブラウザでもJSで対応してくれる。
- キャッシュ設定
- PWA/Server Worker、ブラウザにキャッシュを保存してくれる、オフライン表示を再現。
- 最終的には静的化、Shifter。
コーディングあり改善施策
- ページによってCSSとJSの読み込み制御。
- レンダリングを妨げるリソースの除外（スライド参照）※この表にWEXALも並べれば違いが分かりやすそう。
- WordPressでやるなら、preg_replace()しかない。
- resource hints。preloadなど（スライド参照）
- WordPressにはwp_ resource_hintsフックあり。dns-prefetchについては、enquereにフックしてるものをWordPressが自動でタグ追加してくれる。
- JAMstack。WordPressはAPIとして使う。
まとめ：エントロピー増大の法則
- 減らすのは人しか出来ないが、簡単ではない。
- どういうものを作って、どこまでやるか。
西川さん「エンタープライズ向けにWordPressを提供するためにあなたとコミュニティができること」
次に、西川 伸一さんのセッションを聞きました！「エンタープライズ向けにWordPressを提供するためにあなたとコミュニティができること」です。
スライドも公開されています。
タイトルからはなかなかどういったお話になるのか想像ができなかったけど、聞いてみるとすごく夢のある話でした。そして、これが実現できればコミュニティがさらに発展しそうでわくわくしました。
もう、ひとつの会社というか、パートナーシップというか・・・なんか、いろいろと考えさせられました。
私もどこかしらの「必要になること」への参画ができるといいな。
以下はFacebookに投稿した、箇条書きメモです。
- Web周りで必要になるのはデザイン、開発だけではない。
- セキュリティとかドキュメンテーションとかワークフローとかユーザー管理とかプロマネとかサポートとかアセット管理とかとかとか。
- 全部できる人はいないから、サービスとして提供している企業があり、そこに頼んでいる企業がある。
- 今のエンプラの世界観は、データの収集→分析→活用。
※今私がやってることみたいだ。 - DXP。タッチポイントが様々、WebやIoTや店舗、DMなどと組み合わせ。パーソナライゼーション、平均からの脱却。APIファースト、様々なツールとの連携。
- これは大企業だけの関心ではなくなる。理解してコミュニケーションしたい、エンゲージメントを高めたい。
- Webサイトを持つ意味の変化→「顧客理解とコミュニケーション」「ビジネスそのものになっている」「IT部門への社内外注からの脱却」「ビジネスの基盤」
- ＼実はまだ本題ではない！／
- WordPressはハブとして動けばいい。
- 前述したたくさんの必要なことは、コミュニティ内に得意な人がいるはず。
- ＼ここから本題！／
- それぞれ得意な人が集まればいいじゃん、というか集まってるじゃん。一人でじゃなくて、一人ひとりの力で。
- 共同でリサーチ、ケーススタディなど。
おまけ：コードレビューの自動化！？
WordCamp中に、Facebookで流れてきた、とっても気になる記事！
今はまだ日本では利用できないし、Javaのみ対応だけど、あっという間にいろいろな国と言語で利用できるようになるんだろうな。コードレビューって工数けっこうかかるので、自動でやってもらえるならすごくありがたい！！
もう既にコードレビューができるのだから、AIがコードじたいを書けるようになるのも時間の問題ですね。
前もちょろっと考えてましたが、今WEXALを使っていても、AIって本当にすごくて・・・将来確実に、エンジニアの仕事ってなくなると思います。発想や提案だけAIに渡せばそれで勝手にプログラミングしてくれるとか。
プログラミングするって曖昧なところがないから、画像認識とか音声認識と比べても、AIの得意分野ですよね。
今後残る仕事ってきっと、人間がやらなきゃ意味がなかったり、必要とされないような仕事だけなんでしょうね。介護とか画家とか作家とか俳優とか・・・
10年後にはもう仕事ないだろうなとか考えて、今後どうしようかとうっすらと考えていたりします。
ランチとスタンプラリー
時間はお昼、ランチタイムです。大阪にきたので、大阪っぽいランチが食べたい！ですよね！！
去年は近くのお店でたこ焼きを食べました。美味しかったです(๑´ڡ`๑)
今年はどうしようか、昨年たこ焼きだったから、お好み焼きとか？・・・近くにお好み焼きお店はあまりないね・・・またたこ焼きかなあ・・・と、調べに調べて行き着いたお店がこちらです。
幸せでした(｀-ω-´)✧
美味しそうな食べ物の写真が撮れるようになりたいです。
その後会場に戻って、スタンプラリーに挑戦。いつもより少し苦戦し、集め終わりました！
左が私のわぷーです。可愛いポーチをゲット(つω`*)
ハムさん「運用も最大限考慮！コーポレートサイトでブロックエディタフル活用の事例紹介」
次は長谷川 広武ハムさんのセッション、「運用も最大限考慮！コーポレートサイトでブロックエディタフル活用の事例紹介」です。
スライドも公開されています。
また、スライド内で共有されていた記事やスライドをいくつか掲載しておきます。
Gutenbergがリリースされた当初は、私も「HTMLコーディング好きだから、ブロックエディタなんて嫌だ！マークアップ考えさせろ！」とか思ってましたが、今はがっつり使って記事を更新しています。
セッションの中でも言われていましたが、本当に設計次第で、「the_content()だけで全部出せる」んですよ！
テーマのコード書く量も減れば、クライアントの自由にレイアウトできるから、「ここはエディタ外の変更だから工数かかりますねー」とかもなくなる。夢みたい。
それと・・・ブロック間の余白は統一したいはめちゃくちゃ同意です。私は新人のときでも、デザイナーさんに「ここの余白ってこっちと違うの合ってますか・・・？」とか聞いたりしてましたもん。。。
以下はFacebookに投稿した、箇条書きメモです。
一番最初に大事なこと
- 札幌には「赤くて美味しいタピオカ」があるから、遊びに来てね！
ブロックエディタで設計が変わった
- 投稿コンテンツが全てブロックエディタ入力対応のサイトをリリースした。それをの事例紹介。
- 商品情報ブロック→カラムブロックを使う。カスタマイズとして、画像や商品名を再設定でなく既存記事を参照するようにした。→Advanced Post Blocksプラグイン
- 表ブロックのスタイルを用意。リストブロックも用意。スタイル追加は比較的容易。
- 更新頻度の高い投稿タイプはわかりやすく、お客様も運用しやすいようにブロック構成。ほぼいじらない特殊なページはHTMLで構成。
- 再利用ブロックにカテゴリが設定できるようにした。変更頻度が高い再利用ブロックに専用のリンクを用意。
- 設計4ヶ月、開発2ヶ月、調整1ヶ月、入力1ヶ月。設計の4ヶ月は、ブロックエディタ採用前からの提案だったから。ブロックエディタ使っていいか、こんなものです含めた期間。
- ワイヤーの段階でブロックを確定させること。ワイヤー確定後にブロック精査か、ブロック確定後にワイヤー作るか、どっちでも。今なら後者の方がいい。
- デザインやワイヤーから、どのようなブロックが必要かなどをまとめていく力が今後ディレクターに求められる。仕組みや構造が一緒でデザインだけ違うかなど、抽象化。
- カスタムブロックさえ作れば、コンテンツに全部入る。the_content()だけで全部出せる。重くなりづらい。
- カスタムフィールド前提の設計と構築を避けたかった。この話は今に始まったことじゃない。理想はデフォルトテーマに変えても機能するような設計と構築。外観とコンテンツを分離するため。
- カスタムフィールドの利点として、入力の制限と明確化があり、表示崩れ防止や運用のしやすさがあった…が、制作やメンテに負担がかなりかかっていた。
- 「WordPressテーマの作り方2019 私のベストプラクティス」スライドは、テーマ作成者必読。
- WordPress案件は難しい。機能が増えて、できることも多くなったから。
- 運用も踏まえて仕様を詰めることと、ブロックエディタの理解が必要。
- デザイナーは特にどんなHTML構造か、どんなスタイルがついているかの学習が必要。ここの学習コストが増えてきた印象。
- ブロック間の余白は統一したい。隣あっているブロックによって余白を変えると制作工数が増える。死ぬ。デザイナーさんには、そのこだわりでどれくらいのコストがかかるのか知って欲しい。
まとめ
- ブロックだけでページ構成できるように。
- 制作ブロック数で工数が変わる。
- スタムフィールドは最小限に、使うならコンテンツ以外の構成に。
- Gutenberg One Year Later。英語記事だがコメントまで合わせて見て欲しい。
岡本さん「Getting Started JAMstack Based WordPress」
次はOkamoto Hidetakaさんのセッション、「Getting Started JAMstack Based WordPress」 です。
スライドも公開されています。
実は、JAMstackというのを一切知らない状態で聞きに行きました。
タイムテーブル見ていた時に、黄色い方が「へー、JAMstack話すのかー」みたいな反応だったので、そんな注目されてる技術なのかな？！みたいな。
そんな初心者でも、おおまかにどんなものか分かるくらいに、わかりやすいセッションでした！
いまいま簡単に導入するには私のスキルが足りないけど・・・別のWordPressの使い方として覚えておいて、粛々とJavaScriptの勉強しなくちゃですね。
以下はFacebookに投稿した、箇条書きメモです。
JAMstackとは
- 高速で安全なサイトを作るアーキテクチャ
- JS、API、markup の略。
- 今の技術で阿部寛のサイトを目指そう！
- 事前生成したHTMLを配信。WordPressテーマがmarkup、DBがAPI。markupにAPIデータをマージしてHTML生成。
なぜWordPressに使うのか
- 早い、強い、固い、楽
- アクセス経路の一本化でリスクを局所化。
- 処理とDBとフロントの分離でスコープの明確化。
どう使うのか
- WordPressをAPIサーバとして採用し、Jとmの技術選定、JAM、運用のワークフロー整備。
- 重複コンテンツに気をつける。ログイン以外は301、カノニカルやノーインデックスの設定。
- WordPressをメンテしないでいいようにフルマネサーバを検討。
- StaticGen
- 今はReact(nextなど)やVeu(nuxtなど)。なんでもいいけど、書き方やAPI、頼れる人がいるかなどで選定。Angularはあまりメジャーじゃない使い方になる。
- JMにAを流し込む。graphQL。Reactでmarkup、gatsbyがAPIからデータ取り込み。graphQLで、データをインポート。
- WordPressの更新≠サイト更新になる。HTMLビルドが必要になるので、netlifyなどでビルド→公開。WordPressからビルド実行を指示する必要がある。JAMstack Deploymentプラグイン。WebHook。
- 公開前チェックもビルドが必要。プレビュービルドやローカルビルドがある。どのビルドHTMLを公開するか選べるからロールバックが容易。(WordPress側はロールバックしないから注意)
メリットとデメリット
- 今までのWordPress制作ノウハウが使えない
- JavaScriptやってこうは、遅かれ早かれフロントにも管理画面にもくるよ
- するかしないかは、失うもの<手に入れるものになるように選択する。
- ポジショントークに振り回されないようにする。
- パフォーマンスや可用性が求められる、別CMSに移行する予定がある、インタラクティブなサイトを作りたい、JSノウハウの多いチームのとき、WordPressのメンテなくしたいとき→JAMstack
- JAMstackのメンテ体制がない場合、コンテンツが不十分な場合、これからWordPressはじめる場合、プラグインとテーマを使って構築運用していきたいとき→WordPress
- WordPressの管理画面は欲しいけど、フロント自由にしたいときにおすすめ。
最後に大事なこと
- 盲信しないで自分で触ってやってみて！
メインルームの動画公開
今回のセミナーはYouTubeでライブ放送されていました。まだ見られるみたいなので、常翔ホールでやっていたセッションで見られなかったものはこちらで見てみましょう！
おすすめは基調講演、Mike Schroderさんの「The Future of WordPress」です。
6:57:00くらいから見られます。
最後におまけ
懇親会とかも出ましたが、長くなってしまったので割愛します。ただ、楽しかった！！！
帰りの新幹線では、金曜日大阪についたときにポスターを見て気になりまくっていたこれを食べました。
すごくおいしかったので、大阪来たときのお決まり弁当になりそうな予感…！！
今年もスタッフの皆さん、本当にお疲れ様でした！