先日 gatsby-plugin-guess-js を
Guess.js に ついて
gatsby-plugin-guess-js を
guess-webpack の インストール、 設定
- インストール
npm でインストールします。
npm install guess-webpack --save-dev
- webpack.config.js の
修正
webpack.config.js に
new GuessPlugin({ GA: '10xxxxxxx' })
の'10xxxxxxx'
には、
const GuessPlugin = require('guess-webpack'); ... new Webpack.ProvidePlugin({ $: 'jquery', jQuery: 'jquery' }), new GuessPlugin({ GA: '10xxxxxxx' }),
- ビルド、
Google の アカウントで 認証を 通す
以下で、webpack を ビルドします。
ビルド時には、gatsby-plugin-guess-js を 使う | Monotalk と 同じように、 Google の アカウントで 認証を 通す 必要が あります。
npm run-script build
JavaScript で guess 関数を 呼び出して、 ページの 先読みを 行う
import 文の
追加 import { guess } from 'guess-webpack/api';
prefetch 関数
head にlink prefetch を 挿入する 関数を 作成しました。 function prefetch(url) { var hint = document.createElement('link'); hint.rel = 'prefetch'; hint.href = url; hint.as = 'html'; hint.crossorigin = 'use-credentials'; document.head.appendChild(hint); }
ページごとに、
prefetch を 呼び出す。
下記のようなコードを、 ページ毎に 1度呼び 出される 箇所に 実装しました。
引数なしで guess 関数を実行すると、 現在の ページからの アクセス数が 多い url が 返ります。 このif (typeof window !== 'undefined') { for (const url of Object.keys(guess())) { prefetch(url); } }
ブログの JavaScript だと、 pageConfigurator.js
がページごとに 1度呼び 出されているので、 その 中に 上記の コードを 実装しています。
mezzanine-theme-clean-blog/pageConfigurator.js at master · kemsakurai/mezzanine-theme-clean-blog
guess 関数の 使い方に ついて
以下、
デプロイ後に、JSON.stringify(__GUESS__.guess());
を
JSON.stringify(__GUESS__.guess());
{ "/":{ "probability":0.167 }, "/blog/Calculate-coefficient-of-variation-with-python-scipy-and-numpy/":{ "probability":0.167 }, "/blog/Calculate-the-geometric-distribution-with-python/":{ "probability":0.167 }, "/blog/cent-os-69-に-memcached-をインストールログの設定まで実施する/":{ "probability":0.167 }, "/blog/python-folium-で都内の公園にまつわる情報を地図上に描画する/":{ "probability":0.167 }, "/blog/pythonで相関係数の計算をする/":{ "probability":0.167 } }
サイトの
guess 関数には
webpack で
Advanced Usage に
動かした 感想
risks の
極度に
サーバリソースを 使う ページ でなければ 積極的に 活用した ほうが いい。
サーバ側負荷がかかる ページの prefetch は 危険かなと 思いますが、 サーバ処理は 軽いが 静的コンテンツが 大きい ページは 積極的に prefetch するのが いいのかなと 思いました。ただ、 ネットワーク帯域使うので 転送量で お金が かかる 場合も あるかもしれません。 古い Web
サイトでも 動くようにできても いいかもしれない。
SPA の登場以前の サイトで 先読みの ために 使用しても いいかもしれません。
Google Analytics のデータを 読み 取って、 JSON を 作成した 後の 処理は 比較的シンプルなので、 自作も できそうです。 ここに
いくまでに、 もっと やるべきことが ある 場合も ある
実業務では、Cache ミドルウェアの 導入、 サーバ側プログラムの 処理速度の 改善等、 Guess.js 導入前に やることがたくさんありそうにも 思います。 ログイン、
末ログイン 等で ページの 表示が 切り替わる ページにはなんらかの 対策が 必要
prefetch でHTML の 先読みを 実施するので ログイン、 末ログインで 表示が 切り替わる 場合は、 Cache を 削除する。
そもそも prefetch させないなどの 対策が 必要かと 思います。
ログイン、末ログインが 表示に 影響が ないような サイトで 使うのが よさそうに 思います。 別の
アルゴリズムでの ページ先読みを 試してみたい
relevant-prediction-models にマルコフモデルを 使う、 クラスタリングを 使う 方式の 説明が 記載されています。 Python あたりで 実装できそうに 思うので そのうち試してみたいと 思いました。 ビルドに
時間が かかるようになる
ビルド実行時に、Googleアカウントの 認証が 行われるので、 その 際の 操作が 手動となり ビルドに 時間を 擁します。
また、アプリケーションは リリースしないが Guess.js の 設定ファイルだけを 更新したいと いう ケースも あるかと 思います。
guess/experiments/guess-static-sites at master · guess-js/guess を見る 限りは サービスアカウントの 認証も できそうで、 仕事で 使うなら スケジューラから 実行等して 定期的に 更新できるようにしたいと 思いました。
参考
以下、
以上です。
コメント