フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング
去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。
SPA を GitHub Actions でビルドして GitHub Pages にデプロイする - 30歳からのプログラミング
デプロイの自動化と History API のフォールバック設定を行うことで、GitHub Pages で SPA を公開できるようにする。 具体的なゴールは以下の通り。 masterブランチにプッシュすると、自動的にビルドが行われる ビルドした内容が GitHub Pages として公開される History API のフォールバックが設定されており、SPA として問題なく機能する 以下がサンプルコード。 github.com 上記のリポジトリによって公開されたページ。内容はない。 https://numb86.github.io/spa-sample/ なお、この記事では SPA の作り方そのものは扱わない。 ビルド用のコマンドを用意し、ビルドの出力先を決める サンプルコードでは、$ yarn buildでビルドし、その結果をpublic/に出力するようにしている。 public/の内
webpack@4 で出力するファイルをリビジョン管理する - 30歳からのプログラミング
ここでいうリビジョン管理とは、JavaScriptファイルやスタイルシートのファイル名に、ハッシュ値などのユニークな値（リビジョン）を付与すること。 そうすることで、ブラウザが古いファイルのキャッシュを利用してしまい変更が反映されない、という事態を回避できる。 手動でファイル名を更新することも可能ではあるが、ビルドの際に自動的に付与されるようにするのが一般的。 ここでは、webpackのv4でリビジョンを付与する方法を書いていく。 この記事で出てくるライブラリについては以下のバージョンで動作確認している。 webpack@4.23.1 webpack-cli@3.1.2 html-webpack-plugin@3.2.0 css-loader@1.0.1 mini-css-extract-plugin@0.4.4 clean-webpack-plugin@0.1.19 出力するファイルにハ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
