NarutopediaのParserSpeedページ
ParserSpeedは、ページのレンダリングにかかる時間を一覧で確認することができる管理者専用のツールで、 特別:ParserSpeedからアクセスすることができます。
画像やテンプレートがたくさん含まれている長い記事は、短い記事に比べてレンダリングにかかる時間が長くなります。 このツールを使えば、レンダリング時間が長いコミュニティ上のページを見つけて、その原因に関する詳細情報を確認することができます。
ページの読み込みが遅い原因を突き止めることが、この問題を改善するための第一歩です。 記事の構文解析が速いことは、編集者、訪問者、そしてFandomのサーバーにとっても大きなメリットとなります。
ページの読み込み速度が重要な理由[]
インターネット上では、 スピードが速いことが 重要です。ウェブサイトの読み込みに通常より1秒長くかかるだけでも、大分イライラさせられてしまうものです。 ページの読み込み時間が長いと、ウェブサイトに対する印象が大きく変わります。 ウェブサイトに対する印象に及ぼす影響を、次の3つに分けて考えてみましょう。
- ユーザー・エクスペリエンス
- ページの読み込み速度は、ウェブサイト全体に対するユーザーの印象に影響します。 多くのユーザーは検索結果からウェブサイトにアクセスするため、サイトに対する第一印象は最初にアクセスしたページから得ることになります。 そのページの読み込みが遅ければ、訪問中のコミュニティのすべてのページも遅いものと考えるでしょう。 一度こうした印象を持たれるとそれを変えることは難しいため、ページをできるだけ速くすることでこうしたリスクを減らすようにしましょう。
- ユーザーに与える印象
- これは、ユーザーがサイトで操作を数回行った後に、そのサイトについてどのように感じるかです。 ユーザー・エクスペリエンスと同様に、ユーザーがサイトに対して長期間良い印象を持っていれば、価値あるコンテンツのために読み込みの遅さを受け入れる可能性もあります。 ただし、ユーザーがサイトの遅さを完全に無視できるようになるには、コンテンツの独創性と価値が非常に高い必要があります。 もしユーザーが速度とコンテンツのバランスを考慮したうえでより魅力的なサイトを見つけた場合は、 そちらのサイトへの信頼性の方が高くなってしまうでしょう。
- 技術的な印象
- Googleでは、サイトの表示速度を検索ランキングのアルゴリズムに組み込んでいます。 そのためにも、コミュニティでは、ユーザーがGoogle経由で訪れるページ内の情報量の豊富さと、その豊富な情報量が影響するページの読み込み速度およびそれによるページランクの下降度の間のバランスを保つようにすることが不可欠です。 たとえば、検索ランキングで5位のコミュニティのページに上位4件のページよりも有益なコンテンツが含まれていたとしても、ユーザーは最初の4件の結果を見て、コミュニティのページにたどり着く前に探している情報はないとあきらめるか、それ以上の情報は見つからないものと考えてしまうでしょう。
ParserSpeedのデータ[]
ParserSpeedには、サーバでWikiテキストをレンダリングした記事に変換する処理（ページの「構文解析」）にかかる時間順にコミュニティのページが一覧表示されます。 構文解析が行われるのはページに変更があったかキャッシュが期限切れになったときのみなので、構文解析にかかる時間とページの読み込みにかかる時間は多少異なります。
- 平均 構文解析速度、最低 構文解析速度、最高 構文解析速度
- 過去30日間のデータをもとに、構文解析にかかった時間の平均、最小、最大の値が表示されます。
- Wikiテキスト・サイズとHTMLサイズ
- 記事の基本的なWikiテキストと現在のレンダリングされたHTMLのサイズがキロバイト（KB）で示されます。 テンプレートでは、ごくわずかな量のWikiテキストでも大量のHTMLになります。
- 高負荷 構文解析関数
- ページで負荷の高いパーサー関数が使用される回数です。
- 定められている上限は100回です。
- 詳しくは、下記とWikipediaの「高負荷構文解析関数使用回数」のセクションをご覧ください。
- 「ノード数」（プリプロセッサ・ノード数）
- 公開済みのHTMLの複雑性にほぼ関連する、ページの複雑性を示します。
- 定められている上限は1,000,000です。
- 詳しくは、Wikipediaの「プリプロセッサ・ノード数」のセクションをご覧ください。
- 展開後読み込み量
- テンプレートやパーサー関数などによって生成される展開後のWikiテキストの長さの合計が計算されます。
- 定められている上限は2,097,152バイトです。
- 詳しくは、Wikipediaの「展開後読み込み量」のセクションをご覧ください。
- テンプレート引数 量
- 代入されるテンプレート引数の長さの合計が計算されます。
- 定められている上限は2,097,152バイトです。
- 詳しくは、Wikipediaの「テンプレート引数量」のセクションをご覧ください。
改善する方法[]
構文解析にかかる時間とページの複雑性を軽減するには、複数の方法があります。
- ページを簡素化する
- 長いページは複数の短いページに分割しましょう。パフォーマンス上の利点に加えて、訪問者が小さい画面を使用している場合や接続が遅い場合でもより快適にページを閲覧できる可能性があります。
- 個々の記事に長いリストや大量のデータを含めすぎないようにしましょう。
- テンプレートを簡素化する
- テンプレートをネスト化しすぎること（テンプレート内にテンプレートを含め、またその中にテンプレートを含めるような 「Inceplates」）は避けましょう。
- テンプレートを一般化しすぎないようにしましょう。テンプレートに不適切で複雑な機能が多くなりすぎる原因になります。 パラメータは必要なものだけを使用するようにし、ハードコード化は適度に行いましょう。
- テンプレートの数は控え目にしましょう。
- 負荷の高い操作は避ける
- 一部の関数は、データベースでのキャッシュ不可能なクエリの実行を伴うため、レンダリングにおける技術的な負荷が高いと見なされています。 そうした関数には、
{{#ifexist:}}、{{PAGESINCATEGORY}}、{{PAGESIZE}}があります。可能な場合は避けるようにしましょう。 - DPL（ダイナミック・ページ・リスト）を使用する必要がある場合は、あまり複雑化しないようにし、 常にDPLのキャッシュを使用するようにしましょう。 情報テーブルがきわめて静的な場合は、クエリによってページを遅くする代わりに、手動でページをコード化することもご検討ください。
- Luaテンプレートを使用すると、通常のテンプレートで同じ関数を実行するよりも速度を大幅に改善できます。
- 複雑なMediaWiki名前空間のメッセージを作成しない
- MediaWikiのメッセージはたくさんのページで読み込まれる可能性があるため、パーサー関数やテンプレートの呼び出しにはMediaWiki名前空間を使用しないようにしましょう。 名前空間は複雑化しないことをおすすめします。
その他のヘルプとフィードバック[]
- ヘルプ:コンテンツでは、他のヘルプページを閲覧、検索することができます。
- 最新の情報やヘルプについては、コミュニティセントラルをご覧ください。
- この記事で不明確な点や、曖昧な点がございましたら、Fandomとの連絡方法をご確認ください。
- このヘルプはコミュニティセントラル内にて管理されています。