コンテンツにスキップ 
私はプラグインを使わず、手動でワードプレスのスピードを最適化することで、読み込み時間を目に見えて短縮し、コアとなるウェブバイタルを確実にヒットさせます。こうして私は リクエスト資源と副作用を排除し、バラストを発生源から取り除く。
中心点
- 絵 アップロード前に一貫して圧縮し、WebP形式に変換する
- レイジーローディング オーバーロードされた拡張機能ではなく、HTML属性によってネイティブに定義される。
- キャッシング .htaccess/serverおよびクリーンヘッダ戦略経由
- コード レンダーブロッカーを最小化、バンドル、回避する
- バラスト ワードプレス、データベース、テーマを削除
プラグインなしで最適化する理由
プラグインは便利なように見えますが、リクエストやスクリプト、スタイルを追加するので、最初のレンダーパスがブロックされ、私の TTFB が悪化する。依存関係が増えるごとにエラー表面も増え、パフォーマンス低下の原因を分析するのが難しくなる。私は手作業で負荷の連鎖を減らし、アクティブなコンポーネントの数を最小限にする対策を行っている。これによってオーバーヘッドを減らし、柔軟性を保ち、新しい要求に素早く対応できるようになる。このアプローチは、アップデート・チェーンによる副作用を防ぎ、メンテナンスを最小限に抑える。 スリム.
画像をスリムに：フォーマット、サイズ、圧縮
大きな画像は1バイトあたりの転送時間は短くならないが、転送時間とLCPを支配する。 前もって.写真はJPEGかWebPで書き出し、PNGは実際の透過画像にのみ使用しています。800pxで十分なのに4000pxを読み込むのではなく、必要なビューポート幅に正確にサイズを合わせています。その後、Squoosh、ImageOptim、またはPhotoshopで一貫して圧縮し、目に見えるアーティファクトがないかチェックします。レスポンシブバリアントの場合、私はsrcset/sizesに依存し、次の短いものを使用するのが好きです。 レスポンシブ画像ガイドブラウザが自動的に最も小さい意味のあるソースをロードするように。 データ転送 が減少する。
ネイティブで遅延ロードを使用する
私は、画像やiFrameがビューポートに入ってきたときだけ、HTML5経由でネイティブに読み込むようにしている。 本スレッド をロードします。モダンブラウザでは、loading="lazy "属性で十分です。このようにして、初期バイト数を減らし、重要なレンダリングフェーズを均等にします。同時に、コントロールは透過的なままであり、どの折り返しより上の要素を意図的にeagerlyにロードするかを決めることができます。クリティカルなヒーロー画像はloading="eager "とし、それ以外はすべて読み込みます。 オフセット.
<img src="beispiel.jpg" alt="画像例" loading="lazy">
<iframe src="video.html" title="ビデオ" loading="lazy"></iframe>目標を定めてLCPを加速させる：優先順位とプレースホルダー
Largest Contentful Paintの安定性を向上させるため、私は最大の折り畳み要素を明示的にマークしています。画像にはfetchpriority="high "を与え、寸法を定義することで、ブラウザが優先的に表示するようにしています。 CLS を避ける。必要であれば、パスが明確であればプリロードを加える。
<!-- LCP-Image priorisieren -->
<link rel="preload" as="image" href="/assets/hero.webp" imagesrcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w" imagesizes="(min-width: 800px) 1200px, 100vw">
<img src="/assets/hero-800.webp"
srcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w"
sizes="(min-width: 800px) 1200px, 100vw"
width="1200" height="700"
fetchpriority="high"
loading="eager"
decoding="async"
alt="ヒーロー">画像とコンテナには、幅と高さを設定するか アスペクト比を使ってレイアウトジャンプを除外する。クリティカルでないエリアには コンテンツ可視性：自動 そして コンテント・イントリンシック・サイズブラウザがレイアウトを移動せずにビューポート外の領域を後でレンダリングするように。
/* 折りたたみより上の部分を予約 */
.hero { アスペクト比: 12 / 7; }.
/* 非可視セクションは後でレイアウトする */
.section { content-visibility: auto; contain-intrinsic-size: 1000px; }.
ブラウザのキャッシュを特別に設定する
定期的な訪問者は、キャッシュから静的アセットをロードするはずなので、有効期限をサーバーレベルで直接設定します。 htaccess またはvHostにあります。画像には長いTTLを、CSS/JSには適度なTTLを、HTMLには短いデフォルトを設定することで、適時性とスピードのバランスをとっています。長いTTLにもかかわらず、アップデートがすぐに反映されるように、一貫したファイルのバージョニングに注意を払っています。ETagsやLast-Modifiedヘッダーと組み合わせることで、トラフィックは劇的に減少する。これによって帯域幅が節約され、TTLを短く感じることができます。 ローディング時間.
ExpiresActive On
ExpiresByType image/jpg "アクセスプラス 1 年"
ExpiresByType image/jpeg "アクセスプラス一年"
ExpiresByType image/gif "アクセス＋1年"
ExpiresByType image/png "アクセスプラス1年"
ExpiresByType text/css "アクセス+1ヶ月"
ExpiresByType application/pdf "アクセス+1ヶ月"
ExpiresByType text/javascript "アクセスプラス1ヶ月"
ExpiresByType application/x-javascript "アクセスプラス1ヶ月"
ExpiresDefault "アクセスプラス2日"キャッシュ戦略、バージョニング、再検証
私は長いTTLとファイル名のハッシュを組み合わせて、クライアントが同じ時間キャッシュするようにしている (スタイル.9c2a.css)、アップデートは即座に反映される。頻繁に変更されるバンドルには キャッシュ制御: public, max-age=31536000, immutableHTMLショート キャッシュなし-戦略。ダイナミックな回答には 条件付きリクエスト 経由 イータグ 或いは 最終更新日クライアントの再バリデーションが控えめになるように：
の場合
ヘッダーセット Cache-Control "public, max-age=31536000, immutable"
</ファイルマッチ
ヘッダーセット Cache-Control "no-cache, no-store, must-revalidate"
</IfModuleフォーマットが異なるコンテンツ（例えば、WebPとJPEGなど）については、私は以下をチェックする。 値: Accept これは、間違ったバージョンがキャッシュに残ってしまうのを防ぐためです。私はビルドパイプラインによってバージョン管理を一貫させているので、アセットが無秩序に古くなることはありません。
CSSとJavaScriptの効率化
私はビルドプロセスでCSS/JSをローカルに最小化し、コメント、スペース、および未使用のものを削除します。 セレクタ.重要なスタイルはインラインで、それ以外は非同期またはディファード・ファイルとして読み込みます。レンダリングをブロックするスクリプトは最後に移動させ、defer/asyncを追加し、外部ライブラリの数を少なくする。フレームワークの場合は、ツリーの揺れとインポートスコープをチェックして、めったに使わないものをすべて読み込まないようにする。可能であれば、バックエンドをキャッシュせずにリクエストを減らすためにファイルをバンドルする。 悪くなる.
INPを改善する：メインスレッドの緩和
次のペイントまでのインタラクションを少なくするために、私は長いタスクを小さく分割し、レイアウトの乱れを避け、複雑なハンドラをインタラクションから切り離す。私は 持ち越す モジュールにパッシブ・イベント・リスナーを設定し、アイドル時にクリティカルでない作業をスケジュールする：
.
document.addEventListener('touchstart', onTouch, { passive: true })；
const expensiveInit = () => { /* ...*/ };
requestIdleCallback(expensiveInit, { timeout: 1500 })；
// 長いタスクを分割する
function chunkedWork(items) {
const batch = items.splice(0, 50)；
// 処理...
if (items.length) requestAnimationFrame(() => chunkedWork(items))；
}DevToolsで長いタスクを計測し、重複するライブラリを削除し、jQueryユーティリティをネイティブAPIに置き換える。DOMの更新を要約し 変える の代わりに 上/左 そしてリフローを最小限に抑える。
ワードプレスのバラストを取り除く
生産的なサイトではWPの機能はあまり必要ないので、絵文字やoEmbeds、REST APIの一部を無効にしてお金を節約しています。 リクエスト.これによってヘッドが縮小され、ファースト・ペイントをブロックするスクリプトが少なくなる。また、ピンバック、RSDリンク、WLWマニフェストをチェックし、それらをオフにします。トラックバックとXML-RPCも、役割を果たさないならオフにします。このようにして、攻撃対象を減らし、開始段階を維持します。 ライト.
// 絵文字を無効にする
remove_action( 'wp_head', 'print_emoji_detection_script', 7 )；
remove_action( 'wp_print_styles', 'print_emoji_styles' )；
// oEmbedsとREST APIを減らす
remove_action( 'wp_head', 'wp_oembed_add_host_js' )；
add_filter('rest_enabled', '_return_false')；
add_filter('rest_jsonp_enabled', '_return_false')；サードパーティ製スクリプトを飼いならす
サードパーティのコードは、しばしば最大のブレーキパッドとなる。私は、サードパーティのコードを遅延させて初期化し、絶対に必要なものだけを組み込み、インタラクションや同意の後にのみ読み込むようにしている。分析／トラッキングが来る 非同期 最初のペイントの後、ソーシャルウィジェットを静的リンクに置き換える。iFrameには loading="lazy" そして サンドボックスを使用して副作用を制限しています。YouTubeの埋め込みはプレビュー画像を受信し、クリックされたときのみプレーヤーをロードします。
ヘルパーを使わないデータベース・メンテナンス
余計なリビジョンを削除し、トランジェントを空にし、phpMyAdminでスパムコメントをクリーンアップして、クエリを高速化しています。 回答.オートロードされたオプションのサイズが大きすぎないかチェックします。小規模なインストレーションでは、テーブルを最適化するのに数個のSQLステートメントで十分です。cronジョブがハングアップしていないかチェックし、古いプラグインが残したpostmetaを整理する。定期的なメンテナンスは、クエリが手に負えなくなるのを防ぎ、バックエンドが乱雑になるのを防ぎます。 低調 の意思表示をします。
WP Cronの代わりにシステムCron
cronジョブを確実かつ効率的に実行するために、私はページロードから切り離しています。私はWP-Cronを非アクティブにし、静かな時間に働く実際のシステムジョブをスケジュールします。
// wp-config.phpで
define('DISABLE_WP_CRON', true)；# crontab -e (5分毎)
*/5 * * * /usr/bin/php -q /path/to/wp/wp-cron.php >/dev/null 2>&1これは、cronが通常のリクエストのレスポンスタイムをブロックすることがなく、一時的なクリーンアップやサイトマップ生成のような定期的なタスクをスケジュールできることを意味します。
テーマ、プラグイン、フォントのチェック
非アクティブなテーマや、機能が重複していたり、ほとんどメリットをもたらさない拡張機能はすべて削除します。 オートローダー のロードが少なくなります。フォントについては、バリアントをレギュラー／ボールドと2つのフォントスタイルに減らし、それらをローカルでホストし、メインファイルのプリロードを有効にしています。本当に必要であれば、DNSプリフェッチで外部リソースを準備する。YouTubeへの埋め込みは、サムネイルを使って後でiFrameを初期化します。こうすることで、レンダリングパスを制御し、開始ペイロードを維持することができます。 小さい.
を参照してください。フォント：ロードの動作、サブセット、フォールバック
ウェブフォントは知覚速度に強く影響する。私は フォント表示：スワップ 或いは 任意テキストがすぐに見えるように。私は可変フォントを厳密にチェックし、バイトを節約するためにユニコード領域をサブセットします。最も重要なWOFF2ファイルをターゲットとしてプリロードすることで、FOITを減らすことができます。
フォント・フェイス
font-family: 'Brand'；
src: url('/fonts/brand-regular.woff2') format('woff2')；
font-weight: 400；
font-style: normal；
font-display: swap；
unicode-range: U+000-5FF; /* ラテン文字ベースセット */
}レイアウトのジャンプを最小限に抑えるため、フォントスタックにきれいなシステムフォールバック（Segoe UI、Roboto、SF Pro、Arialなど）を定義しています。フォントについて サイズアジャスト 私は、フォールバックフォントからウェブフォントへの変化がほとんど見えないように、メートル差を調整している。
サーバー、PHP、プロトコル
適切なインフラストラクチャーがなければ、どんな最適化も失敗する。 ピーエッチピーエス-バージョンとHTTP/2のサポート。OPcache、Brotli/Gzip、HTTP/2の多重化は、配信をスピードアップし、ブロックを減らす。可能であれば、私はHTTP/3/QUICを検討し、セットアップとTLS設定を注意深くチェックする。 HTTP/3の実装.負荷テストとストレステストは、負荷がかかったときにページがどのように反応するかを示してくれる。これが、私のスタックがアプリケーションをサポートしていることを確認する方法だ。 運ぶ 私の対策は効果的だ。
| ホスティングプロバイダー | 特徴 | パフォーマンス | サポート | 価格性能比 |
|---|---|---|---|---|
| webhoster.de | SSD、PHP 8.*、http/2 | ★★★★★ | ★★★★★ | ★★★★★ |
| 競技者1 | SSD、PHP 7.*、http/2 | ★★★★☆ | ★★★★☆ | ★★★★☆ |
| 競技者2 | HDD、PHP 7.*、HTTP/2なし | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
PHP-FPM、OPcache、トランスポートの最適化
PHP-FPMを設定して、リクエストがキューに終わらないようにした。 午後, pm.max_children そして pm.max_requests 私はロードに次元を合わせる。OPcacheは再コンパイルを避けるために十分なメモリを確保する。
php.ini / www.conf
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
PHP-FPM (値の例)
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500トランスポートレイヤーでは、Gzipの前にBrotliを有効にし、Keep-Aliveをオープンにしておき、TLSの再開をチェックする。HTTP/2では、CSS/フォントとLCP画像が優先されるように優先順位をチェックする。HTTP/3では、パケットロスを監視し、ペーシングを調整する。
CDN、キャッシュヘッダ、地理
海外からのトラフィックに対しては、エッジネットワークを使ってレイテンシーを減らし、静的アセットをユーザーの近くに置いている。 配信する.クリーンなキャッシュキー、バリアントヘッダー（WebP用など）、一貫したバージョニングに注意を払っています。重要なHTMLページは注意深く、APIレスポンスは選択的に、画像は積極的にキャッシュします。簡単な概要 CDNの最適化 二重圧縮のような落とし穴を避けるのに役立っています。こうしてサーバーとエッジのキャッシングを組み合わせ、コストを抑えている。 表示.
エッジでのフォーマット、ネゴシエーション、重複排除
私は最新のフォーマット（WebP、オプションでAVIF）で画像を再生し、CDNがコンテンツ・ネゴシエーションを尊重するようにします。重要なのは、正しい 受け入れる-バリアントとキャッシュキーの一意性。私は一度だけ圧縮することで二重Gzipを避けている（サーバ 或いは Edge)のフラグを解除する。HTMLについては、私は保守的なTTLと強力なETagを設定し、アセットについては積極的にキャッシュしています。
測定、主要数値、優先順位付け
私は明確なパフォーマンス予算からスタートし、ミリ秒単位の値ではなく、LCP、CLS、INPに集中する。 絶縁 を考慮する。フィールドデータはラボの値より高いので、私は実際のユーザーのシグナルとテスト実行を比較する。ウォーターフォール・ダイアグラムはブロックしているアセットを明らかにし、リクエスト・マップは重複したライブラリや不要なフォント・ファイルを示す。各変更を個別に測定し、リグレッションを素早く認識します。数値が一貫して改善された場合にのみ、より広範囲に展開します。 より.
作業方法：クリーンなデプロイ、迅速なロールバック
私はデプロイプロセスにパフォーマンスチェックを組み込んでいます：ビルドはバージョン管理された成果物を生成し、Lighthouse/DevToolsのテストはステージング上で実行され、チェックされたバンドルだけがライブになります。フィーチャーフラグを使うことで、リスクのある変更を制御された方法でロールアウトし、必要であればすぐに無効化することができます。これにより、新しい機能を開発する間、パフォーマンスを安定させることができます。
簡単にまとめると私の導入方法
画像サイズの縮小、レイジーローディングの有効化、重要なCSS部分のインライン化、スクリプトのブロックなどです。 シフト.そして、ブラウザとサーバサイドのキャッシュ戦略を確保し、WordPressの機能とデータベースを整理し、不要なプラグインを削除します。インフラ、HTTP/2/3、Brotli、OPcacheをチェックし、バージョニングでクリーンなデプロイプロセスを保証します。必要に応じてCDNを追加し、ヘッダーとバリアントを調整します。最後に、LCP、CLS、INPが安定したグリーンな状態になるまで、主要な数値を繰り返しチェックします。 地域 嘘だ。
