Autoptimize

説明

Autoptimize は本当に簡単にサイトを最適化します。スクリプトとスタイルを連結、最小化 (Minify)、キャッシュし、標準ではページの先頭に挿入される CSS を、クリティカル CSS (重要な CSS) としてインライン化したり、連結した完全な CSS を遅延させたり、スクリプトをページの末端に移動し遅延させたり、また HTML を最小化することが可能です。ほかにも画像の最適化と遅延読み込み (WebP と AVIF 形式に対応)、Google フォントの最適化、非同期で未連結の Javascript の処理 (async 属性)、WordPress コアの絵文字の残骸の除去ができます。他にも。従ってすでに HTTP/2 を利用していてもサイトの性能を向上させることが可能です。豊富な API があり、各サイト個別の要望に応じて Autoptimize を調整できます。あなたがサイトのパフォーマンスを重視していれば、同時にページキャッシュを行うなんらかのキャッシュ用プラグインを使用すべきでしょう。そのように Autoptimize を補うような良い候補の例には Speed Booster pack, KeyCDN’s Cache Enabler, WP Super Cache また Cloudflare WP Cloudflare Super Page Cache があります。FAQ 内の AO は Autoptimize の略です。

Premium Support
We provide great Autoptimize Pro Support and Web Performance Optimization services, check out our offering on https://accelera.autoptimize.com/!

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

インストール

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

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

FAQ

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

It minifies all scripts and styles and configures your webserver to compresses them with good expires headers. JavaScript be default will be made non-render-blocking and CSS can be too by adding critical CSS. You can configure it to combine (aggregate) CSS & JS-files, in which case styles are moved to the page head, and scripts to the footer. It also minifies the HTML code and can also optimize images and Google Fonts, making your page really lightweight.

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

HTTP/2 is a great step forward for sure, reducing the impact of multiple requests from the same server significantly by using the same connection to perform several concurrent requests and for that reason on new installations Autoptimize will not aggregate CSS and JS files any more. That being said, concatenation of CSS/ JS can still make a lot of sense, as described in this css-tricks.com article and this blogpost from one of the Ebay engineers. The conclusion; configure, test, reconfigure, retest, tweak and look what works best in your context. Maybe it’s just HTTP/2, maybe it’s HTTP/2 + aggregation and minification, maybe it’s HTTP/2 + minification (which AO can do as well, simply untick the “aggregate JS-files” and/ or “aggregate CSS-files” options). And Autoptimize can do a lot more then “just” optimizing your JS & CSS off course 😉

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

Although Autoptimize comes without any warranties, it will in general work flawlessly if you configure it correctly. See “Troubleshooting” below for info on how to configure in case of problems. If you want you can test Autoptimize on a new free dummy site, courtesy of tastewp.com.

Why is jquery.min.js not optimized when aggregating JavaScript?

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

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

This happens when aggregating JavaSCript and ticking the “force in head” option or when not aggregating and not deferring. Consider changing settings.

自動最適化された 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 とします。

Troubleshooting Autoptimize

Have a look at the troubleshooitng instructions at 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 へと統合する予定です。

Do I still need the Critical CSS power-up when I have Autoptimize 2.7 or higher?

No, the Critical CSS power-up is not needed any more, all functionality (and many fixes/ improvements) are now part of 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 をフォークして コードを提供するだけです !

評価

2022年9月25日
Had an issue with errors in the console window. The support team helped me investigate it was exclusively regarding the admin side and shew me the way to disable the plugin functionality for admins. All of that within 1 day, great job and thank you again!
2022年9月24日
A great plugin that has been helpful for years.
2022年9月18日
Awesome support (answers really quickly), and the plugin itself works magically 🙂
2022年8月22日
This plugin helps to get rid of loading Google Fonts if you are hosting Fonts local. It does what is written in the description (and more). As always. A product, especially a software, is as good as its support. And the support is awesome. Thanks Frank!
2022年8月22日
If you install it once, you will never able to unstall it from your website. you can just deactive it. It creates more problems, than good. My file size getting bigger day by day without any reason and my cpu usage gets 100 percent!. So please dont install it.
1,349件のレビューをすべて表示

貢献者と開発者

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

貢献者

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

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

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

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

変更履歴

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