Autoptimize

説明

Autoptimize makes optimizing your site really easy. It can aggregate, minify and cache scripts and styles, injects CSS in the page head by default but can also inline critical CSS and defer the aggregated full CSS, moves and defers scripts to the footer and minifies HTML. You can optimize and lazy-load images (with support for WebP and AVIF formats), optimize Google Fonts, async non-aggregated JavaScript, remove WordPress core emoji cruft and more. As such it can improve your site’s performance even when already on HTTP/2! There is extensive API available to enable you to tailor Autoptimize to each and every site’s specific needs.
If you think performance indeed is important, you should at least consider one of the many free page caching plugins (e.g. Speed Booster pack or KeyCDN’s Cache Enabler) to complement Autoptimize or even consider Autoptimize Pro which not only has page caching but also image optimization, CDN, critical CSS and more!

Autoptimize プロ
Autoptimize プロはプレミアムな機能強化で、画像最適化、CDN、ページのキャッシュ、自動でクリティカル CSS のルール、「ブースター」オプションを追加できる、サイトを高速化する機能が全部入りの便利なサブスクリプションです !

プレミアムサポート
私たちは、素晴らしい Autoptimize プレミアムサポートとサイトパフォーマンス最適化サービスを提供しています。https://accelera.site/ にて私たちの製品をご覧ください !

(LL Twistiti によるウィンドサーフィンの画像は creative commons ライセンスで表示)

インストール

お使いの WordPress 「プラグイン > 新規追加 」から単にインストールするだけです。それだけで様々に改善されます。手動でのインストールも簡単です。以下のようにします。

  1. ZIP ファイルをアップロードし、/wp-content/plugins/ ディレクトリで解凍
  2. WordPress の「プラグイン」メニューからプラグインを有効化してください
  3. 設定 > Autoptimizeへ移動し、ご希望のオプションを有効化します。一般的に、これは「HTML / CSS / JavaScript の最適化」を意味します。

FAQ

プラグインは、サイトを高速化するために何をしてくれますか ?

すべてのスクリプトとスタイルを最小化し、有効期限を備えたヘッダーを付与して圧縮するようウェブサーバーを設定します。標準設定では JavaScript はレンダリングブロックしないようにし、CSS もクリティカル CSS を追加することで同様にします。CSS と JS ファイルを結合(連結)するようにも設定できます。その場合、スタイルはページのヘッダーに、スクリプトはフッターに移動されます。また、HTML コードを最小化し、画像や Google Fonts を最適化することで、ページの軽量化もできます。

HTTP/2 で稼働させているので Autoptimize は不要ですか ?

HTTP/2 は確かに大きな前進で、複数の並列のリクエストを実行するために、同じ接続を利用することで、同じサーバーからの複数のリクエストの影響を大きく減少させ、このため、新しいインストールでは Autoptimize これ以上 CSS と JS を連結しなくなります。しかし、この css-tricks.com の記事やこのある Ebay エンジニアによるブログ記事で説明されているように、CSS/ JS の連結にはまだ多くの意義があります。結論としては、設定、テスト、再設定、再テストを経て調整し、あなたの環境で何が一番よく稼働するか確かめることです。HTTP/2 のみ、または HTTP/2 + 連結と最小化、HTTP/2 + 最小化 (AO も同様に可能で、「JS ファイルの連結」 や「CSS ファイルの連結」オプションのチェックを単に外すだけ)。そしてもちろん Autoptimize は単に JS と CSS を最適化する以上のことができます。

私のブログでも動きますか ?

なんの保証もできないとはいえ、あなたが正しく設定すれば Autoptimize は完璧に動作するでしょう。問題が起きた場合の設定方法の情報に関しては、下記の「使用に困ったら」を参照してください。希望であれば、tastewp.com という、新しい無料のダミーサイトで Autoptimize をテストできます

JavaScript を連結すると jquery.min.js が最適化されないのはなぜ ?

AO 2.1 以降、WordPress コアの jquery.min.js を最適化しないのには単純な理由があります。人気がある多くのプラグインでは、jQuery が利用できる状態を想定して、集約されていない状態であるインラインでの JS を挿入しています (インライン JS 内の独自コードにはキャッシュサイズの問題が発生する可能性がある)。そのため jquery.min.js の除外することで、大半のサイトでそのままうまく動作することを確かにします。jQuery も最適化したいのであれば、JS 最適化の除外リストから削除することもできます(「インラインの JS も連結」や「head 内へ JavaScript を強制」を有効化する必要があるかもしれません)。

自動最適化された JS がレンダリングブロックされるのはなぜ

これは以下の時に起こります。JavaSCript を連結しつつオプション「head 内へ JavaScript を強制」が有効な場合、または連結せず遅延させない場合に発生します。設定の変更を考慮してください。

自動最適化された CSS がまだレンダリングブロックされていると言われるのはなぜ

標準の Autoptimize の設定では、CSS は head 内でリンクされるため安全な初期設定ですが、Google PageSpeed Insights はこのことをよく言っていません。この FAQ では以下も説明されています。「すべての CSS のインライン化 (簡単)」や「CSS のインライン化と遅延 (より良い)」。

「CSS のインライン化と遅延」の使用とは何 ?

一般に CSS は文書の head 内に配置すべきです。最近、Google は必須ではない CSS の遅延化や、ページのファーストビュー (Above the fold) の表示に必要なスタイルのインライン化を促しています。このことは、モバイル端末でページをできるだけ早く描画するのに特に重要です。Autoptimize 1.9.0 以降は簡単にこれが行えます。「CSS のインライン化と遅延」を選択し、入力欄 (テキストエリア) にファーストビュー (Above the fold) のブロックを貼り付けます。

ファーストビューの見つけ方は ?

ファーストビュー (Above the fold) の境界は、モニターのサイズに依存するので、簡単な解決策はありません。ファーストビューの特定を試みるいくつかのツールはあります。以下のツールは良い出発点です。Sitelocity critical CSS generatorJonas Ohlsson による criticalpathcssgenerator はいい感じの基本的な解決策で、同じく Jonas Ohlsson による http://criticalcss.com/ はプレミアムな解決策です。あるいは、このブックマークレット (Chrome のみ) も役に立つでしょう。

すべての CSS をインラインにすべき ?

簡単に答えると、おそらく「いいえ」でしょう。すべての CSS をインラインで記述すれば CSS がレンダリングブロックされないとはいえ、ベースの HTML ページがかなり肥大化するため、さらなる解析時間が必要になります。サイトの閲覧中には複数のページが閲覧されるので、インラインの CSS はページごとに送信されますが、インラインでない CSS ではキャッシュが使えます。また インラインの CSS は、Facebook や Whatsapp が探索しない位置まで HTML 内のメタタグの位置を下げてしまい、これらのプラットフォームでシェアされる画像などを壊す可能性があります。

キャッシュが肥大化しています。Autoptimize はキャッシュを消去しないのですか ?

Autoptimize には、適切なキャッシュ消去の仕組みはありません。これは、まだほかのキャッシュから参照されている最適化された CSS/JS を削除する可能性があり、そうなればサイトの表示が壊れるためです。また、急速に肥大化するキャッシュは、避けるべき別の問題の存在の兆候となります。

次のどちらかの方法で、許容できる水準でキャッシュのサイズを維持できます:

  • 「インラインの JS も連結」や「インラインの CSS も連結」の無効化
  • ページごとに (あるいはページの読み込みごとに) 変わる JS の変数 (また時に CSS のセレクタ) を除外。その方法は、このブログ記事を参照してください。

上記の意見と反対に、AO のキャッシュを自動的に消去する第三者製の解決策があります。たとえば、このコードの使用このプラグインです。しかし上記の理由通り、何を行うのか理解している場合に使用してください。

「キャッシュを削除」がうまくいっていないようだ

管理バーの Autoptimize のドロップダウンのメニューから「キャッシュを削除」のリンクをクリックすると、「キャッシュが正常に消去されていない可能性があります」と表示されることがあります。この場合、Autoptimize 設定の「変更の保存とキャッシュの削除」ボタンをクリックしてください。

またキャッシュが 0ファイル / 0KB に下がってなくても心配する必要はありません。Autoptimize (バージョン 2.2 以降) では、消去後ただちに自動的にキャッシュを事前読み込みし速度を向上させます。

Autoptimize のキャッシュを消去するとサイトが壊れるようです !

「AO のキャッシュ」を消去した際、削除された最適化済みの CSS/JS を参照しているページ (HTML) が、「ページのキャッシュ」に存在してはいけません。この理由から Autoptimize と一部のページキャッシュは統合されていますが、この統合は 100% の対応ではないので、手動でページのキャッシュを消去する必要があることもあるでしょう。

Cloudflare の Rocket Loader は同時に使えますか ?

Cloudflare がまだベータ版だと考えている Cloudflare Rocket Loader は、JavaScript のレンダリングブロックをなくすために、高機能な一方で侵略性のある方法です。Autoptimize と Rocket Loader は同時に動作しますが、時に動作しないこともあります。最も良い方法は Rocket Loader を無効にし、Autoptimize を設定し、再び Rocket Loader を有効にしてから (有益だと考えるなら)、すべてが動作するかテストしてください。

2017年6月時点で、RocketLoader は、Filamentgroup の loadCSS を元にした AO の「CSS のインライン化と遅延」を壊すようで、遅延させた CSS は読み込まれませんでした。

Autoptimize を試したが Google Pagespeed のスコアはわずかな改善でした

Autoptimize は簡単な「私のページスピードの問題修正」用のプラグインではありません。このプラグインは、基本的には JS と CSS と画像を連結および最小化する「だけ」で、Google フォントを削除したり、CSS の読み込みを遅延させる、いくつか追加の機能があります。このようにしてサイトのパフォーマンスを改善し、また一部の特定のページスピードの警告に取り組むのに有用でしょう。もっと改善したければページのキャッシュや、ウェブサーバーの設定も調べる必要があるり、これらは実際のパフォーマンスとページスピードの評価を改善します (改善されたかは https://webpagetest.org などで読み込み時間を秒単位で計測します)。

API で何ができますか ?

多くのことです。リクエストごとの自動最適化を条件付きで無効化するフィルタ。CSS と JS の除外を変更。CSS による背景画像を CSS 内にインライン化する制限の変更。連結されたファイルの後ろに移動する JS ファイルを定義。連結された JS スクリプトのタグの defer 属性を変更。autoptimize_helper.php_example やこの FAQ にフィルタの例があります。

CDN はどう動作しますか ?

バージョン 1.7.0 以降、ブログのルートディレクトリに CDN が入っていると有効化します (例 http://cdn.example.net/wordpress/)。この URL が存在すれば、その URL は、CSS 内の背景画像 (data-uri を使用しないもの) を含む、すべての Autoptimize による生成ファイル (連結された CSS と JS) に使用されます。

アップロードした画像を CDN にもアップロードしたければ、 お使いの WordPress の構成設定内 (/wp-admin/options.php) の upload_url_path を、対象の CDN のアップロードパスに変更できます (例 http://cdn.example.net/wordpress/wp-content/uploads/)。既存の画像ではなく、設定変更以降にアップロードされた画像に適用されることを考慮してください。ヒントをくれた BeautyPirate に感謝 !

フォントも CDN に配置したい

Autoptimize はこれに対応していますが、ローカルに保存していないフォントは、追加の設定が必要な場合があるので、標準では有効化されていません。しかし、cross-origin request policy が正しければ、autoptimize_filter_css_fonts_cdntrue に設定し、その API をフックすることで、Autoptimize に対し、フォントを CDN に配置するよう指示できます。

add_filter( 'autoptimize_filter_css_fonts_cdn', '__return_true' );

CloudFlare を使っていますが、CDN のルートディレクトリには何を入力すれば良いですか

なにもしなくていいです。Cloudflare では、自動最適化された CSS/ JS は、自動でCloudflare の CDN に配置されます。

PHP の代わりに、強制的に連結済みファイルを固定的な CSS や JS にするには ?

お使いの ウェブサーバーで、圧縮 (GZIP など) とキャッシュ期限 (キャッシュ性を十分に考慮したキャッシュ管理) の扱いが適切に設定されていれば、Autoptimize を使って処理する必要はありません。この場合、「連結されたスクリプト / CSS を静的ファイルとして保存」の設定を有効化すると .css と .js ファイルとして連結されたファイルを、Autoptimize が強制的に保存します (このファイルを保存するための PHP は不要です)。これは Autoptimize 1.8 では標準設定です。

「最適化から除外」するには ?

CSS と JS の両方の最適化において、カンマ区切りの除外リストに「識別子」を追加することで、コードの連結と最小化を行わないようにできます。使用する正確な識別子の文字列は以下のように決定できます。

  • 特定のファイル (例 wp-content/plugins/funkyplugin/css/style.css) を除外したければ、単に funkyplugin/css/style.css を除外します。
  • 特定のプラグインのすべてのファイル (例 wp-content/plugins/funkyplugin/js/*) を除外するには、funkyplugin/js/ や plugins/funkyplugin を除外します。
  • インライン内のコードを除外するには、そのコードの塊中から特有の文字列を探し、除外リストに追加します。たとえば、<script>funky_data='Won\'t you take me to, Funky Town'</script> の除外には 、識別子は funky_data とします。

Autoptimize の使用に困ったら

問題発生時の解説をご覧ください。https://blog.futtta.be/2022/05/05/what-to-do-when-autoptimize-breaks-your-site/

ファイルを除外したけどまだ最適化されている

AO は、まだ最小化されていないことを示すファイル名であれば、除外された JS/CSS でも最小化します。AO 2.5 以降、設定の「JS、CSS & HTML」タブの「その他オプション」内の「除外された CSS ファイルと JS ファイルを最小化する」のチェックを外すことで、この機能を無効にできます。

助けてください。Autoptimize の有効化後、空白のページまたは内部サーバーエラーが発生しました。

ほかの HTML、CSS や JS の最小化プラグイン(BWP minify, WP minify など)を Autoptimize と同時に実行していないか、あるいはページキャッシュ用プラグイン (W3 Total Cache, WP Fastest Cache など) を無効化して確認してください。またはその機能を無効にしているページキャッシングプラグイン(W3 Total Cache, WP Fastest Cache, …)。CSS のみ、または JS のみの最適化を有効に、どちらがサーバーエラーの原因なのか確認し、一般的なトラブルシューティングの手順に従ってください。

しかしまだ自動最適化された CSS や JS ファイルが白紙です !

Apache 上で稼働しているなら、一部の環境では、Autoptimize が書いた .htaccess と、Apache 構成設定の AllowOverrides の設定 (一部の Ubuntu インストールでは標準設定) が競合していることがあります。自動最適化された CSS や JS ファイルには「内部サーバーエラー」が発生していることになります。解決するには、AllowOverrides を All に設定します。

ドメインマップを用いたマルチサイトにログインできない

ドメインマップを用いたマルチサイトでは、異なる WordPress のアクションとして、Autoptimize を初期化する必要があります。たとえば、以下の行を wp-config.php に追加すれば、setup_theme にフックされます:

define( 'AUTOPTIMIZE_SETUP_INITHOOK', 'setup_theme' );

エラーはありませんが、ページが最適化されていません。

Autoptimize は実際の最適化前にいくらか検査を行います。以下に当てはまる場合、そのページは最適化されません。

  • カスタマイザー内にいる場合
  • <html の開始タグがない
  • レスポンスに <xsl:stylesheet がある (出力は HTML ではなく XML であることを示している)
  • レスポンス内に <html amp がある (AMP のページは既に最適化されたものです)
  • 出力が RSS フィード (is_feed() 関数)
  • 出力が WordPress 管理ページ (is_admin() 関数)
  • ?ao_noptimize=1 を URL の末尾に追加したページが要求された場合
  • 最適化を無効にするために Autoptimize にコードがフックする場合 (Visual Composer
    のトピックを参照)
  • 別のプラグインが、互換性のないやり方で出力バッファーを使用している (順番に別のプラグインを無効化してみて原因を特定する)

Visual Composer や Beaver Builder などページビルダー系のプラグインが壊れます !!

ログインユーザーでも最適化するというオプションを無効化してください。

チェックアウト/支払いが動作しません !!

カート/チェックアウトのページの最適化を無効化します (WooCommerce, Easy Digital Downloads, WP eCommerce で動きます)

Revolution Slider が動きません。

JS 最適化を除外するカンマ区切りの一覧に js/jquery/jquery.min.js が指定されているか確認してください (標準設定で除外されています)。

「jQuery が定義されていません」というエラーが表示されます

この場合、jQuery の読み込みを必要とする、連結されていない JavaScript が存在します。カンマ区切りの JS 最適化の除外リストに js/jquery/jquery.min.js を追加する必要があります。

NextGen Galleries を使っていますが、多くの JS ファイルが連結・最小化されていない

NextGen Galleries は巧みに JavaScript を追加用しています。Autoptimize による連結を可能にするには、このコードスニペット add_filter( 'run_ngg_resource_manager', '__return_false' ); でNextgen Gallery のリソース管理を無効化するか、あるいは、wp-config.php に以下を記述することで初期化の時期を早めます:define("AUTOPTIMIZE_INIT_EARLIER","true");

noptimize って ?

Autoptimize バージョン 1.6.6 以降、noptimize タグ内のすべてを除外します。例: <!--noptimize--><script>alert(‘これは最適化されません’);</script><!--/noptimize-->

投稿やページ、ウィジット、テーマファイル内にこれを記述できます (テーマの更新による上書を避けるには、child theme の作成を考慮します)。

キャッシュされる最適化ファイルのフォルダやファイル名を変更するには ?

標準の /wp-content/cache/autoptimize/autoptimize_12345.css の代わりに、たとえば /wp-content/resources/aggregated_12345.css にするには、wp-config.php に以下を追加します:

define('AUTOPTIMIZE_CACHE_CHILD_DIR','/resources/');
define('AUTOPTIMIZE_CACHEFILE_PREFIX','aggregated_');

これは既定値以外の WP_CONTENT_URL で動作しますか ?

いいえ、Autoptimize は既定値以外の WP_CONTENT_URL に対応していませんが、Autoptimize の API にフックする数行のコードで実現できます。

生成された JS/CSS を事前にgzip 圧縮できますか ?

はい。しかし、標準では無効化されています。有効化するには、autoptimize_filter_cache_create_static_gzip を true にします。オンザフライの圧縮によるオーバーヘッドを避けるために、ウェブサーバが非圧縮ファイルの代わりにこれらのファイルを使用するように設定する必要があります。

「絵文字の削除」は何をしますか ?

これは、Autoptimize バージョン 2.3 以降の新しいオプションで、WordPress コアによって追加されたインライン CSS、インライン JS、リンク型の JS ファイルを除去します。サイトのパフォーマンスを少し改善するでしょう。

「クエリー文字列を削除」は役立ちますか ?

一部のオンラインのパフォーマンス評価ツールは、パフォーマンスの問題として「静的ファイルのクエリー文字列」を指摘しますが、一般にこの影響はほとんどありません。Autoptimize バージョン 2.3 以降、クエリ文字列 (具体的には ver 変数) を削除できます。しかし「静的リソースからクエリー文字列を削除」を有効にし削除しても、サイトのパフォーマンス (ミリ秒単位) にはほとんど影響がありません。

Google フォントをどのように最適化したらいい ?

Google フォントは「レンダリングブロック」されるリンク型の CSS ファイルによって、通常は読み込まれます。Google フォントを使用したテーマやプラグインをお使いであれば、そのような CSS ファイルが複数あるかもしれません。Autoptimize (バージョン2.3以降) では、Google フォントをすべて削除するか、読み込み方法を最適化することで、Google フォントの影響を減らするができるようになりました。2つの最適化方法があります。1つ目の「結合してリンク」では、Google フォントのすべてのリクエストを、1つのリクエストに置き換え、これはまだレンダリングブロックが発生しますが、フォントがすぐに読み込まれるようになります (つまり、ページ読み込み中にはフォントの変更が表示されません)。2つ目は「結合と非同期読み込み」で、JavaScript を使ってレンダリングブロックのない方法でフォントを読み込みしますが、「スタイル化されていないテキストの点滅」が起こることがあります。

事前接続はどう使いますか ?

事前接続 (Preconnect) は、ただちに接続しない場合でも特定のドメインに接続するようブラウザ(対応表)に指示するという少し高度な機能です。たとえば、第三者のリソースが HTTPS に与える影響を軽減するために使用できます (DNS リクエスト、TCP 接続、SSL/TLS ネゴシエーションが事前に実行される)。非常に多くのドメインに事前接続すると逆効果となるので、注意して使用します。

JS を非同期にする注意点

自動最適化されていない JavaScript ファイル (除外していたり提供サイトが異なるなどの理由で) は、通常はレンダリングブロックされます。「非同期 JavaScript」欄にカンマ区切りでこれらの JS ファイルを追加すると、Autoptimize は 非同期 (async) 属性を追加し、ブラウザに非同期で読み込ませます (レンダリングブロックなし)。たとえば、js/jquery/jquery.min.js を非同期にしてしまうと、「jQuery は未定義です (jQuery is not defined)」というエラーが発生しやすくなるため、注意して用いてください。

画像最適化はどう動作しますか ?

画像の最適化を有効にすると、Autoptimize は、image タグと CSS ファイルから、お使いのドメインから読み込んだ png, gif, jpeg (.jpg) ファイルを探し、それらのファイルの src (参照先) を ShortPixel CDN に変更します。重要: これは公開されている画像に対してのみ機能します。公開されていなければ、画像最適化用のプロキシは画像を取得できません。なので、ファイアウォールやプロキシ、パスワード保護、あるいは直リンク防止も画像最適化が行えない原因となることがあります。

社内ネットワークや保護されたサイトで画像最適化はできますか ?

いいえ。画像最適化は、サービスがあなたのサイトから元の画像を取得し、最適化して CDN に保存するという、外部の画像最適化サービスの能力に依存します。あなたが、匿名の訪問者として画像ダウンロードすることができない場合 (原因としてファイアウォール/プロキシ/パスワード保護/直リンク保護)、画像最適化は動作しません。

画像最適化についてもっと情報を得るには ?

Shortpixel の FAQ をご覧ください。

AO がページキャッシュの消去をリッスンするのを無効化できますか ?

AO 2.4 以降、AO は、自身のキャッシュを消去するために、ページキャッシュの消去を待ち受け (リッスン) しています。あなたは以下のフィルターでこの動作を無効化できます:

add_filter('autoptimize_filter_main_hookpagecachepurge','__return_false');

一部の非 ASCII 文字が最適化の後になくなります

標準では AO はマルチバイトに対応のない文字列処理を用いますが、お使いの環境の PHP に mbstring 拡張モジュールがあれば、このフィルタでマルチバイトに対応する関数を有効化できます:

add_filter('autoptimize_filter_main_use_mbstring', '__return_true');

クリティカル CSS が動作しません

こちらの「パワーアップ」の FAQ をご覧ください。後にこの FAQ へと統合する予定です。

Autoptimize バージョン 2.7 以降でも クリティカル CSS パワーアップは必要ですか ?

いいえ。クリティカル CSS パワーアップは不要です。すべての機能は(多くの修正と改善を含めて)、Autoptimize に組み込まれました。

「404 フォールバックの使用」は何を行いますか ? 必要でしょうか ?

Autoptimize は、連結および最適化された CSS/JS をキャッシュし、それらキャッシュされたファイルへのリンクを HTML に挿入し、これがページキャッシュとして保存されます (プラグイン、ホスト単位で、また第三者により、Google キャッシュ、あるいはブラウザ内に)。ページキャッシュの HTML 内から、自動最適化された CSS/JS へのリンクがあり、この HTML が削除された場合 (キャッシュが消去された場合)、存在するだろうとみなした CSS や JS を見つけられないため、そのキャッシュのページは期待通りには表示・動作しません (404 エラーの発生)。

この設定の目的は、「フォールバック」(予備) の CSS や JS を提供してそれらが壊れることを防ぐことです。このフォールバックのファイルは、キャッシュが空になった直後に作成された自動最適化された CSS と JS ファイルのコピーで、そのホームページが原型となっています。別のページでは、100% 完全な CSS/JS が適用されない可能性がありますが、少なくとも CSS/JS がまったくないという影響は軽減されます (たいてい大幅に軽減されます)。

このオプションを有効化すると、Autoptimize は、.htaccess (Apache 用のファイル) に ErrorDocument 404 を追加し、また WordPress コアのtemplate_redirect にもフックして WordPress によって処理された 404 エラーを捕捉します。NGINX を利用していれば以下のようなコードが動作するでしょう (NGINX に詳しくありませんが私の環境で動作させています)。

location ~* /wp-content/cache/autoptimize/.*\.(js|css)$ {
    try_files $uri $uri/ /wp-content/autoptimize_404_handler.php;
}

また以下は別の良い方法です (fboylovesyou 氏の提供)。

location ~* /wp-content/cache/autoptimize/.*\.(css)$ {
    try_files $uri $uri/ /wp-content/cache/autoptimize/css/autoptimize_fallback.css;
}
location ~* /wp-content/cache/autoptimize/.*\.(js)$ {
    try_files $uri $uri/ /wp-content/cache/autoptimize/js/autoptimize_fallback.js;
}

Autoptimize で使われるオープンソースソフトウェアは ?

以下の素晴らしいオープンソース・プロジェクトが、何らかの形で Autoptimize に使われています:

サポートを得たい

wordpress.org のサポート用掲示板でサポートを得ることができます。もし、Autoptimize の設定では解決せず、コード内にバグを発見したと100%確信するなら、GitHub 上で 「問題 (issue)」を作成できます。プレミアムサポートをご希望であれば、Autoptimize Pro サポート・ウェブ最適化サービス をご覧ください。

もうやめたいです。Autoptimize をどうやって削除できますか ?

  • プラグインを無効化 (これによりオプションとキャッシュが削除されます)
  • プラグインを削除
  • Autoptimize で生成された CSS/JS を参照している可能性のあるキャッシュを消去 (WP Super Cache などページキャッシュ用プラグイン)

貢献するには

Github 上の Autoptimize をフォークして コードを提供するだけです !

評価

2023年8月22日
I'd tried many things and even asked for professional help to make my blog load faster without much change until I decided to try Autoptimize Pro. A dramatic improvement in speed was gained immediately and I continue to be delighted with how much faster everything loads. Very impressed.
2023年8月20日 1 reply
I don't have time for manually setting up each optimization and this option is great with most of my websites. When this doesn't work I usually hire someone for manual configurations
1,394件のレビューをすべて表示

貢献者と開発者

Autoptimize はオープンソースソフトウェアです。以下の人々がこのプラグインに貢献しています。

貢献者

“Autoptimize” は32ロケールに翻訳されています。 翻訳者のみなさん、翻訳へのご協力ありがとうございます。

“Autoptimize” をあなたの言語に翻訳しましょう。

開発に興味がありますか ?

コードを閲覧するか、SVN リポジトリをチェックするか、開発ログRSS で購読してみてください。

変更履歴

3.1.8.1

  • urgent fix for PHP error, sorry about that!

3.1.8

  • Images: improve optmization logic for background images
  • Critical CSS: don’t trigger custom_post rule if not is_singular + adding debug logging for rule selection
  • some other minor changes/ improvements/ filters, see the GitHub commit log.

3.1.7

  • security: improve validation (import) and sanitization (output) of critical CSS rules, to fix a medium severity Admin+ Stored Cross-Site Scripting vulnerability as reported by WP Scan Security.

3.1.6

  • CSS: removing trailing slashes in <link tags for more W3 HTML validation love
  • Extra: also dequeue WooCommerce block CSS if “remove WordPress block CSS” option is active
  • imgopt: also act on non-aggregated inline CSS
  • imgopt: added logic to warn users if Shortpixel can’t reach their site
  • backend: AO toolbar JS/ CSS is finally minified as well.
  • explicitly disable optimization of login pages
  • some other minor changes/ improvements/ filters, see the GitHub commit log.

3.1.5

  • improvements to JSMin by Robert Ehrenleitner (big thanks Robert!).
  • do not consider jquery.js as minified any more (WordPress now uses jquery.min.js by default and jquery.js is the unminified version).
  • fix for “undefined array key” PHP errors in autoptimizeCriticalCSSCron.php
  • some other minor changes/ improvements/ filters, see the GitHub commit log.

3.1.4

  • Improvement: when all CSS is inlined, try doing so after SEO meta-tags (just before ld+json script tag which most SEO plugins add as last item on their list).
  • Img opt: also optimize images set in data-background and data-retina attributes (+ filter to easily add other attributes)
  • CSS opt: filter to enable AO to skip minification of calc formulas in CSS (as the CSS minifier on rare occasions breaks those)
  • Multiple other filters added
  • Some other minor changes/ improvements/ filters, see the GitHub commit log.

3.1.3

  • Multiple fixes for metabox LCP image preloads (thanks Kishorchand for notifying & providing a staging environment to debug on).
  • Fix in revslider compatibility (hat tip Waqar Ahmed for reporting & helping out ).
  • No image optimization or criticalcss attempts on localhost installations any more + notification of that fact if localhost detected.
  • Some other minor changes/ improvements/ filters, see the GitHub commit log.

3.1.2

  • Google Fonts: some more removal logic
  • fix for 404 fallback bug (hat tip to Asif for finding & reporting)
  • Some other minor changes/ improvements/ filters, see the GitHub commit log.

3.1.1.1

  • Quick workaround for an autoload conflict with JetFormBuilder (and maybe other Crocoblock plugins?) that causes a critical error on the AO settings page.

3.1.1

  • images: when optimizing images and lazyloading is on, then by default do not set an LQIP (low quality image placeholder) any more (reason: it might look nice but it comes with a small-ish perf. penalty). This can be re-enabled by returning true to the autoptimize_filter_imgopt_lazyload_dolqip filter.
  • security: further improvements to critical CSS settings page (again with the great assistance of WPScan Security).
  • some other minor changes/ improvements/ filters, see the GitHub commit log.

3.1.0

  • new HTML sub-option: “minify inline CSS/ JS” (off by default).
  • new Misc option: permanently allow the “do not run compatibility logic” flag to be removed (which was set for users upgrading from AO 2.9.* to AO 3.0.* as the assumption was things were working anyway).
  • security: improvements to the critical CSS settings page to fix authenticated cross site scripting issues as reported by WPScan Security.
  • bugfix: “defer inline JS” of very large chunks of inline JS could cause server errors (PCRE crash actually) so not deferring if string is more then 200000 characters (filter available).
  • some other minor changes/ improvements/ hooks, see the GitHub commit log

3.0.4

  • fix for “undefined array key ao_post_preload” on post/ page edit screens
  • fix for image optimization altering inline JS that contains an <img tag if lazyload is not active
  • improvements to exit survey
  • confirmed working with WordPress 6.0

3.0.3

  • fix for images being preloaded without this being configured when lazyload is on and per page/post settings are off.
  • ensure critical CSS schedule is always known.
  • when deferring non-aggregated JS, make the optimatization exclusions take the full script-tag into account instead of just the src URL.

3.0.2

  • rollback automatic “minify inline CSS/ JS” which broke more then expected, this will come back as a separate default off option later and can now be enabled with a simple filter: add_filter( 'autoptimize_html_minify_inline_js_css', '__return_true'); .
  • fix for “Call to undefined method autoptimizeOptionWrapper::delete_option()” in autoptimizeVersionUpdatesHandler.php

3.0.1

  • fix for minification of inline script with type text/template breaking the template (e.g. ninja forms), hat tip to @bobsled.
  • fix for regression in import of CSS-files where e.g. fontawesome CSS was broken due to being escaped again with help of @bobsled, thanks man!

3.0.0

  • fundamental change for new installations: by default Autoptimize will not aggregate JS/ CSS any more (HTTP/2 is ubiquitous and there are other advantages to not aggregating esp. re. inline JS/ CSS and dependancies)
  • new: no API needed any more to create manual critical CSS rules.
  • new: “Remove WordPress blocks CSS” option on the “Extra” tab to remove block- and global styles (and SVG).
  • new: compatibility logic for “edit with elementor”, “revolution slider”, for non-aggregated inline JS requiring jQuery even if not excluded (= auto-exclude of jQuery) and JS-heavy WordPress blocks (Gutenberg)
  • new: configure an image to be preloaded on a per page/ post basis for better LCP.
  • improvement: defer inline now also allowed if inline JS contains nonce or post_id.
  • improvement: settings export/ import on critical CSS tab now takes into account all Autoptimize settings, not just the critical CSS ones.
  • technical improvement: all criticalCSS classes were refactored, removing use of global variables.
  • technical improvement: automated unit tests on Travis-CI for PHP versions 7.2 to 8.1.
  • fix: stop Divi from clearing Autoptimize’s cache which is pretty counter-productive.
  • misc smaller fixes/ improvements, see the GitHub commit log

older