What you'll have when you finish
A WordPress install that no longer loads emoji or embed scripts you never use, no longer runs scheduled tasks only when a visitor happens to load a page, no longer downscales every image you upload to 2560 pixels, and no longer accumulates twenty post revisions per draft until your database is 80% revision history. Plus PHP runtime limits set to values that match the work the site actually does, rather than whatever your host shipped by default.
- Prerequisites: WordPress 5.3+ (for the big-image-threshold toggle), PHP 7.4+, and either an Apache or LiteSpeed server for the
max_execution_timerules (Nginx falls back to awp-config.phpapproach with caveats noted below). - You'll need access to: a WordPress admin account, and SSH or cron-tab access on the server to set up a system cron in section 4. If you do not have that access, ask your host or skip that section.
- Time: 20 minutes for the toggles, plus 10 to 15 for the system-cron setup if you take that step.
- Take a baseline: know what your current limits and bloat look like
- Tune the system limits: memory, execution time, upload size
- Strip the bloat: emojis, embeds, script concatenation
- Disable WP-Cron and replace it with a real system cron
- Tame database growth: autosave, revisions, trash retention
- Polish the media library: big image threshold, infinite scroll
1. Take a baseline: know what your current limits and bloat look like
Before you change a setting, know the value you are about to change. Five numbers are worth writing down before you start:
- Memory limit: WordPress's effective
WP_MEMORY_LIMIT. View it under Tools › Site Health › Info › Server in the WordPress admin. - Max execution time: PHP's per-request runtime cap. Same Site Health screen.
- Upload max filesize: the largest file the Media uploader will accept. Visible at Media › Add New on the upload screen.
- Database size: under Tools › Site Health › Info › Database. Note especially the
wp_postsandwp_postmetasizes. - Number of revisions on a representative post: open an existing post in the editor and check the "Revisions" panel.
These five numbers tell you which sections of this tutorial are urgent and which are nice-to-have. A site with a 256M memory limit and a healthy database does not need most of section 2. A site with thousands of revisions per post desperately needs section 5.
2. Tune the system limits: memory, execution time, upload size
Three PHP-level limits affect what WordPress can do per request. AdminEase exposes each one and writes the change to wp-config.php (and, on LiteSpeed, to .htaccess directives) so it survives PHP and WordPress updates.
This writes two constants to wp-config.php: WP_MEMORY_LIMIT (the front-end limit) and WP_MAX_MEMORY_LIMIT (the admin-side limit, used during image processing and plugin operations). For most production sites, 256M is comfortable. Sites running heavy page builders or large WooCommerce stores benefit from 512M. Anything above 1G is unusual outside of imports and migrations.
This is the cap on how long a single PHP request can run before it gets killed. Default WordPress installs ship at 30 seconds. Hosts vary. On Apache and Nginx, AdminEase writes max_execution_time as an ini directive to wp-config.php. On LiteSpeed, it additionally writes php_value directives to .htaccess and a rewrite rule with E=noabort:1,E=noconntimeout:1 to prevent the LiteSpeed connection timeout from cutting requests short.
This writes both upload_max_filesize and post_max_size ini directives to wp-config.php. The post_max_size is automatically padded above your upload limit (the larger of 8MB extra, or 25% of the upload size) so that the surrounding form data does not push the total request size over the limit. The plugin also hooks wp_handle_upload_prefilter at runtime to reject oversized uploads with a clean error message rather than the cryptic default PHP one.
3. Strip the bloat: emojis, embeds, script concatenation
Three features that load on every WordPress page by default and that most sites do not need.
Emojis. WordPress ships a small JavaScript file plus inline CSS that detects whether the visitor's browser supports modern emoji rendering, and if not, swaps emoji characters for SVG fallbacks served from s.w.org. In 2026 every browser supports native emoji, so the swap is dead code. AdminEase removes the relevant print_emoji_detection_script and print_emoji_styles actions from wp_head, admin_print_scripts, and wp_print_styles, removes the TinyMCE emoji plugin, and removes the DNS-prefetch hint that would otherwise warm up a connection to s.w.org.
Embeds. WordPress's oEmbed system makes URLs to YouTube, Twitter, and other supported services auto-embed when pasted into a post. Most modern sites use page builders that handle embeds independently, and the oEmbed REST endpoint adds discovery links and a script (wp-embed) to every page. AdminEase removes the REST endpoint, the discovery link in <head>, the TinyMCE embed plugin, the embed=true rewrite rule, and the oembed/1.0/embed and oembed/1.0/proxy REST routes.
Script concatenation. WordPress's admin combines multiple JavaScript files into single requests as a performance optimization. On modern HTTP/2 connections, that bundling can actually be slower than letting the browser load files in parallel, and it interferes with debugging. AdminEase writes define('CONCATENATE_SCRIPTS', false); to wp-config.php when the toggle is on, which tells WordPress to serve admin scripts individually.
4. Disable WP-Cron and replace it with a real system cron
This is the most consequential single change in the article. WordPress's built-in scheduler (WP-Cron) does not run on a real schedule. It runs whenever a visitor happens to load a page, by checking on every request whether any scheduled tasks are due, and if so, firing them as part of that visitor's request. The result on a busy site is that scheduled tasks pile up; on a quiet site they barely run at all. Worst case, every visitor request pays the cost of checking the queue.
The fix is two steps: tell WordPress not to run cron from page requests, then set up a real system cron that calls WordPress's cron endpoint on a fixed schedule.
define('DISABLE_WP_CRON', true); to wp-config.php.
If you stop here, scheduled tasks will never run. WordPress will accumulate them silently. You must complete step 2 before this is safe.
wp-cron.php on a schedule. A typical entry that fires every 5 minutes:
*/5 * * * * curl -s https://your-site.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
Five minutes is a reasonable default. Tighter intervals (every minute) make sense for sites with email queues or scheduled posts that need rapid dispatch. Looser intervals (every 15 minutes) are fine for content sites with minimal cron activity. The right number is "the longest acceptable delay for your most time-sensitive scheduled task."
5. Tame database growth: autosave, revisions, trash retention
Three settings that together control how much editorial history WordPress retains. The defaults are generous to the point of being wasteful on a busy editorial site.
Autosave interval. WordPress autosaves every open post every 60 seconds. For a writer in a long session, that means a draft can pick up dozens of autosave revisions in the wp_posts table during a single afternoon's writing. Raising this to 300 (5 minutes) is the right default for most teams. AdminEase writes define('AUTOSAVE_INTERVAL', 300);.
Number of post revisions. By default, WordPress keeps every revision of every post forever. A heavily-edited post can have hundreds. AdminEase exposes three choices: keep all (the WordPress default), keep none, or keep a specific number. For most editorial sites, 5 to 10 revisions is enough history without bloating the table.
wp post delete $(wp post list --post_type=revision --format=ids) --force) or a dedicated cleanup plugin once. After that, the AdminEase setting keeps the table from growing back.
Empty trash days. By default, WordPress holds deleted posts in the trash for 30 days before permanently deleting them. AdminEase lets you change that to 0 (delete immediately, no trash), 1, 7, 14, 30, 60, 90, 180, or 365 days, or remove the constant entirely (returns to the default 30).
For most editorial sites, 7 days is the right balance: long enough to recover from accidental deletes, short enough to avoid permanently retaining a trash of mistakes. Set this to 0 only on sites where deletes are intentional and final (a strict moderation workflow, for example).
6. Polish the media library: big image threshold, infinite scroll
Two media-related improvements that punch above their toggle-weight.
Disable big image threshold. Since WordPress 5.3, any uploaded image larger than 2560px in either dimension gets automatically downscaled to that threshold, and the resized version becomes the "full" image. The original is preserved on disk with a -scaled suffix but is not used. The default is well-intentioned (it stops 50-megapixel uploads from blowing up your media library), but it also silently degrades quality on retina displays and large hero images. Most sites that care about image quality should turn this off and rely on responsive image sizes instead.
What this does at the code level: AdminEase filters big_image_size_threshold to return false, which tells WordPress to skip the downscaling step. Existing already-downscaled images are not restored (the -scaled versions stay as they are). Only new uploads from this point on retain their original dimensions.
Media library infinite scrolling. WordPress 6.0 added an opt-in for infinite scroll in the Media Library grid view, but it ships disabled by default. The default Media Library uses pagination with a "Load more" button. On sites with thousands of images, infinite scroll is meaningfully faster to navigate.
This is admin-only (the filter check happens inside is_admin()) and has zero front-end effect. AdminEase filters media_library_infinite_scrolling to return true.
Where to go from here
Twelve toggles, four tabs, one underlying goal: make the WordPress install do less of what it does not need and more of what it does. The single most impactful change is the WP-Cron replacement. The change that pays back fastest in database size is the revisions limit. The change that pays back fastest in front-end speed depends on your starting point: a heavily-bloated default install will see the largest gain from disabling emojis and embeds, while a properly-built modern site will see almost no front-end change but will benefit from the admin-side ones.
The companion "Monitoring & Diagnostics" tutorial covers AdminEase's observability features (Email Log, Cron Viewer, Network Viewer), which are the tools you use to verify that your scheduled tasks are actually running and that the front-end is actually loading what you expect.
Frequently asked questions
Will any of these settings break my theme or plugins?
The bloat-stripping toggles (emojis, embeds, script concatenation) have known compatibility edges. Disabling embeds removes auto-embedding for raw URLs pasted in the Classic editor. Disabling script concatenation only affects the admin. Everything else writes constants to wp-config.php or applies runtime filters; neither approach breaks well-built plugins. Test on staging if you have one.
Why is autosave under Performance but post revisions under Posts?
AdminEase groups settings by their conceptual home, not by their effect. Autosave is a WordPress-wide editing setting that affects performance through database write frequency. Post revisions is a per-post-type behavior that fits naturally under Posts. The split looks arbitrary at first but maps cleanly to how WordPress itself categorizes these features in the codex.
My host says I can't change max_execution_time. What gives?
Shared hosts often lock the value at the PHP-FPM or pool level, in which case the wp-config.php ini directive is ignored. You will know because the Site Health screen shows the host's value unchanged after you save in AdminEase. The fix is either to ask the host to raise the limit on your account, or to move to a host that lets you control it. There is no WordPress-level workaround.
I disabled WP-Cron but forgot to set up a real cron. What happens?
Scheduled tasks stop running. Scheduled posts will not publish on time. Plugin updates that are scheduled via cron will not fire. Email notifications that go through cron will queue up but not send. The damage is reversible: turn the toggle off, and WP-Cron resumes running from page loads. But fix the system cron rather than reverting, because the page-load cron is the problem you were solving in the first place.
How big can WP_MEMORY_LIMIT actually go?
AdminEase will let you set values up to 32G. Your host caps the real ceiling. PHP will silently honor whichever is lower: your WP_MEMORY_LIMIT or the host's memory_limit. Check effective values in Site Health after saving. If the number you set is not reflected, the host is the bottleneck.
Should I disable big image threshold on every site?
No. Disable it on sites where image quality matters (photography, portfolios, art, e-commerce with detailed product shots) and where you also have responsive image sizes properly configured. Leave it on for content sites where editors paste in random 8000px images and the resulting 5MB files would otherwise become hero images. The default exists because most users do not check their uploads. Turn it off when you trust yourself to.