Leverage Browser Caching | PageSpeed Insights | Google for Developers
Stay organized with collections Save and categorize content based on your preferences. This rule triggers when PageSpeed Insights detects that the response from your server does not include caching headers or if the resources are specified to be cached for only a short time. Overview Fetching resources over the network is both slow and expensive: the download may require multiple roundtrips betwee
さいきんの Rails サービスを高速化をしてみた - 2nd life (移転しました)
先日のももクロハッカソンで出会った wantedly を作ってる仲さんが と言ってたので、面白そうなので wantedly を速くしてみました。 wantedly ちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。 アプリケーションサイドのチューニング 初心者*1にありがちな問題として SQL に適切にインデックス張ってない キャッシュすべき場所をキャッシュしていない 無駄なデータを引きすぎてる ことがよくあります。ので順に実装を見ていきました。 SQLに適切なインデックスを張ってない 張ってありました！びっくり！＼(^o^)／ キャッシュすべき場所をキャッシュしていない Facebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直に HT
ついに出た！Chrome版「Page Speed」の使い方
2011/3/22に、GoogleがようやくGoogle Chrome版「Page Speed」拡張機能を公開しました。 「Page Speed」は、項目をある程度理解できれば自分や自社のサイトの表示速度の改善にとても役立つツールです。 この記事では、「Page Speed」のインストール方法から各調査項目の見方や改善方法を中心に使い方を解説します。 ぜひ、ご自身のサイトの改善に役立てていただければと思います。 そもそも、なぜサイトの表示速度を速くする必要があるのか？ 例えば、Amazonの調査によると「表示速度が0.1秒遅くなると、売上が1％減少する」といい、Googleの調査によると「表示速度が0.5秒遅くなると、検索数が20％減少する」と言われます。 また、GoogleはWebページの読み込み速度をアルゴリズムに取り入れたことを発表しています。 大手サイトや大規模なECサイトに限らず
Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは？(0.1秒未満ぐらいを目指したい？) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu
Impact of the number of idle connections in MySQL (version 2)
All of Percona’s open source software products, in one place, to download as much or as little as you need.
Impact of the number of idle connections in MySQL
All of Percona’s open source software products, in one place, to download as much or as little as you need.
パフォーマンスを求めて - お前の血は何色だ!! 4
結局、わかったことは、 次の4つ。 index から 実体へのシークは遅い。 すべてがindex内で完結するクエリーは早い。 limit をつけても where や order by すると意味がない。 indexを張るなら Using indexe をゲットできないと負けかな。 では、select で取得する値すべてに index を張りますか? 場合によっては可能ですが、テーブルに文字列なんかがふんだんに含まれていると難しいものがあり、現実的ではありません。 そこでこんな方法を提案します。2段階にわけてクエリーを打ちます。 A. task テーブルの 2008/6/5 〜 2008/6/18 のデータを開始日順にならべて、先頭5件だけ表示せよ。 select SQL_CALC_FOUND_ROWS * from task where task.task_starttime <= '20
�Linux/DB Tuning (DevSumi2010, Japanese)
PFN は、「現実世界を計算可能にする」を Vision として，膨大な計算量を必要とするシミュレーションや深層学習などの計算ワークロードを実行するためのオンプレ ML 基盤を持っています。 この発表では、「オンプレクラスタの概要」と最近のトピックとして「新しく構築した「MN-2b」」、「Pod のリソース要求量の最適化を助けるしくみ」、「Kubernetes クラスタのアップグレード」についてお話します。 本イベント「オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜」では、オンプレミスの Kubernetes クラスタ上に構築された機械学習基盤を持つ PFN とヤフーのエンジニアが自社での取り組みについて語り尽くします！ イベントサイト: https://ml-kubernetes.connpass.com/event/255797/
Twitterのクジラ解剖学、あるいは彼らがいかにサーバの処理能力を向上させたか
Twitterを利用していると、ときどきクジラの絵の画面が表示されることがあります。これはTwitterの処理能力がパンクして一時的に利用不可になったときに表示されるお馴染みの画面。 2月9日にTwitter Engineeringブログにポストされたエントリ「The Anatomy of a Whale」（クジラの解剖学）では、Twitterのエンジニアたちがこのクジラの内部に分け入ってどのようにTwitterサーバの処理能力を向上させたのか、という話が詳しく語られています。 彼らが行ったのは、まず詳細なデータを取得して原因がどの辺にあるのかを推測すること。そこから多数の無駄な処理を発見し、ソースコードの修正による性能の向上に成功します。 元記事は非常に長いエントリになっていますが、問題の調査から解決に至るアプローチについて多くのエンジニアの方の参考になりそうな内容が含まれていますし、T
KOSHIGOE学習帳 - [MySQL] パフォーマンス関連メモ
{{toc_here}} InnoDB パフォーマンスチューニング MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.11 InnoDB パフォーマンス チューニング ヒント MySQL :: MySQL 5.1 Reference Manual :: 13.6.13.1 InnoDB Performance Tuning Tips 長過ぎる PRIMARY KEY を避けてディスク領域の無駄遣いを避ける セカンダリインデックス用に余計な領域を使わないよう、長い主キーを避ける 主キーが長い場合、代わりに AUTO_INCREMENT なカラムを主キーとして作成するとよい 補足 MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.13 InnoDB テーブルとインデックス構造 MySQL :: MySQL 5.1 Reference Ma
MySQL Reference Manual for version 3.21.31. - MySQL の最大性能を得る方法は？
MySQL のバッファサイズの変更方法 現在のバッファサイズを次で得ることができます: > ./mysqld --help この結果、全ての mysqld オプションと次のようなコンフィグ可能変数のリスト を得られます。 Possibly variables to option --set-variable (-O) are: back_log current value: 5 join_buffer current value: 131072 key_buffer current value: 1048568 max_allowed_packet current value: 65536 max_connections current value: 90 max_join_size current value: 4294967295 max_sort_length current val
Googleに学ぶ、ウェブページのパフォーマンスを最適化する方法
Web Performance Best Practices 下記、ウェブページのパフォーマンスを最適化するポイントをまとめたものです。 キャッシュの最適化 往復遅延時間を減らす HTTPリクエストを減らす ロードサイズを減らす レンダリングの最適化 関連書籍 1. Optimize caching キャッシュの最適化 ブラウザのキャッシュを活用 JavaScriptやCSSファイルや画像などのスタティックなリソースは、HTTPヘッダを使用してキャッシュをロードするようにします。 アドバイス スタティックなリソースは全て、積極的にキャッシュにセットします。 時々更新するリソースのキャッシュには、ファイルパスにフィンガープリントを埋め込みます。 IEでも確実にキャッシュされるように、Varyヘッダは削除します。 URLを自動生成している場合は、Fxのディスクキャッシュで使用している8文字のラ
はてなブックマークが重い件について、Page Detailerというツールを使って調べてみる - VTuberになったプログラマーの魂の残滓
JavaScriptの部分は というわけでid:amachangに任せましょう。 というわけでそれ以外の部分でいったいどこが重いのか 何が重いの？ということで重たい箇所を分析していきましょう。 IBM PageDetailer 解析ツールとしてIBM PageDtailerを利用します。 alphaWorks Community 解説するよりも見てもらうほうが早いと思うのでさっそく使ってみるよ。 ちなみに上記ソフトのダウンロードにはIBMアカウント（無料）が必要なので、使いたい人は登録しよう！ http://b.hatena.ne.jp/HolyGrail/ の結果 こんな感じのグラフが出てきます。 では、詳細を見てみましょう。 このグラフですが、長い部分が http://b.hatena.ne.jp/HolyGrail/ のHTMLそのもののロード時間になっています。 内訳としては 濃い
Yahoo!ニュース高速化へのサイトデザイン側からのアプローチ
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、Yahoo!ニュースのデザイナーの黒田・由衛です。 Yahoo!ニュースが2009年4月27日にリニューアルしました。今回のリニューアルでは、お客様に快適にサイトを利用していただけるよう最速でページを表示させることに重点をおきました。 お客様がウェブを閲覧するのは1日の中のほんの限られた時間です。その貴重な時間を割いてYahoo!ニュースに来ていただくわけですから、1ページでも多くの記事を「読みやすく」「ストレスなく」見ていただけるようにするのが、Yahoo!ニュースがお客様にできる最高のおもてなしだと考えています。そこで、今回のリニューアルでは、サイトデザイン側からのアプローチとして以下の2点の施策を行いました。 １
ハイエンドNICは実際にどの程度ネットワークスループットを向上させるのか？
ハイエンドNICは実際にどの程度ネットワークスループットを向上させるのか？：Validation Case Study（1/2 ページ） オンボードのNICとデスクトップ用のハイエンドNICはどの程度性能が違うのだろう。幾つかのベンチマークテストを通して、その性能差を検証してみよう。価格にふさわしい性能差はあるのだろうか。 マザーボードに標準で搭載されているギガビットNIC（Network Interface Card）をIntel製ハイエンドデスクトップ用NICに置き換えた場合、具体的にどの程度の機能向上が見込めるのだろう？ 今回わたしは、2つの一般的なマザーボードにオンボードで搭載されたギガビットNICおよび、これらをIntel製PCIeデスクトップ用ギガビットNICに置き換えた場合とを比較対象とし、ネットワークを介したNFS共有アクセスに特化したベンチマークを実行してみた。その結果を
MySQLのベンチマークを用いたIntel X25-M SSDの評価 - SH2の日記
X25-M、SSDで検索してくる方が非常に多いので、本ブログ内のSSD関連記事をリストしておきます。 MySQLのベンチマークを用いたIntel X25-M SSDの評価 (本記事) SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin (2009/09/07) 先週末IntelのSSD、X25-Mが突然7,000円ほど値下がりしたので、ついに我慢できず手を出してしまいました。初めてのSSD導入です。 SSDのベンチマーク記事は国内・海外問わずたくさんありますが、実際にデータベースを乗せて計測した記事はそれほど多くありません。そこで、先日ご紹介したtpcc-mysqlを用いてベンチマークテストを行ってみました。 データベースサーバ OS ： Windows XP SP3 32bit CPU ： Core2 Duo T7300 2.0GHz (EIST OFF)
Webサイトを“速く”表示させる7つの計測ポイント（1/2） - ＠IT
株式会社ライブドア マークアップエンジニア 浜 俊太朗 2009/3/24 FirefoxやYSlowを使ってWebサイトの問題点を探るには？ ライブドアブログを速くした著者が7つのポイントを伝授します（編集部） Webサイトは“見た目”が重要なのは当たり前だが…… 皆さんはWebサイトを作るときに、どのようなことを意識していますか？ デザイナや主にHTMLのコーダー／マークアップエンジニアと呼ばれる職種に就いている人は、やはり“見た目”を強く意識しているのではないでしょうか。 例えば、複数のWebブラウザで同じか近い表示になるようにとか、リリース後の更新業務によって表示崩れが起きないように、などです。もちろんそれは職種の適性として正しいものですが、実はほかにも意識した方がよい重要な要素があるのです。 良い印象を与えるには、“速度”も重要 Webサイトを見たユーザーが、良い印象を受けるのか
大量に同じ画像を表示したいとき - os0x.blog
画像周りの速度メモ - #生存戦略 、それは - subtechの件。 最終手段として、CSSを使う。 .hatenastar{ display:inline-block; width:11px; height:10px; background:url('http://s.hatena.ne.jp/images/star.gif'); } (function(){ var now = new Date*1; for (var i = 0; i < count; i++) { var span = document.createElement('span'); span.className = 'hatenastar'; container.appendChild(span); } document.title += ' css:' + ((new Date*1) - now); })();
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
English (US)
