2025年度 traP新歓オリエンテーションのLTで発表した内容です。5分のLTなので1章のみを話しました。
実践Webフロントパフォーマンスチューニング
2025年度 traP新歓オリエンテーションのLTで発表した内容です。5分のLTなので1章のみを話しました。
JS のビルドサイズを極限まで絞るための TIPS 集
ビルドサイズ限界まで絞りたい人向け。 あらゆる環境で実践するものではないが、知ってたら簡単に避けることができるのもあるので知っておくと便利なTIPS書いていく。 基本ポリシー 未使用コードはビルド時に全部落とす。 何が未使用コードで、何が定数かわかるようなインターフェースを人間が心がける。 用語 Dead Code Ellimination(DCE) Rollup や Terser で、未使用コードを削除すること
【WV.10】WordPress高速化のためのCore Web Vital チェックリスト – Capital P – WordPressメディア
Core Web Vitalに関する連載の最終回ではこれまで紹介してきた内容をチェックリスト形式で紹介しよう。 基礎知識 LCP, FID, CLSなどの指標を理解する。 リソースの配信 画像の次世代配信（webp）ブラウザキャッシュ、GZip圧縮の適用CDNを利用する サーバーの処理速度向上 ページキャッシュの利用キャッシュを利用できない場合のTTFB改善 リソースの読み込み CSSの遅延読み込み（rel=preload）JavasScriptの遅延読み込み（defer/async）srcsetおよびpictureによる画像のサイズ最適化サードパーティーリソースの削除および改善loading=lazyによる画像・iframeの遅延読み込みリソースヒント（preload / preconnect / prefetch / dns-prefetch） 最後に宣伝なのだが、連載で紹介した内容の
WordPress高速化とCore Web Vital対応の基本 – Capital P – WordPressメディア
GoogleはCore Web Vitalと呼ばれる指標を2021年6月中旬から検索エンジンのランキング評価項目として採用することを発表している。この記事を書いている時点で段階的に採用が始まっているはずだ。コンテンツの中身だけではなく、速度もまたユーザーにとって重要な指標だというわけだ。 これにともない、現在WordPress高速化の需要は増えていることだろう。もっと単純化すると、顧客から「Page Speed Insightsで高得点を出せるようにして欲しい」という要望を受けるWordPressコンサルタントも増えているはずだ。本連載ではこうした人たちに向けてWordPressにおけるCore Web Vital対応の基本から応用までを紹介する予定だ。 なお、本連載で紹介する内容は筆者が開発したプレミアムテーマ Side Business をベースにしている。さくらインターネットのレンタ
サイトの表示高速化につながる18のこと｜ベイジの図書館
ベイジでエンジニアをやっている酒井です。 ベイジには2017年に、新卒で入社しました。いつもはJavaScriptの開発からWordPressのカスタマイズなど、フロントエンドを中心としながら、一部バックエンドも含めて仕事をしています。『knowledge / baigie』でも、フロントエンド寄りの情報を発信していきたいと思います。 私の今日のテーマは、表示の高速化についてです。 webサイトの表示スピードは、webサイトのユーザー体験に直結すると私は考えています。表層的なUIデザインの改善以上に重要かつ効果的であることも多いため、webのデザイナーやエンジニアは、0.1秒でも速くなることにこだわるべきでしょう。 表示高速化の手法というと、サーバ側の話になることも多いですが、実はフロントエンド側でできることもたくさんあります。それは大きく3つに分けられます。 ブラウザ処理の高速化通信の高
WordPress でも大丈夫！実例で見るウェブパフォーマンス改善
ウェブパフォーマンス、あるいはウェブページの表示速度は、ウェブサイト品質の重要な指標の1つです。今注目されているウェブパフォーマンス改善ですが、そもそも何をすればいいのか、具体例を交えながらその施策を紹介いたします。具体例としては、WordPress を利用したブログの PageSpeed Insigh…
Webパフォーマンス虎の巻
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、**改善施策ってまず何をどうすればいいの？**という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元： テクニックではなく、今、本気で取り組むべきWebパフォーマンス （html5jパフォーマンス部 部長 竹洞さん） 心得 パフォーマンス向上に対する施策は大別すると以下の２通り 軽量化 （単純にやりとりするデータ容量を小さくすること） 圧縮 削除 最適化 （その時に最も適している実装・実行をとること） 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。
Webフロントエンド パフォーマンス改善ハンドブックを公開しました - dwango on GitHub
パフォーマンス改善ハンドブック ウェブページにおけるパフォーマンスに関する問題の見つけ方や考え方の事例をまとめた Webフロントエンド パフォーマンス改善ハンドブックを公開しました。 URL: https://dwango-js.github.io/performance-handbook/ このハンドブックでは過去に行ったWebフロントエンドのパフォーマンス改善の事例を中心に紹介しています。 注意点としてWebフロントエンドは常に変化しているため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを用い、映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのWebフロントエンドを扱います。 具体的にはニコニコ生放送（以下「生放送」）で行った事例を中心に書かれていま
サイトを37倍に高速化した7つの手法 - オールアバウトTech Blog
今回はオールアバウトのnnmrが弊社サイトAll About Japanの速度を高速化した経緯についてまとめます。 All About Japanとは そもそもAll About Japan（以下AAJ）とは何かといいますと、弊社が提供している訪日外国人向けの日本紹介サイトです。 外国人向けサイトで、英語、中国語（繁体字）、中国語（簡体字）、タイ語、韓国語の5か国語に対応しております。 「Anime」「Izakaya」「Ninja」といったような特集や、実際に観光する人向けのモデルルート記事が特色です。 ■ 特集 (url : http://allabout-japan.com/en/tag/sushi/ ) ■ モデルルート記事 (url : http://allabout-japan.com/en/article/222/ ) 技術的な紹介 LAMP環境です。 （サーバー構成は後に記述
するするさせたい：サイボウズ採用情報のアニメーション（その1） - fragmentary
サイボウズの採用情報ページを見ていた。 サイボウズ | 採用情報（新卒・キャリア） といっても受けるとかではなく、ただ性格悪いことを思っていただけなんだけど。 Kintoneのセクションでアプリっぽいアイコンたちが右から左へと流れているんだけど、それがガタガタとしている。するするしていない。するするさせたい。 というわけで、何が起こっているのかを調べてみようかと。何回かにわけて書くよ。 その1 ― 何が起こっているのか調べる その2 ― 調べながら直しながらするするさせる その3 ― ちょっとしたことや他のブラウザでもするするさせる アニメーションの実装を調べる あとのことを考えて、Chrome DevToolsを使う。 まず、該当の流れるアイコンのところで右クリックしてinspectする。Elementsパネルで、<div class="icon"> という要素がハイライトされる。div
とあるサイトの高速化についてフロントエンドでやったことまとめ。 - Toro_Unit
業務で携わっている案件なのですが、アクセス数の急増が見込まれるイベントがありまして。準備期間も少なく、バックエンド側でできることがほぼないという状況でサイトを落とさないようにがんばる！というお仕事でした。レガシーソースてんこ盛り。CSSプリプロセッサとか何それ状態。 そこで実施した対策のまとめです。サーバー・アプリケーション・サイトの構成によって、効果の大小はありますが、比較的効果があったと思われるものをつらつらと。 リクエストの削減とファイルサイズの最適化 まず一番最初に考えなければいけないのがリクエスト数です。すごいおおざっぱに言うと、WEBサーバー（ApacheとかNginxとか）への負荷は、PV数×リクエスト数です。PVがそんなに無くてもそのページのリクエストがめちゃくちゃ多いとそれだけでかなりの負荷になります。リクエストを半分にできれば2倍の人数がさばけるってことに、すげーおおざ
Webサーバのベンチマークツールはh2loadが便利 - 人間とウェブの未来
Webサーバのベンチマークをとるのが趣味になりつつあるmatsumotoryです。 Webサーバのベンチマークについては、abからはじまりwrk等を使っていたのですが、最近ではほぼh2loadを使っています。 h2loadはnghttp2というHTTP/2ライブラリのアプリケーションに含まれているツールですが、 HTTP/2（SPDYも）とHTTP/1.xに両対応している ベンチマーク側の同時スレッド数を増やせる TLS及びSNIもサポートしている 最小、最大、平均、標準偏差あたりもちゃんとでる ので、色々プロトコルを変えつつ同じベンチマークツールで、値の目安を出すにはとても重宝しています。 Nghttp2: HTTP/2 C Library - nghttp2.org 実行結果のサンプルは例えば以下、 $ h2load -c 100 -n 10000 https://localhost:
スマートフォンWebのフロントエンドを高速化する取り組み - クックパッド開発者ブログ
ユーザファースト推進部の丸山(@h13i32maru)です。 先日「撮るレシピ」というサービスを cookpad.com にて公開しました。「撮るレシピ」というサービスは料理本や雑誌のレシピを写真に撮ってクックパッド上に保存できるというものです。料理本や雑誌でレシピを良く見る方はぜひ使ってみてください(Androidアプリ版もあります)。 この「撮るレシピ」は全体公開前に一部のユーザに限定公開をしていました。そして全体公開をするにあたりフロント側のコードを全面的に書き換え高速化を行いました。その結果、最大で30倍高速化することができユーザの使い勝手が向上しました。以下が「書き換え前」と「書き換え後」の計測結果です(Android端末8機種 + iOS3機種で各操作のターンアラウンド時間*1を計測)。 閲覧系 最大: 30倍高速化(4.2秒→0.14秒) 平均: 15.7倍高速化(3.6秒→
『フロントチューニンガソン 最速を目指すには』
11:10～ 課題ページの確認＆PageSpeed Insightsの実行目的：チューニング対象のウェブサイトの改善の余地を調査 上記のgruntプラグインをインストールする npm install コマンドを実行しながら、ブラウザやIDEでチューニング対象のウェブサイトを確認し始めました。 少し見ただけでもCSSの構文エラーがあったり、使っていないJavaScriptライブラリがインポートされていたり…。 まるで無茶な運用を数ヶ月続けたかのような、カオスなファイル群でした。 ここで実行した PageSpeed Insights に画像サイズの最適化をオススメされたので、まずはそこから行うことにしました。 11:20～ 画像ファイルの最適化目的：画像ファイルサイズの削減 30 x 30pxで表示している画像ファイルが実際には150 x 150pxで保存されていたりする画像がそこそこあったの
不特定多数の人が更新する大規模サイトに必要な CSS 設計の思想
今話題（？）の CSS 設計のメモ。 この「ある程度の規模」というのは、肌感覚としてテンプレートの枚数( ≠ Webサイトのページ総数)が 20P〜50P くらいのイメージ。 また、コーディング完了後に自分以外の人間による断続的な更新が入るという前提。 そして一番重要なのは「更新する人のスキルは定義しない。」ということ。つまり HTML の知識が乏しい人が更新する可能性があることを前提とする。 きっと1ヶ月くらいすれば変わると思うけど、自分の思想のログとして残しておく。 今ぼくは以下のことに気をつけながら CSS を書いている。 コードが長くなることを気にしない セレクタが長くなることを気にしない セマンティクスの実現の難しさを理解し、妥協する 再利用性より保守性 拡張しやすい設計 最初から最適化しようとしない ゴールは目先のパフォーマンス向上ではなく誰が触っても問題が起きにくい設計 ひと
Webフロントエンドパフォーマンスチューニング
Webフロントエンドのパフォーマンスチューニングについて全体的な話。javascript、Chrome DevToolsの紹介、ボトルネック、ポイントなど。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ウェブパフォーマンスの基礎とこれから