ウェブサイトのパフォーマンス向上のための WordPressプラグイン「Better Website Performance」を作りました。

最近のウェブサイトは、ウェブページの読み込みや表示速度 (PageSpeed) などパフォーマンス面も検索エンジン対策 (SEO) において検索順位を決める重要な要素の一つとなっています。そのため、個々のウェブサイトで適切なパフォーマンスを発揮し維持するためにサイト最適化が求められています。

WordPressプラグイン「Better Website Performance」の主な機能は、以下のとおりです。

HTML ヘッダー最適化

WordPress によるメタタグや rel=link 出力を最適化します。

絵文字

WordPress に実装されている絵文字リソースを最適化

レスポンシブ画像 (image srcset）

WordPress に実装されているレスポンシブ画像 (image srcset) を最適化

非同期 JavaScript

非同期 JavaScript を管理します

jQuery

jQuery の読み込みを管理

CSS の結合やインライン化

スタイルシートファイルの読み込みをインライン化したり、縮小化、または結合します。

追加 CSS

WordPress に実装されている追加 CSSをヘッダーに配置します

Resource Hints

リソースを事前に読み込んでパフォーマンスを向上させます

Preload

リソースを事前に読み込んでパフォーマンスを向上させます

WordPressプラグイン「Better Website Performance」

• wordpress.org 公式ディレクトリ
• Performance」GitHib - WordPressプラグイン「Better Website

WordPressプラグイン「Editor Bridge (エディタブリッジ) 」は、デフォルトのブロックエディタを拡張するプラグインです。

デフォルトブロックの機能を拡張したり、フォーマットやスタイルを追加してみました。どのようなことができるかを確認できるサンプルページを作りましたので、そちらをざっくり見てみてください。

• WordPress plugin Editor Bridge demo sample
• WordPressプラグイン「Editor Bridge」デモサンプル

WordPressプラグイン「Editor Bridge」で、できることは大きく3つ。

1つ目は、デフォルトブロックの機能を横断的に拡張します。 デフォルトブロックに背景画像や枠線 (ボーダー) を付けたり、マージンやパディングなど余白 (スペース) を設定できます。またボタンのサイズや幅など各種設定ができるように設定パネルに追加しています。

対応しているブロックは以下の通り。

• Background image (背景画像)
  • core/heading
  • core/paragraph
  • core/column
  • core/columns
  • core/group
• Border (枠線)
  • core/heading
  • core/paragraph
  • core/group
• Button size and width (ボタンの大きさと幅サイズ)
  • core/button
• Space, Margin (upper margin as default) and Padding (スペース)
  • core/heading
  • core/paragraph
  • core/image
  • core/button (only Margin)
  • core/buttons
  • core/media-text (only Margin)
  • core/gallery (only Margin)
  • core/list (only Margin)
  • core/table (only Margin)
  • core/columns
  • core/column (only Padding)
  • core/group
  • core/cover

2つ目は、見出しや段落など文字を入力するところに使われる RichText Component にフォーマットを追加。文字の大きさや太さを変えたり、文字を装飾する強調やバッジが使えます。

バッジはちょっとしたアクセント用のテキスト装飾に、強調は文章の一部を強調できます。ブロックにスタイルがあるように、フォーマットにもスタイルが選べるようにしてみました。

• Badge (バッジ)
  • Default (デフォルト)
  • Round Corner (角丸)
  • Round (円形)
  • Outline (アウトライン)
  • Status (ステイタス)
  • Perfect Circle (正円)
• Font size (フォントのサイズ)
• Font weight (フォントの太さ)
• Highlight (強調)
  • Highlight (強調)
  • Marker (マーカー)
  • Underline (アンダーライン)

3つ目は、ブロックにスタイルを追加。

よく使うブロック5つほどにスタイルを追加しています。応用的な活用方法として、まずスタイルを設定して、次に拡張機能のパディングで余白バランスを整えたり。ブロックの拡張機能を組み合わせてスタイルに柔軟性をもたせることができます。

• Button block (ボタン)
  • Triangle Icon (三角アイコン)
  • Blur (ぼかし)
  • Shadow (シャドウ)
  • Expansion (膨張)
  • Emboss (エンボス)
• Heading block (見出し)
  • Underline (アンダーライン)
  • Thick Underline (太めのアンダーライン)
  • Two Color Underline (2色アンダーライン)
  • Up Down Line (上下線)
  • Accent Line (強調線)
  • Kebab Line (横串線)
  • Single Box (囲み線)
  • Double Box (2重囲み線)
  • Left Accent Line (左ラインアクセント)
  • Gradation Line (グラデーション
  • Stripe Line (ストライプ)
  • Cross Box (交わり囲み線)
  • Brackets (カッコ)
  • Japanese quotation marks (日本語の引用符)
• Image block (画像)
  • Round Corner (角丸)
  • Frame (フレーム)
  • Shadow (シャドウ)
• Separator block (区切り線)
  • Thick line (太線)
  • Dotted (点線)
  • Shadow (シャドウ)
  • Circle Mark (円マーク)
• Table block (テーブル)
  • No Style (スタイルなし)
  • Underline (アンダーライン)
  • Dashed (破線)
  • Round Corner (角丸)

プラグイン命名に悩む

今回WordPressプラグイン「Editor Bridge」を公式ディレクトリに登録するにあたり直前にプラグイン名を変更しました。

理由は、プロジェクト名「gutenberg」がプラグイン名に含まれていることについてです。 含まれていると表示名 (後で変えられる) とパーマリンク (後で変えられない) にも含まれるからです。プラグインの登録申請すると、一旦確認のメールが届きます。

そのメール内容には、上記の理由とリスクが書いてあり、正式エディタは、WordPressエディタとクラシックエディタなので、「gutenberg」プロジェクト名は時間が経てば忘れ去られる。コードネーム的な扱いですね。

そのときにそのまま登録を進めていいのか。パーマリンクを変更するなど何か対応する必要があるのか決めて返信するとレビューが開始されます。つまりワンステップ追加した形でプラグインのレビューが進められます。

もともとは「Guten Plus」というプラグイン名でしたが、その前にも「Guten Bridge」と付けていましたので、実は2回めのプラグイン名を変更でした。

「Guten Bridge」のときは、開発している途中に他に同名のプロジェクトが出てきたので、「Guten Plus」に変えたのですが。。。

今後は、とりあえずコードネーム的に名前をつけて開発を進めたほうがいいかもしれないなぁと思いつつ。いつもプラグイン命名に頭を悩まされています。

2転3転して何度も心を折られた開発

今回の開発したWordPressプラグイン「Editor Bridge」はだいぶ難航しました。

プラグインの構想自体は、WordPressバージョン 5.0 リリース直前にちょこちょこブロックの作り方を学びつつ進めてきました。

その中でいちばん実現したかったことは、スペースの設定。ブロックにマージン (margin) とパディング (padding) をいい感じにつけれたらいイイなぁと。レイアウトに変化をもたらすものになればなぁと。

しかしそれは容易なことではありませんでした。特にフロント部分とエディタ部分の整合性を調整するところ。

ブロックエディタは、2018年12月6日にWordPress (v 5.0) の標準エディタとして搭載されてからブロックエディタ自体がまだまだ発展途上で機能追加されるし、改良もされます。そのたびに仕様が変更されてしまいます。

初期の頃のブロックエディタは、とにかくエディタ部分のDOM (Document Object Model) 構造が複雑すぎて。作ってもCSSセレクタが入れ子の連続だったり、設定次第でレイヤーが一つ増えたりしてDOM構造が動的に変わります。ありとあらゆることに対応するには複雑になりすぎて整合性が全く取れませんでした。変更容易性も保守性も確保できなくなるのが目に見えて挫折。。。

アップデートのたびに大幅にDOM構造が変わるところもあり、なかなか安定しません。バージョン5.4 あたりからようやくDOM構造が素直になりつつある感が出てきました。フロント部分とエディタ部分の整合性がとれるような感触を掴んだので。形にしてもいいのではないかと。そしてリリースにこぎつけました。

今後の展望

WordPressプラグイン「Editor Bridge」は特定のテーマに依存する形ではなく、なるべくブロックエディタに対応するいろんなテーマで使えるようにしたいなぁと考えています。

一番の課題は、テーマそれぞれにマージンやパディングの余白のとり方が違うと思うので。またマージンの付け方も上部または下部とあるでしょう。そこをどのように埋められるか。

すでに少し考えていて、今回裏ではCSSカスタムプロパティを仕込んでいていろんなテーマにフィットするように開発者向けの仕組みをつくることを視野に入れていたりします。

ブロックエディタは、まだまだ改良が続くと思います。 WordPressプラグイン「Editor Bridge」もまだまだ改良や調整をしながらいいプラグインにしていきたいと思います。

話はそれてしまいましたが、ブロックエディタでWordPressプラグイン「Editor Bridge」をぜひ活用してみてくださいね。

• WordPressプラグイン「Editor Bridge」プラグインページ
• WordPressプラグイン「Editor Bridge」GitHub Repository

カスタム投稿タイプで活用できるデフォルトウィジェットブロック 7 点が詰まった WordPressプラグイン「Custom Post Type Widget Blocks」を作りました。

WordPressプラグイン「Custom Post Type Widget Blocks」は、以前つくったウィジェット版の WordPressプラグイン「Custom Post Type Widgets」のブロックエディタ版です。

WordPress 5.0 から標準エディタがブロックエディタになりました。それに伴い、ウィジェットはブロックエディタに統合されていくことを見越して、ブロックの作り方をちょこちょこ学びつつ作ってみました。

機能は、Custom Post Type や Taxonomy で絞り込みができる以外は、標準のウィジェットブロックとほぼ同じです。
ある程度安定した状態になれば、将来的に機能を追加して拡張していこうかと思います。

是非ブロックエディタで活用してみてくださいね。

• WordPressプラグイン「Custom Post Type Widget Blocks」プラグインページ
• WordPressプラグイン「Custom Post Type Widget Blocks」GitHub Repository

WordPressテーマ「Foresight」が wordpress.org 公式ディレクトリに掲載されました。

WordPressテーマ「Foresight」は、公式ディレクトリ登録を目指していたので、テーマ開発に取り組んで目標の一つを達成できて一段落つきました。これからもテーマの改良を続けてブロックエディタの活用を充実させたり、いろいろ研究開発を行っていきたいですね。

ということで、公式ディレクトリ登録を行う上で欠かせないテーマレビューはどのようなものか。2ヶ月ほどやり取りしていたレビューの所感を綴ってみたと思います。

WordPressテーマ「Foresight」の詳細や作ったときの感想は、以下を見てください。

• WordPressテーマ「Foresight」プロダクトページ
  wordpress.org 公式ディレクトリのテーマページ
• ブロックエディタにフル対応したWordPressテーマを作ってみた所感
• WordPressテーマ「Foresight」GitHubレポジトリ

テーマレビュー経緯

• tracのチケット上でのレビューの様子はこちら。
• テーマレビューの進み方 - Review Process

テーマの登録申請を2019年11月25日にしました。
その時のテーマレビュー待ち200余り。
とりあえず気ままに待つことに。

待つこと3ヶ月ほど。
2020年2月13日にレビューアさんが付いてくれました。
途中新型コロナウイルスの大流行で滞りなくレビューが進むのが心配していましたが、普通にレビューが進んでいきました。こういうときにコミュニティが機能しているありがたさが実感できますね。

最初のレビューは、作ったWordPressテーマが、Theme Check や Theme Handbook のガイドラインに準拠しているかを主に診てくれます。

そして、修正をしながら進めていくとさらにソースコートを隅々まで詳細にレビュー (complete review) してくれます。

指摘されて改善したところ (パート1)

• ディレクトリ構成が少し特殊な形なので、構成やファイル名を見直した。
• JavaScript ファイルは minified しか入れていなかったので、レビューできるように生のソースも追加で入れた。最初 webpack でバンドルしていたけど、出力される生のソースも特殊な出力なのでレビューできるかどうか分からなかった。ということで普通の結合 (concat) に変えた。
• オプションのデータの持たせ方を変えた。取り回しが効きやすいようにいつも複数の options に分けて入れているけど、公式テーマだと theme_mod (一つの配列) に入れるようにすることが大切。参考: Customizer Objects#Settings
• タブキーでのフォーカス移動などキーボード操作できるようアクセスビリティをしっかり診てくれた。特にドロップダウンメニューが展開するグローバルメニューの部分。普段キーボード操作をあまり意識していなかったのでこういうところも大切だなぁと改めて気づいた。
• テンプレート階層を少し触っているのでそのことを聞かれた。理由を説明するとすんなり受け入れてくれた。そんなに厳格さはなく、柔軟に対応してくれるようだ。

やり取りと修正を2回ほど繰り返し、ひとまず承認された。

次にダブルチェック的な最終テーマレビューへ進む。
少しベテランな感じ?のレビューワーさんが付いてくれました。
更に細かい部分まで診てくれる。特にセキュリティ面でエスケープやサニタイジングのところ。

指摘されて改善したところ (パート2)

• エスケープやサニタイジングを結構見落としているところがあった。のでチェックしてくれるの助かる。
• コピーライトやクレジットの表記の見直し
• readme.txt ドキュメントの見直し
• ライセンス上使っていい CDN や画像などサードパーティリソースの見直し。スクリーンショットを変えた。
• 標準コアにあるカスタマイザの機能を一部削除していたのでその調整をした。
• javascript のグローバル変数の扱い。プリフィックスをつけるか、または即時関数にしてローカルオブジェクトにする。
• デザイン的にボタンやメニューを画面に fixed すると。ログイン状態でページを見る場合、adminバー (ツールバー) に重なるところがある。位置をずらして重なりを回避するの厄介だった。バーの高さは通常PCで32pxでタブレットやスマホビューで46pxに変わる。adminバーはスクロールしても上部に固定されているが、スマホビューでは挙動が変わり、固定がなくなる。その高さと挙動に合わせて fixed している position を CSSやjavascriptで調整。

やり取りを繰り返し、2020年4月26日にレビューが終了した。
即日 wordpress.org にあるテーマページが公開されて、7,472点あるディレクトリ掲載テーマ (2020年4月28日現在) の一員に加わりました。
晴れて Theme Developer になりましたとさ。

WordPressテーマを公式ディレクトリ登録してみてよかったこと、感じたこと

• WordPressエコシステムの土台に乗って世界中で幅広い人に使われるように、レビュー済みで一定の品質基準を確保した WordPressテーマができた。
• いままでテーマの公式ディレクトリにはあまり縁がなかったけど。独自機能を実装したテーマと公式ディレクトリに掲載される準拠さをもったテーマとの技術的な比較基準をもつことができた。
• 公式ディレクトリに登録されているテーマの完成度が上がっている。これからも上がっていく感。よく言及されるスクリーンショット映え感ではなく技術実装面で。以前はブログ用途とかスキン的な感じのテーマが多かったりソースコードを見るとグチャグチャな感じも見受けられたけど。ブロックエディタとの兼ね合いなのか技術的にそれなりのレベル、また幅広くトータルなレベルが求められている感じがする。今後テーマを一人で作り切るのはスキル的に求められるものが多くなりそうで大変そう。チームでテーマを開発するとかに進むのかなぁ。
• 機能面の充実より、用途の提案とか、コンセプト面の充実がテーマに求められそう。そのほうが活用の広がりが生まれる。
• 今回テーマを作ったり、WordPressテーマスタータキット「WP Theme Boilerplate」を開発したりしてきて。WordPressテーマの開発は、スクラッチから作ったり、フレームワークから作ったり。公式テーマや無料有料テーマのありあわせものでサクッと立ち上げたり、カスタマイズしたり。多様なアプローチが取れるようになってきていると思う。その都度ふさわしいやり方を選んでプロジェクトが進められそう。プロジェクトマネジメント面の発展とかにつながる。

可能性が広がっているなぁと感じる今日このごろです。