Scribble at 2020-07-02 13:33:30 Last modified: 2020-07-05 13:56:30

昨日、オンラインでの相談に対応している個人事業主さんを紹介する自社サイトをひっそりと公開した。仕様について、事前に幾つかの点を公開してからの課題として残していたのだが、ひとまず現状で公開に漕ぎ着けたので、課題を検討しておきたい。

恐らく最も大きな課題は、表示するデータ(紹介する個人事業主)が増えていったときにページの読み込みサイズが増加していくということにある。公開直後の現状でも、合計で250名を超える人物の掲載データを1ページに最初から全て出力して、それを JavaScript で少しずつ表示していく体裁としている。HTML ファイルだけで 1 MB あり、画像ファイルなどを合計すると1ページ全体のリソースで 15 MB もある。これはいかにも大きい。もちろん、最初に表示するべき個数のデータだけを出力しておいて、必要に応じて順番にデータや画像ファイルを読み込むように書き直したいところだが、WordPress を使っているため、どこかに固定の「次ページ用 HTML」があるわけではないし、この個人事業主のリストはアクセスするたびにランダムに並びを変えてほしいというのが与件だったので、そもそも固定のコンテンツを置けない。すると、そういう後続のコンテンツを固定のページへの呼び出しによって実現するのであれ、あるいは JavaScript で動的に読み込むのであれ、その都度で WordPress の関数を呼び出す、つまりは DBMS へのクエリを投げることになる。これはこれで、そうする負荷も考慮しなくてはならない。

いまのところ、他のファイルやページとして後続コンテンツを出力しておくという方法は採用しない。他のページに分割すると、そこでも動的にコンテンツを読み込むのだから、既に表示させているデータとの重複を避けるために「それまでに出力した個人事業主の ID」を配列として渡さなくてはならず、そういうデータの管理方法を組み込む方が面倒だからだ。それなら、寧ろ1ページで完結させる方針はそのままとして、HTML のソースが肥大化するのを避けるために、まずはランダムに並べ替えた ID のリストを定義しておき、後続する内容を表示するときに必要なデータはマークアップごと生成してしまう方がよいだろう。

[2020-07-05 追記] もちろん、そもそもなんでこんなことを悩まなくてはいけないのか、という根本的な仕様の制約を問うことはできる。SPA のような体裁ではなく、pagination で次のページを読み込むようにしてしまえば、上記のごとく無駄に JavaScript を使う必要など何もない。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook