Twitter タイムラインをAMPページに埋め込んでみました

AMP for WordPress v1.0-beta3 のリリース記事内に、新しく追加されたTwitter タイムラインのアトリビュートをサポートしていると書かれていたので、本ブログでベータ3をインストールした際に試してみましたが、その時は動作しませんでした。まだ少し調整が必要なのだろうと思っていました。

少し日が経過したので、本日、Twitterのタイムラインの埋め込みに再挑戦してみました。今回は、無事に表示されました! しかし、高さの指定・制御ができない状態です。現状、縦に非常に長く表示されてしまいます。

この現象は、タイムラインだけでなく、Twitter モーメントなどでも発生しています。AMPの仕様では、予め縦横の値を指定して、アトリビュート(パラメーター)にレスポンシブを指定すると、設定した縦横比(アスペクトレシオ)に合わせて表示される仕様になっています。

現状、Twitterのコンポーネントでは、組み込み表示のの際、アスペクト比が動作しない状況であると、AMP by Exampleに説明が記載されています。ツイートの埋め込みではマニュアルで縦横の値は設定通りに表示されるのですが、モーメントとタイムラインの埋め込みでは動作しないようです。

AMP by Exampleでモーメントの幅を390、高さを330、レイアウトをレスポンシブで設定しているのですが、縦に凄く長い状態で表示されてしまっています。

以下は、幅350、縦550に設定した状態での埋め込みTwitterプロフィールです。物凄く縦に長いです。(苦笑)

ソースコード

<amp-twitter width="350"
height="550"
layout="responsive"
data-timeline-source-type="profile"
data-timeline-screen-name="blogginglifejp">
</amp-twitter>

埋め込みタイムライン表示例

 


 
本ブログのサイドバーに埋め込んでみたのですが、かなり長くなって表示されてしまったので、設置を見送りました。埋め込みのツイートは需要もかなりあるので、速やかに対応されていますが、モーメントやプロフィールをAMPページに埋め込む需要はまだ少ないと思われます。需要もまだ少ないため、対応も後になっていると推測しています。縦の長さが制御できるようになったら、本ブログでも設置する予定です。

本ブログのサイドバーにTwitter プロフィールを埋め込み設置した時の状態をYouTubeで紹介しています。

 

Twenty Fifteen 子テーマの作成、フォントの変更

今週行った本ブログの設定関連の作業について、以下に記します。

Twenty Fifteen の子テーマ作成

本ブログは、AMP for WordPressのベータバージョン1.0の備えるネイティブAMP機能を使用しています。ネイティブAMP機能は、大まかに言うと通常ページのテーマをAMP化するものです。まだ、開発途上の段階であり、プロダクションには適さないと断りもあるステータスです。

WordPress標準テーマのTwenty Fifteen, Twenty Sixteen, Twenty Seventeenは、ある程度安定して動作するとのことから、Twenty Fifteenを選択しました。選択した理由などについては、以下の記事に詳しく書いております。

ネイティブ AMP ブログのテーマにTwenty Fifteenを選んだ理由

試験的な形で運用を開始しましたが、基本的な機能は問題なく動作しています。

機能追加などの設定変更でテンプレートファイルなども編集していました。テンプレートファイルを直接編集している場合、テーマの更新時に変更した設定内容が上書きされてなくなるため、再設定が必要となります。子テーマを使用することで、再設定せずに済むため保守、管理の上で優位です。

これまでは、Twenty Fifteenを継続して使用するか未定だったので、テンプレートファイルを直接編集していました。現状、予想していた以上に無事に動いているので、当分の間は、Twenty Fifteenを使っていくことにしました。そのため、Twenty Fifteenの子テーマを作成することにしました。

Twenty Fifteenは、標準では子テーマは提供されていませんが、WordPressのサイトに子テーマの作り方の記事が掲載されています。この記事の中では、Twenty Fifteenを例にして子テーマの作成方法を紹介しているのでとても参考になりました。

記事の内容に基づいて、子テーマを作成したところ、無事に動作しました。

追記:

WordPress 子テーマの作成について、ブロギングライフに記事を投稿しました。

WordPress 子テーマの特長、作成方法と利用例

子テーマ移行後、バリデーションエラー発生

子テーマに切り替えても、ブログページは問題なく表示されていたのですが、記事を更新した際にバリデーションエラーが発生しました。AMPでは仕様が厳しく、CSSの容量も50KBに制限されています。オリジナルのTwenty Fifteenのスタイルシートだけで98Kもあり、それだけでもAMPの制限の倍近いサイズです。

プラグインの方でかなり工夫をして、AMP化しているのですが、ちょっとした変更や機能追加をしようとするとCSSの容量にひっかかってエラーが発生したりします。子テーマに切り換えて、記事を更新しただけでもエラーとなってしまい、一瞬、暗い気持ちになりました。

少し調整をしてみたところ、エラーがなくなりました。しかし、正直、ギリギリで動作している感が強いです。さらなる変更を行った時に、エラーが発生して対応できるか懸念があります。

フォントの変更

子テーマにしたので、CSSの追加などは気楽にできるようになりました。Twenty Fifteenのフォントは、日本語を表示した時のデフォルトは明朝体です。個人的に、サイトのフォントはゴシック体が好きなのですが、Twenty FifteenでAMP化後、明朝体で表示されるページの感じも悪くないと思い、意外と気に入っていました。フォントは変更しなくても良いかと思ったのですが、折角、子テーマにしたので、試しにフォントを変更してみました。(子テーマであれば、フォントの変更も気楽にできます。)

ホームページの記事全文表示から概要表示に変更しました

本ブログが使用しているWordPress標準テーマ Twenty Fifteen は、ホーム(トップ)ページは、最新の投稿記事の全文が表示されます。

ホームページで表示する記事数は、WordPressダッシュボードの「設定」から「表示設定」を選び、1ページに表示する最大投稿数を指定します。デフォルトでの表示投稿設定は10記事です。

このブログでは、テキスト中心の日記的なコンテンツも取り扱うことも考えていて、レイアウトのスタイルは、Google ウェブマスター向け公式ブログ  のような構成にしたいと考えていました。

Google ウェブマスター向け公式ブログは、トップページは直近の5記事がフルに表示される構成です。このブロギングライフBLOGでも、直近の5記事全文を表示する設定でスタートしました。

このブログで使用するテーマを選ぶ上での前提条件やコンセプトなどについては、ブロギングライフに投稿した記事に詳しく書いております。

ネイティブ AMP ブログのテーマにTwenty Fifteenを選んだ理由

このブログは、レイアウトやコンセプトはクラシックなスタイルにしていますが、ネイティブAMPに対応するなど、最新機能を搭載しています。AMPでは、構造化データの設定が前提となっていたり、AMPの記事の構造化データのマークアップでは、画像を含めることが必須となっています。

テキスト中心のコンテンツを中心に取り扱って、最近のブログで普及しているアイキャッチ画像は使用しない方向で運営する予定だったのですが、Search Console のAMPレポートで警告が表示されたり、AMPテストでも警告が表示されたり、不安定な状態となっているため、記事によってはアイキャッチ画像を設定する方向で運営方針変更を検討中です。

画像が加わると、記事の物理的な長さも長くなります。ユーザーがトップページから記事を読む場合にスクロールを多くする必要が発生します。多くのスクロールをユーザーに強いることは、ユーザーの使い勝手やユーザーエクスペリエンスの上でも、好ましいことではありません。

そのため、トップページは記事の序文のみ表示する設定に変更しました。「続きを読む」をクリックするとその記事の全文が表示されます。このようなページの表示や構成は、必要と思われる場合は(やった方が良いと思う場合を含みます)、適時変更したり、試してみることも重要と思います。

今トップページで表示する記事数は、とりあえず5記事のままにしています。(10記事でも良いかもしれないと思っています。)

サイト運営は、トライアンドエラーがつきものです。将来、表示構成を変更することもあるかと思いますが、色々試してみようと考えています。

 

Search Console AMPレポート表示開始。しかし、不可思議なステータス

本日、本ブログのプロパティをSearch Consoleで見てみると、メニュー項目の「拡張」の下に「AMP」が表示されていました。プロパティを登録して、5日程度でAMPレポートが表示されるようになりました。(AMPページがサイトに存在しない場合は、メニューにAMPは表示されません。)

Search ConsoleのメニューにAMPが表示されています

依然として不可解なAMPステータス

AMPのレポートを表示すると有効(警告あり)が1,有効が5と表示されていました。

Search ConsoleのAMPステータス レポート

警告の内容は、「必須の構造化データ要素のエラー」です。

「必須の構造化データ要素のエラー」の警告メッセージ

AMP テストを行うと合格します。しかし、一つ前の不安定なAMPテスト結果の記事で紹介しているように通常AMPテスト結果に表示される推奨する対応「構造化データが有効なページ(または、問題があるページ)」の部分が表示されません。

AMPテスト結果は合格

構造化データの出力は、全てのページで基本的に同じにも関わらず、有効(警告あり)と有効に分かれるのが不可解です。画像のあるページと無いページということで結果が分かれているわけでもありません。まだ、初期段階なので、これからどちらかに結果が統一されてくるかもしれないと考えています。

試しに「修正を検証」のボタンを押してみたところ、検証が開始となりました。現状、AMPの仕様を満たす構造化データは出力されていないので、検証が不承認となる可能性も十分にあります。

Search Consoleに検証開始のメッセージ表示

検証の結果がとうなるか興味深いです。有効(警告あり)と表示されるのは、やはり気になるので、構造化データの出力に関しては対応する予定です。

このブログでは、アイキャッチ画像は設定せず、テキスト中心の投稿にする予定でしたが、記事によっては今後はアイキャッチ画像を設定する方向で検討中です。

追記:

AMPでの構造化データのマークアップは、必須ではなく、推奨に変更になったようです。(上のSearch Consoleの警告メッセージには、「必須の構造化データ要素のエラー」となっています。)

変更に伴い、AMPテストで構造化データの出力がないページでは、テスト結果に構造化データの項目が表示されなくなったと思われます。

AMP テストに構造化データの項目が含まれない理由

追記2:

一日経過後、Search ConsoleのAMPレポートで警告は0になりました。検証も一日で合格しました。

AMP レポートの警告は一日で検証合格となりました

不安定なAMPテスト結果 – 構造化データ 画像未出力が原因?

ネイティブAMP対応でも、大きな問題は発生せず、主要な設定も無事完了して、記事も投稿を開始しました。設定に時間をかけ過ぎになってしまうことを懸念していたので、まずは順調な出足をきることができたと思っていました。

記事の投稿を開始してから、Search Consoleに本ブログのプロパティを登録しました。通常、プロパティを登録してから、数日から1週間程度すると Search Consoleにデータが表示されるようになるのですが、本ブログの場合、2日後には一部のデータが表示されるようになりました。

ネイティブAMPに対応していると、クローラーの解析なども早く、Search Consoleでの処理も早くなるのかなと思っていました。レポートなどの表示が早いのは良かったのですが、Search Consoleのレポートの表示もその時によって異なる不安定な状態になっています。

AMPで必須となっている画像の構造化データの出力がされていないことが、レポートの表示が一定しない理由ではないかと推測しています。現在の本ブログのページは、構造化データの画像出力がないために警告付きで有効となっています。

AMPのステータスは警告ありの有効

同じページについて、AMPテストを行うと問題ないと表示される(合格)こともある一方で、エラーとなってしまったりすることもあります。

AMPテスト合格の表示

不思議なことに通常のAMPテスト結果に表示される推奨する対応「構造化データが有効なページ(または、問題があるページ)」の部分が表示されません。この部分が表示される時は、構造化データの出力に問題があると表示されます。

AMPテストの結果に構造化データに関連する結果が含まれていません。

テスト中の状態が続いた後に、以下の様に何らかの問題でテストができなかったと表示されることがあります。

AMP テストが完了しない問題発生画面

同じURLをテストしていても、その時によってテスト結果が異なります。上に添付している結果画面以外の表示になる(赤字で構造化データに関連する警告メッセージ表示)時もあります。

AMPページにも関わらず、構造化データの画像の出力がなく、さらにページ自体に画像がないというようなページは、AMPテストの想定を超えているのかもしれません。(苦笑)

アイキャッチ画像は使わず、テキスト中心のコンテンツにすることを予定していたのですが、AMPで必須となる構造化データの画像出力を行なっていないことは、大きな課題、懸案事項となっています。

テキスト中心のコンテンツを取り扱うブログであれば、AMPにする必要性は、ほとんどありません。AMPを推進しているGoogleですら、公式ブログはAMP非対応です。テキスト中心のブログは、AMP化する必要はないことをGoogleのブログが如実に物語っているとも解釈できます。

AMPは検索との関わりが深い設計思想を元にした仕様です。ブロギングライフBLOGは、検索からの訪問を主眼には置いていません。しかし、ネイティブAMPと言う新しい試みに対応するサイト運営をしたいと言う考えを持っています。

サイト運営は、状況に応じて、柔軟に対応することも必要な場合もあります。アイキャッチ画像は、個人的には使いたくないのですが、試験的に一部の記事では導入して見ようと思います。また、適切な構造化データの出力に関しても、改めて対応が必要と考えています。

気づいたことや更新情報は、適時、本ブログに投稿する予定です。