wp_head に標準フックされる関数一覧 ver.4.2
wp_head アクションには、いくつかの関数が標準でフックされています。 ここでは WordPress 4.2 の wp_head にフックされている関数とその役割を一覧します。 標準でフックされる関数は、./wp-includes/default-filters.php から確認することができます。
WordPress は多くのユーザのための汎用的な関数を wp_head に標準でフックしています。 したがって、wp_head にフックされる関数のいくつかは、利用状況に応じて削除しても良いでしょう。
不要な関数の呼び出しを停止すること、それによって出力されるコードを減らすことは、 ページの読み込み速度などのパフォーマンスを改善することにつながります。
一方で、 WordPress の扱い方、利用状況によっては削除するべきでないものもあります。 標準の関数、削除する関数がどのような役割を担っているのか理解することは重要です。
目次
- _wp_render_title_tag
- wp_enqueue_scripts
- feed_links
- feed_links_extra
- rsd_link
- wlwmanifest_link
- adjacent_posts_rel_link_wp_head
- locale_stylesheet
- noindex
- print_emoji_detection_script
- wp_print_styles
- wp_print_head_scripts
- wp_generator
- rel_canonical
- wp_shortlink_wp_head
- wp_no_robots
wp_head にフックされる関数一覧
_wp_render_title_tag
_wp_render_title_tag 関数は 4.1 からの導入されたテーマ機能です。 使用中のテーマが title-tag をサポートするとき、タイトルタグを出力します。
4.1 以前の WordPress では、次のようなテンプレート用の関数を使ってタイトルを出力していました。 title-tag 機能がサポートされている場合には、wp_head アクションフックによってタイトルが出力されるので、4.1 以前のような関数を記述する必要はありません。 title-tag 機能の利点は、プラグインなどがタイトルの内容を変更できるようになる点です。
title-tag 機能を有効にする場合には、この関数は削除してはいけません。 一方で、wp_title 関数はテンプレートファイルから削除します。
title-tag 機能を無効にしたテーマの場合には、この関数は削除してよいです。 一方で、wp_title 関数はテンプレートファイルに記述される必要があります。
_wp_render_title_tag - WordPress.org (2015.06 現在、まだページができていないようです。)
wp_enqueue_scripts
wp_enqueue_scripts 関数は、wp_enqueue_scripts アクションを実行します。 wp_enqueue_scripts アクションにフックされた関数を実行して CSS や Javascript を読み込みます。
多くのテーマやプラグインが wp_enqueue_scripts アクションを利用するので、 この関数は削除するべきではありません。
wp_enqueue_scripts - WordPress.orgfeed_links
feed_links 関数は RSS フィードのリンクを出力します。RSS フィードが不要である場合には削除しても良いです。 ただし、ブログ投稿システムや外部の管理ツールと WordPress が連携している場合には、 それらが RSS を参照していないことを確認する必要があるでしょう。
執筆時現在(2015.06)では、RSS リーダを使うユーザは減少する一方のようです。 Google も 2013 年にサービスを終了しました。
Feedly が Google Reader のユーザを受け入れ、 RSS リーダの大手となっていますが、Feedly が最後の砦でしょう。
バイラル・キュレーションメディアの類、あるいは検索エンジンの一部は RSS を考慮することもあるでしょうが、 schema.org などの構造化データ、メタデータが普及することを考えると、重要度は更に下がることが予想されます。
しかしながら、標準的な RSS フィードについては削除しないことを推奨します。 RSS による集客が 0 であることを保証できないためです。
バイラル・キュレーションメディアやニュースサイトの類を運営し、記事を投稿している方々が、 多くの情報を取捨選択するために、RSS を活用することも考えられます。 RSS は機械的に処理し、また人間が要約を確認するために都合が良いフォーマットであるためです。
feed_links - WordPress.orgfeed_links_extra
カテゴリページやコメントなどの RSS フィードを出力します。RSS フィードが不要である場合には削除しても良いです。 ただし、ブログ投稿システムや外部の管理ツールと WordPress が連携している場合には、 それらが RSS を参照していないことを確認する必要があるでしょう。
feed_links による標準的なフィードの配信と比較して、カテゴリ専用のフィードなどを配信します。 多くの場合に、ある WordPress サイトの配信する情報はある程度カテゴリが限定されていますから、 別途カテゴリ別の RSS を活用する場面は多くないでしょう。
また RSS を活用してデータを取得するようなユーザは、そのサイト全体のフィードを取得するようにするのが普通でしょう。 わざわざカテゴリ別の RSS を取得することは少ないと思います。
カテゴリ別やコメント向けの RSS を特に明示することも考えられますが、ノイズに近い情報をユーザに提供するだけでしょう。
feed_links_extra - WordPress.orgrsd_link
ブログ投稿システムなどの外部ツール向けのリンクを出力します。外部ツールを使わないなら削除しても良いです。
自動投稿するようなプラグイン、あるいは外部システムを活用するようなプラグインを扱う場合には、削除しないほうが良いです。 特に、扱ってる技術が明確でないか、あるいは知識・技術不足で理解できない場合には削除しないほうが良いでしょう。
rsd_link - WordPress.orgwlwmanifest_link
ブログ投稿システム Windows Live Writer 向けのリンクを出力します。Windows Live Writer を使わないなら削除しても良いです。
ウェブブラウザから標準的な投稿しか行わない場合や、WordPress を使った会員制システムを作る場合などには積極的に削除しても良いでしょう。
wlwmanifest_link - WordPress.orgadjacent_posts_rel_link_wp_head
adjacent_posts_rel_link_wp_head 関数は、"次のページ" と "前のページ" を表す link 要素を出力します。
2011 年の Google によれば、 分割されたページ、あるいは同一の内容を示した連続するページのために、prev, next メタデータを参照するとしています。 したがって、この関数によって出力される prev, next と、Google が積極的に理解する prev, next の意味は異なります。
ただし W3C で定義される従来の prev, next は、 単に、連続的な構造を持ったページを示すために用いても良いことになっているので、前後の投稿を示すことは、誤った構文ではありません。 したがって、積極的に削除することもないでしょう。
日記のような、連続した投稿が意味を持つサイトの場合には、特に削除するべきではありません。 一方で、ノウハウなどの情報を提供し、投稿の順序が重要でないサイトの場合には、削除しても良いでしょう。
prev や next は a 要素にも適用することができます。したがって、テンプレートによっては重複することもあるでしょう。 ただし、重複する場合にも、いずれか一方を削除する必要ないと思います。 テンプレートなどで任意に挿入する仕組みを用意している場合には、削除しても良いかもしれません。 また、SEO に関する十分な知識があり、ページの設計方針が定められている場合には、任意に削除しても良いです。
カテゴリページなどで前後のページを表すために rel="next" などを出力する関数ではありません。 出力されているように見える場合、プラグインが出力している可能性があります。 例えば All in One SEO Pack などが、カテゴリページなどで rel="next" を出力します。
locale_stylesheet
locale_stylesheet 関数は、ja.css や en_US.css などのローカル(特定の言語)向けの css や rtl.css を読み込みます。 rtl.css は右から左へ読む言語向けの css です。
特定の言語にローカライズされたテーマファイルや、 ja.css, en_US.css, rtl.css などの、特定の言語向けの CSS が用意されていないテーマファイルでは、この関数を削除しても良いです。
locale_stylesheet - WordPress.orgnoindex
noindex 関数は、[設定] > [表示設定] > [検索エンジンがサイトをインデックスしないようにする]が有効の時、 noindex, follow となる meta 要素を出力します。
関数内部で wp_no_robots
関数を使って meta 要素を出力します。
WordPress サイトを公開した後に、常にサイトをインデックスさせるような場合には、削除することが考えられます。 あるいは、常にサイトをインデックスさせないバイには、テーマファイルのヘッダーに、直接 noindex を記述して、 この関数を削除することが考えられます。
プラグインによって noindex を管理し、指定する場合には削除しても良いかもしれませんが、 プラグインの設定や機能に依存するので、状況に応じた判断が必要です。
テーマを配布するような場合には、ユーザがどのように利用するかわからないので、削除しないほうが良いでしょう。
noindex - WordPress.orgprint_emoji_detection_script
print_emoji_detection_script 関数は、絵文字のためのスクリプトを出力します。絵文字を使わない場合には削除しても良いです。
執筆時現在(2015.06)現在では、絵文字のために、絵文字のデータ、CSS、スクリプトを読み込む必要があります。 したがって、絵文字を使わない場合にはこの関数を積極的に削除しても良いでしょう。 ページの読み込み速度を改善が期待できます。
print_emoji_detection_script - WordPress.orgwp_print_styles
wp_print_styles 関数は wp_print_styles アクションを実行します。 wp_print_styles アクションにフックされた関数を実行して css を読み込みます。 この関数は 3.3 以降の Wordpress で非推奨です。
wp_print_styles 関数の代わりに、wp_enqueue_scripts 関数(アクションフック)を使うべきとされています。 wp_enqueue_scripts 関数は wp_head アクションフックしています。
wp_print_styles 関数のフックは、互換のために維持されているものだと思われます。 wp_print_styles アクションフックを使う比較的古いプラグインが存在しなければ削除しても良いです。
wp_print_styles - WordPress.orgwp_print_head_scripts
wp_print_head_scripts 関数は、 wp_print_scripts アクションを実行します。 wp_print_scripts アクションにフックされた関数を実行して、ヘッダにスクリプトなどを読み込みます。
この関数を削除すると、wp_print_scripts アクションフックを使うプラグインが動作しなくなります。 したがって、削除しないほうが良いでしょう。
wp_print_head_scripts - WordPress.org wp_print_scripts - WordPress.orgwp_generator
wp_generator 関数は、Generator メタ情報を出力します。Generator の情報は、多くの場合に削除してよいです。
Generator は検索エンジンなどに対しても強い影響力を持たないでしょう。 WordPress では、すべてのページに出力されますから、 この関数を削除することは、ページの表示速度を改善することにつながるでしょう。
wp_generator - WordPress.orgrel_canonical
rel_canonical 関数は、投稿・固定・添付ファイルのページで rel="canonical"
メタ情報を出力します。
rel="canonical"
は重複するページが存在する際に、優先するべきページや URL を示すメタ情報です。
内容が著しく重複するページや URL が存在しないとき、rel="canonical" は意味を持ちません。
しかしながら、見かけ上に重複するページが存在しない場合にも、基本的には削除しないほうが良いでしょう。 WordPress は同じページを異なる URL で出力する可能性があります。
例えば、投稿画面の http://DOMAIN/POST-NAME
なる URL を示す投稿が、短縮された URL http://DOMAIN/?p=123
を持つとします。
検索エンジンに走査されるとき、2 つの URL は同じ内容を持った別のページと判定されます。
rel="canonical" が存在すれば、検索エンジンは http://DOMAIN/POST-NAME
をインデックスして、コンテンツの重複を無視します。
短縮された URL の他にも、複数の URL が存在する可能性があります。 複数のカテゴリが設定された投稿に対し、階層的な URL をパンくずリストなどを設定する場合です。 "PARENT-A > CHILD-A > POST" と "PARENT-B > POST" の関係などです。
rel_canonical 関数を削除し、短縮 URL を使わない場合には、rel="shortlink" の出力も停止する必要があります。 wp_head アクションにフックされた wp_shortlink_wp_head 関数を削除します。
rel_canonical - WordPress.orgwp_shortlink_wp_head
wp_shortlink_wp_head 関数は、短い URL を示したメタデータを出力します。
rel="shortlink"
は microformats の仕様です。
HTML5 においては、link 要素の rel 属性は、その値が限定されています。
したがって、HTML5 の構文に違反するメタデータを出力することになります。
多くの場合に、短縮された URL が重要視されることはありません。 特に短縮された URL を必要とするシステムがない限り、この関数は削除しても良いでしょう。
また、特に HTML5 でコーディングされたテーマの場合には、構文に違反するので、削除しても良いでしょう。
wp_shortlink_wp_head - WordPress.orgwp_no_robots
wp_no_robots 関数は、noindex, follow メタデータを出力します。 noindex, follow はページをインデックスしないようにしますが、ページ内のリンクは辿ってほしい時に設定します。
WordPress のバージョン 4.2 の時点では次のコードのように実装されています。 URL がコメントへの返信のパラメータ (replytocom) を含んでいるとき、wp_no_robots が追加されます。
対象の WordPress が将来コメントの機能を使わないのであれば削除してよいです。 一方で、一部のページでもコメントを使う場合には削除しないほうが良いでしょう。
replytocom パラメータが与えられた URL は Google にインデックスされないほうが良いです。 コメントの返信向けの URL ですから、実質的には、ページ内容が重複するためです。 rel="canonical" を出力することで解決できると思うのですが、