Table of contents
33 tips to speed up your WordPress siteFAQsGetting startedAdditional resources
Get the industry’s fastest hosting for WordPress◦ 100% network uptime
◦ Comprehensive security
◦ 24/7 support
Explore options

WordPress Guide → SEO → Speed Up Your Website

Speed up a WordPress site: 33 tips to optimize your website

A slow website frustrates visitors, hurts search rankings, and can even cost you sales. WordPress is powerful, but without some optimization, your site may not perform at its best. Luckily, there are several proven ways to make WordPress faster.

Get fast, reliable hosting for WordPress

Power your site with the industry’s fastest, most optimized WordPress hosting

WordPress.org hosting

33 tips to speed up your WordPress site

To speed up a WordPress site, focus on three main areas: choosing quality hosting and a lightweight theme, optimizing your site assets with caching, image compression, and file minification, and reducing unnecessary load by limiting plugins, cleaning your database, and using tools like CDNs and lazy loading.

Regular updates and maintenance also ensure your site runs efficiently over time.

Here are 33 tips—from beginner friendly to more advanced—to help you fully optimize your site.

TipSummaryDifficultyImpact
1. Optimize imagesCompress, resize, and convert images to reduce file sizeBeginnerHigh
2. Implement cachingStore prebuilt pages/files so they load instantlyBeginnerHigh
3. Use a CDNDeliver static files from servers closest to visitorsBeginnerHigh
4. Lightweight themeChoose a clean, fast theme with minimal codeBeginnerHigh
5. Keep WP updatedUpdate core, themes, and plugins regularlyBeginnerMedium
6. Latest PHP versionUpgrade to the newest PHP for speed and securityModerateHigh
7. Minify/combine codeShrink and combine CSS, JS, and HTMLBeginnerMedium
8. Optimize databaseClean out old data, revisions, and overheadBeginnerMedium
9. Limit post revisionsControl how many content revisions are storedBeginnerLow
10. Lazy load mediaLoad images/videos only when they’re visibleBeginnerMedium
11. Remove unused pluginsDelete inactive plugins, themes, and widgetsBeginnerMedium
12. Reduce external scriptsCut or self-host third-party scripts/assetsModerateHigh
13. Clean media libraryDelete unused files and thumbnailsBeginnerLow
14. Paginate commentsBreak large comment threads into pagesBeginnerLow
15. Paginate long postsSplit long posts into multiple pagesBeginnerLow
16. Disable hotlinkingBlock others from stealing your images/bandwidthModerateLow
17. DB calls & cachingReduce queries; use Redis/Memcached object cacheProHigh
18. Defer blocking CSS/JSPrevent scripts/styles from delaying renderingModerateHigh
19. Reduce redirectsEliminate extra URL hops and chainsBeginnerMedium
20. Upgrade infrastructureMove to faster servers or stacks when neededModerateHigh
21. Fast hosting providerPick a reliable, performance-focused hostBeginnerHigh
22. Host speed featuresAsk host to enable caching, Brotli, etc.BeginnerMedium
23. DB in same regionKeep DB and site servers geographically closeProHigh
24. Use better pluginsReplace bloated plugins with efficient onesBeginnerMedium
25. Remove share buttonsReplace heavy share scripts with lighter linksBeginnerLow
26. Disable pingbacksTurn off old link notifications to cut spam loadBeginnerLow
27. DNS-level firewallUse Cloudflare or similar to block bad trafficModerateHigh
28. Fix HTTPS/SSL issuesCorrect mixed content and redirect loopsModerateMedium
29. Speed diagnosticsTest with PageSpeed Insights, GTmetrix, etc.BeginnerMedium
30. Offload heavy mediaHost large videos/audio on YouTube/VimeoBeginnerMedium
31. Elasticsearch searchUse Elasticsearch for large-site fast searchProMedium
32. Optimize homepageLimit posts, use excerpts, trim widgetsBeginnerMedium
33. Optimize fontsReduce weights, preload, or host fonts locallyModerateMedium

1. Optimize images

Difficulty: Beginner
Impact: High

Image optimization means preparing your pictures in a way that reduces their file size without hurting visual quality. This usually involves compressing images, resizing them to the dimensions you actually use on your site, and sometimes converting them into modern formats like WebP. Tools and plugins can automate most of this process, so you don’t have to manually adjust every file.

Large image files are one of the most common reasons a WordPress site loads slowly. Every time a visitor opens a page, their browser has to download each image. Smaller, optimized images load faster, reduce strain on your server, and improve user experience. 

To optimize images, you can:

  1. Install an image compression plugin like Smush, Imagify, or EWWW Image Optimizer that compresses images automatically when you upload them.
  2. Resize images before uploading them — for example, don’t upload a 4000px-wide photo if your theme only displays it at 1200px.
  3. Convert images to modern formats like WebP (supported by most browsers). Many optimization plugins can do this automatically.
  4. Run a bulk optimization through your plugin to compress old images already in your Media Library.

Learn more: How to optimize images for WordPress →

2. Implement caching

Difficulty: Beginner
Impact: High

Caching creates and serves stored versions of your web pages instead of generating them from scratch every time someone visits. In WordPress, a caching plugin can store copies of static files (like HTML, CSS, and images) so visitors get faster load times without waiting for the server to reprocess everything.

Without caching, each page load requires multiple database queries and script executions, which slow down your site—especially during traffic spikes. With caching enabled, most visitors see an instantly served copy, dramatically cutting down load times.

To enable caching on your WordPress site:

  1. Install a caching plugin such as WP Super Cache, W3 Total Cache, or LiteSpeed Cache.
  2. After activation, go to the plugin’s settings and turn on page caching.
  3. For extra speed, enable features like browser caching, object caching, or database caching (if your plugin and hosting provider support them).
  4. Test your site with tools like GTmetrix or PageSpeed Insights to confirm caching is working and making pages load faster.

3. Use a Content Delivery Network (CDN)

Difficulty: Beginner
Impact: High

A Content Delivery Network (CDN) is a global network of servers that stores copies of your website’s static files, like images, stylesheets, and JavaScript. When a visitor accesses your site, the CDN delivers content from the server closest to their location, reducing the distance data has to travel.

Using a CDN is important for WordPress speed because it decreases latency and ensures your content loads quickly for visitors worldwide. Without a CDN, someone far from your server might experience noticeable delays. 

A CDN also reduces the load on your main server, helping it handle more traffic without slowing down.

To set up a CDN:

  1. Sign up for a CDN service such as Cloudflare, Bunny.net, or KeyCDN. Many hosting providers also bundle CDN services into their plans.
  2. Connect your WordPress site to the CDN by changing your site’s DNS settings or using a plugin like CDN Enabler.
  3. Configure the CDN to cache static files and ensure it automatically purges old versions when you update content.
  4. Test your site again to make sure files are being served from the CDN instead of just your main hosting server.

4. Use a lightweight, speed-optimized theme

Difficulty: Beginner
Impact: High

A lightweight theme is built with minimal code, small CSS/JS files, and few bundled features you don’t need. Instead of shipping 20 page builders, sliders, and animation libraries, it focuses on clean templates, efficient queries, and smart use of the WordPress block editor. 

This matters because your theme sits on every page. Bloated themes add kilobytes (sometimes megabytes) of CSS and JavaScript to every request, increasing time to first byte (TTFB), delaying first contentful paint (FCP), and pushing out largest contentful paint (LCP). Less code = fewer bytes over the network, fewer parse/compile steps in the browser, fewer layout/paint cycles, and a faster site—especially on mobile and slower networks.

To choose a lightweight theme, look for: 

  1. Small install size
  2. Minimal render-blocking scripts
  3. Block/theme.json support
  4. Good Core Web Vitals test results on the theme’s own demo

5. Keep WordPress core, themes, and plugins updated

Difficulty: Beginner
Impact: Medium

Updates deliver security patches, bug fixes, new features, and performance improvements. Core updates often optimize internal APIs, database queries, and editor performance; plugin/theme updates can replace slow code paths, remove render-blocking assets, and add compatibility for newer PHP versions. 

WordPress also supports automatic updates, so you don’t have to manage everything manually.

A safe update workflow looks like this: 

  1. Back up your site (files + database). If possible, clone to staging. 
  2. In staging, go to Dashboard > Updates and apply updates for WordPress, then plugins, then themes. 
  3. Browse critical pages (home, blog, product, checkout, forms). Check console errors and layout issues.
  4. If all is well, repeat the same updates on production during a low-traffic window.

To enable auto-updates: 

  1. Core: Dashboard > Updates > “Enable automatic updates for all new versions of WordPress” (or in wp-config.php add define(‘WP_AUTO_UPDATE_CORE’, true);). 
  2. Plugins: Plugins > (for each) “Enable auto-updates.” c) 
  3. Themes: Appearance > Themes > (for each) “Enable auto-updates.”

Learn more: Enabling Automatic Updates in WordPress →

6. Run the latest PHP version

Difficulty: Moderate
Impact: High

PHP is the scripting language that runs WordPress. Each major PHP release brings big gains in execution speed, memory usage, type safety, and security hardening. 

WordPress runs on many PHP versions, but your goal is to use the latest stable version supported by WordPress core and your plugins/themes (commonly PHP 8.x). Even without changing a line of theme or plugin code, upgrading PHP can make every page render faster.

Upgrade safely with this flow: 

  1. Check your current PHP: Tools > Site Health > Info tab > Server (or ask your host).
  2. Back up your site and, if available, create a staging copy.
  3. On staging, switch PHP to the newest supported version:
    • cPanel: MultiPHP Manager > select domain > choose PHP version > Apply.
    • Plesk: Tools & Settings > PHP Settings (or Websites & Domains > PHP) > choose version > Apply.
    • Managed panels vary; look for a “PHP Version” selector per site.
  4. Visit key pages and run through critical flows (log in, contact form, checkout). Look for warnings/errors in the browser console and server error logs.
  5. If a plugin breaks, update it or replace it with a maintained alternative; contact the developer if needed.
  6. Switch production to the same PHP version during a low-traffic window.
  7. After switching, clear all caches (page cache, opcode cache if applicable, object cache) and warm up critical pages.
  8. Keep PHP updated going forward; plan to review supported versions at least twice a year so you don’t fall behind end-of-life timelines.

7. Minify and combine CSS, JavaScript, and HTML files

Difficulty: Moderate
Impact: Medium

Minification removes whitespace, comments, and other non-essential characters from code files (CSS, JavaScript, and HTML) without changing how they work. 

Combination (also called concatenation) merges many small files into fewer, larger files so the browser makes fewer requests. Most performance plugins can also defer or async JavaScript, generate critical CSS, and preload key assets so the page starts rendering sooner.

This speeds things up because browsers spend time downloading, parsing, and executing each asset. Fewer bytes and fewer round trips reduce network overhead and CPU work, improving First Contentful Paint (FCP) and Largest Contentful Paint (LCP). 

  1. Back up your site (files + database) and, if possible, create a staging copy.
  2. Pick your tool: If your host runs LiteSpeed, install “LiteSpeed Cache.” Otherwise, pair “Autoptimize” with “Async JavaScript,” or use an all-in-one like “WP Rocket.”
  3. Enable minification:
    1. In LiteSpeed Cache: Page Optimization > CSS/JS/HTML > turn on Minify for CSS, JS, and HTML. 
    2. In Autoptimize: tick “Optimize JavaScript Code,” “Optimize CSS Code,” and “Also optimize for logged-in users” (off on production).
  4. Combine cautiously:
    1. Turn on “Combine CSS” and “Combine JS” only if you have dozens of tiny files.
    2. If pages break (menus, sliders), add problem files to the plugin’s “Exclude” list (often jQuery or inline-critical files).
  5. Defer/async JS:
    1. Enable “Defer JS” or “Async JS” so noncritical scripts don’t block rendering. 
    2. Exclude critical libraries from deferral if functionality breaks.
  6. Generate critical CSS: Enable “Critical CSS” (plugin feature or paid add-on) so above-the-fold styles load fast while the rest is loaded later.
  7. Preload key assets:
    1. Preload your main font files and hero image if your plugin offers it. 
    2. Avoid over-preloading; keep it to a handful of truly critical assets.
  8. Edge minify (optional): If you use Cloudflare, enable “Auto Minify” for CSS/JS/HTML (don’t double-minify—disable minify in your plugin or at Cloudflare if you see issues).
  9. Test: Run PageSpeed Insights and WebPageTest before/after. Compare LCP, Total Blocking Time (TBT), and total transfer size.
  10. Roll out to production, clear all caches (plugin + CDN), then spot-check key pages. Keep a list of excluded files for future updates.

8. Optimize and clean up your WordPress database

Difficulty: Beginner
Impact: Medium

Your WordPress database stores posts, pages, comments, settings, revisions, transients (temporary cache entries), and data from plugins. Over time it accumulates “junk” like expired transients, spam/trashed comments, orphaned metadata, and overhead in MySQL tables. 

Database optimization removes this cruft and reclaims space, which helps queries run faster and keeps backups smaller.

  1. Back up your database (via your host, a backup plugin, or wp db export with WP-CLI).
  2. Choose a safe cleaner: “WP-Optimize,” “Advanced Database Cleaner,” or “WP-Sweep” are well-known and actively maintained.
  3. Start with read-only analysis:
    1. Install your chosen plugin on staging.
      1. Scan to see counts of revisions, auto-drafts, trashed posts, spam/trashed comments, expired transients, orphaned post/term/user meta, and table overhead.
  4. Clean conservatively:
    1. Remove spam/trashed comments, auto-drafts, expired transients, and post/term meta orphans. 
    2. Leave anything you’re unsure about; recheck site functionality after each batch.
  5. Optimize tables: Use the plugin’s “Optimize Tables” to run OPTIMIZE TABLE safely on InnoDB tables. If using phpMyAdmin: select your WordPress tables > With selected > Optimize table.
  6. Tame autoloaded options: In Advanced Database Cleaner, review large autoloaded options (>500 KB). If a plugin leaves huge autoloaded entries after removal, reinstall that plugin and properly uninstall, or consult the developer before deleting any option rows manually.
  7. Schedule maintenance: In WP-Optimize or Advanced Database Cleaner, schedule weekly or monthly cleanups for expired transients, trash, and spam. Exclude revisions here if you still need them (we’ll control the count in the next step).
  8. Verify performance: Use the Site Health “Database size” and your host’s metrics to confirm reductions. Re-test dynamic pages; compare TTFB and server CPU usage during traffic spikes.
  9. Power users (optional): With WP-CLI, run wp transient delete –expired and wp db optimize during low traffic. Always keep fresh backups.

9. Limit/control post revisions

Difficulty: Beginner
Impact: Low

Post revisions are snapshots WordPress saves each time you update content, plus periodic autosaves to prevent data loss. They’re useful for rolling back changes and seeing edit history, but on busy sites revisions can pile up, especially on long-form posts or products edited many times.

However, excessive revisions bloat the wp_posts table and related meta tables, increasing database size and the time needed to run queries and backups. Capping the number of revisions per post keeps history useful without letting thousands of extra rows slow down dynamic queries, editors, or backup/restore operations.

  1. Back up your database (important before changing revision behavior).
  2. Set a sensible cap in wp-config.php:
    1. Edit the file in your site root. 
    2. Above the line /* That’s all, stop editing! */ add:
      define(‘WP_POST_REVISIONS’, 5);
      This keeps the latest 5 revisions per post (adjust to your needs).
  3. Keep autosave reasonable (optional): add define(‘AUTOSAVE_INTERVAL’, 120); to set autosave to every 120 seconds instead of 60 (don’t disable autosave entirely).
  4. Control by post type (optional, no-code): install “WP Revisions Control,” then go to Settings > Writing and set different revision limits for posts, pages, and custom post types (e.g., products).
  5. Clean up existing bloat safely: Use “Advanced Database Cleaner,” “WP-Optimize,” or “WP-Sweep” to remove old revisions in bulk. Do this on staging first, then production during low traffic.
  6. Verify editors: open the block editor for a few posts and confirm the “Revisions” count shows your new cap taking effect after the next edit.

10. Use lazy loading for images and videos

Difficulty: Beginner
Impact: Medium

Lazy loading delays downloading offscreen images, iframes, and video players until they’re close to entering the viewport. WordPress natively adds loading=”lazy” to most images and many iframes, and plugins can extend this to background images and replace heavy YouTube/Vimeo players with lightweight “preview” thumbnails that only load the real player on click.

This helps because images and video are usually the heaviest assets on a page. By skipping them initially, the browser fetches fewer bytes, parses less markup, and renders meaningful content sooner—cutting bandwidth on every visit, especially on mobile and slower networks.

  1. Back up your site and, if possible, test changes on a staging copy.
  2. Turn on native lazy loading: update to a current WordPress version (5.5+ handles images; 5.7+ handles many iframes automatically).
  3. Add a lazy-load plugin for more control: install LiteSpeed Cache, Autoptimize (Images & Extra), a3 Lazy Load, WP Rocket, or Perfmatters.
  4. Exclude above-the-fold visuals: in your plugin, set “don’t lazy load first X images” (usually 1–2) so your hero/LCP image loads immediately.
  5. Optimize video embeds: enable “replace YouTube/Vimeo with preview image” (a.k.a. lazy load iframes/YouTube lite).
  6. Handle iframes and maps: lazy-load iframes; for Google Maps, use a static image preview that loads the live map on click.
  7. Address background images: if large CSS backgrounds are below the fold, use plugin support for lazy backgrounds or switch to standard <img> elements where possible.
  8. Test on mobile and desktop: scroll pages to confirm images/videos appear on time; tweak exclusions if content pops in too late.
  9. Deploy to production, clear caches (plugin + CDN), and recheck key templates (home, posts, product, checkout).

11. Remove unused or inactive plugins, themes, and widgets

Difficulty: Beginner
Impact: Medium

Plugins, themes, and widgets add features and design to WordPress, but inactive or unused ones leave code, database entries, and update checks behind. Over time this clutter can slow the admin, add autoloaded options, and create conflicts, even when something isn’t actively “on.”

Trimming what you don’t use reduces PHP work, memory usage, and requests for CSS/JS those tools inject. It also tightens security, simplifies updates, and can prevent extra HTTP requests on the frontend (icons, fonts, analytics, sliders) that drag down Core Web Vitals.

  1. Back up your site and, ideally, create a staging copy.
  2. Inventory usage: list each plugin’s purpose and where it’s needed (e.g., forms only on /contact). Flag duplicates and nice-to-haves.
  3. Deactivate candidates one at a time and browse key pages/forms to confirm nothing breaks.
  4. Delete safely: after deactivation, click “Delete” so WordPress removes files. Check docs for complex tools (forms/SEO/ecommerce) for uninstall steps.
  5. Clean leftovers: with Advanced Database Cleaner or WP-Optimize, remove orphaned tables/options created by deleted plugins (go slowly and retest).
  6. Consolidate functionality: prefer one well-maintained performance/utility plugin over many small ones.
  7. Review must-use (MU) and drop-in plugins: confirm each is necessary; ask your host before removing host-managed ones.
  8. Remove unused themes: keep only the active theme and one default (e.g., Twenty Twenty-Five) for fallback.
  9. Audit widgets/block areas: remove blocks/widgets you don’t use; empty sidebars that aren’t displayed.
  10. Schedule a quarterly audit to catch new clutter after redesigns or campaigns.

12. Reduce external scripts and HTTP requests

Difficulty: Moderate
Impact: High

External scripts are files your pages load from other domains—think analytics, chat widgets, ad pixels, social embeds, remote fonts, and A/B testing tools. Each one adds DNS lookups and network handshakes, and many inject render-blocking CSS/JS or heavy iframes that compete with your own assets.

Cutting these reduces request count, transfer size, and main-thread work, improving FCP/LCP and lowering Total Blocking Time. It also makes performance more stable: third-party slowdowns won’t tank your pages, and you’ll ship less code to visitors on mobile networks.

  1. Measure first: in Chrome DevTools > Network, load a key page and sort by Domain; note third-party size and timing.
  2. Remove non-essential third parties: uninstall/reconfigure plugins that inject chat, heatmaps, popups, or social feeds if they don’t serve clear goals.
  3. Host fonts locally or use a system-font stack; limit to the weights/styles you actually use.
  4. Load only where needed: use Perfmatters or Asset CleanUp (or plugin-specific toggles) to dequeue CSS/JS on pages that don’t use the feature.
  5. Defer/async and delay: set third-party JS to async/defer; consider “delay JS until user interaction” for noncritical tags (exclude essentials like anti-flicker for A/B tests).
  6. Replace heavy embeds: swap live social timelines/iframes for static images that link out; use lightweight YouTube/Vimeo previews that load the player on click.
  7. Keep tag managers lean: remove paused/unused tags, tighten triggers (e.g., fire conversions only on thank-you pages), and ensure tags load asynchronously.
  8. Add resource hints sparingly: preconnect/dns-prefetch only must-keep domains (e.g., your analytics endpoint).
  9. Disable WordPress extras you don’t use: via a performance plugin, turn off emojis, oEmbed discovery, and dashicons on the frontend.
  10. Re-test: compare request count, transfer size, LCP, and Total Blocking Time in PageSpeed Insights/WebPageTest; iterate until only necessary third-party requests remain.

13. Clean up your media library (delete unused files)

Difficulty: Beginner
Impact: Low

The Media Library stores every image, PDF, video, and file you upload. Over time it fills with unused items—duplicates, old hero images, cropped sizes you no longer need, and assets left behind by page builders or deactivated plugins. 

Some files show as “Unattached” (not linked to a post), though remember: a file can be used in a block, custom field, or slider and still appear unattached.

Old and unused files waste disk space, slow backups and restores, and can increase CPU and I/O when your host scans or backs up the wp-content/uploads folder. If your theme or plugins load media-based CSS/JS for galleries or sliders, stray media can also encourage unnecessary features to remain active. 

  1. Back up your site (files + database) and, if possible, work on a staging copy.
  2. Switch to list view: Media > Library > List view. Use the “Uploaded to” column to see whether a file is attached to a post; click a filename to open its details and copy the URL to search your site for references if you’re unsure.
  3. Filter for “Unattached” (if available in your install) and review carefully. A file can be used by a block, widget, or page builder and still be unattached; open a few representative posts/pages to confirm before deleting.
  4. Remove obvious junk: delete old logo drafts, outdated hero images, test uploads, and unused PDFs. Use “Delete permanently” to remove them from disk (they’ll skip the trash if you confirm).
  5. Scan for orphans with a cleaner: install a reputable tool such as Media Cleaner (Meow Apps). Run in “Test”/“Trash” mode first so it moves suspected-unused files to a temporary trash you can review. Restore anything misidentified, then finalize deletions.
  6. Tidy up image sizes: go to Settings > Media and set only the sizes you actually use. If your theme created many sizes you don’t need, consider a plugin that lets you disable extra sizes, then use Regenerate Thumbnails Advanced to remove old, unneeded sizes and regenerate only the ones you kept.
  7. Replace heavy files without breaking links: if you have very large images, use Enable Media Replace to upload optimized versions in place (same attachment ID), preserving existing references.
  8. Clear builder caches: if you use a page builder or gallery plugin, flush its cache after deletions so it doesn’t reference removed files.
  9. Repeat quarterly: schedule a reminder to review “Unattached,” large files, and new sizes, and keep your library lean.

Learn more: 7 best WordPress media library plugins →

14. Streamline/paginate comments (or disable if unnecessary)

Difficulty: Beginner
Impact: Low

Comments are WordPress’s built-in discussion system. They can be valuable on blogs and content sites, but they also add database queries, avatar lookups (Gravatar), spam checks, and pagination work. 

Heavy comment threads can slow page rendering (lots of DOM nodes), increase TTFB (extra queries), and add external requests (Gravatar, third-party scripts). Paginating comments limits how much the server and browser must process at once; disabling them on posts that don’t need discussion removes that work entirely.

  1. Back up your site (database especially), and consider testing on staging.
  2. Decide where comments are needed: go to Settings > Discussion and uncheck “Allow people to submit comments on new posts” if you don’t want comments sitewide; you can still enable them per post later.
  3. Disable on existing content in bulk: Posts > All Posts (and Pages) > select items > Bulk actions > Edit > “Comments: Do not allow.” Repeat for content types that don’t need discussion.
  4. Break big threads into pages: Settings > Discussion > check “Break comments into pages with X top-level comments per page,” set a sensible number (e.g., 20–50), and choose whether the first or last page shows by default. Verify that your theme renders comment pagination links.
  5. Reduce avatar overhead: in Settings > Discussion, uncheck “Show Avatars,” or keep them but choose a simple default. This cuts Gravatar lookups and image downloads.
  6. Turn off pingbacks/trackbacks: in Settings > Discussion, uncheck both boxes to avoid extra requests and noise.
  7. Auto-close on older posts: enable “Automatically close comments on articles older than X days” (e.g., 30–90) to prevent ballooning threads on old content.
  8. Cache comment pages: ensure your caching plugin caches paginated comment pages and purges the relevant page when a new comment is approved.
  9. Spot-check heavy posts: review load time and pagination on your largest threads; adjust per-page counts if UX or performance suffers.

15. Split/paginate long posts or content into multiple pages

Difficulty: Beginner
Impact: Low

Splitting long posts divides a single article into multiple pages, either with the Page Break block in the editor or the <!–nextpage–> tag in the content. It’s useful for very long guides, image-heavy tutorials, and posts with many embedded elements that strain the browser and server when delivered all at once.

Reducing the initial payload helps the first page render faster by shipping fewer images, scripts, and DOM nodes up front. Subsequent pages load on demand as the reader navigates, which can improve LCP/TBT on the first view—especially on mobile. 

Use this thoughtfully; readers prefer fewer clicks, so split only when the page is truly heavy.

  1. Back up your site and test on staging if available.
  2. Identify candidates: very long posts (3,000+ words), many images or embeds, or sections that naturally break into chapters/steps.
  3. Insert page breaks: in the block editor, add a “Page Break” block at logical section boundaries; or switch to the Code Editor and insert <!–nextpage–> on its own line. Save and preview to see the pagination links.
  4. Keep the first page lean: ensure your LCP element (usually the hero image or headline + intro) loads quickly; move heavy galleries and videos to later pages when possible.
  5. Add navigation aids: include a small table of contents at the top of page one with links to each page/section; many TOC plugins can link to /page/2/, /page/3/, etc.
  6. Verify theme support: most themes output wp_link_pages() automatically for paginated posts. If you don’t see navigation links, enable them in your theme template or site editor.
  7. Optimize images on later pages too: lazy load, compress, and serve proper sizes; splitting doesn’t replace basic image optimization.
  8. Consider prefetching next pages: some performance plugins let you prefetch the “Next” pagination link to make page 2 snappier without loading everything up front.
  9. Test UX and analytics: confirm pagination works with your cache/CDN, that each page is indexed as intended, and that readers can easily move forward/back. Adjust page breaks if bounce rate rises.

16. Disable hotlinking and leeching of content

Difficulty: Moderate
Impact: Low

Hotlinking is when another site embeds your images (or other media) by linking directly to your file URLs, so their traffic uses your bandwidth and server resources. 

“Leeching” is the same idea more broadly—others pulling your assets without hosting them themselves. 

Blocking hotlinking tells the server/CDN to refuse requests for your files when the visitor didn’t come from your own domain. Preventing hotlinking keeps your server and CDN from wasting bandwidth on other people’s pages, which reduces load, stabilizes response times during traffic spikes, and saves money on data transfer. 

It also helps your site remain fast for your own visitors on busy days when a popular forum post or scraper is pulling your images.

  1. Back up your site and confirm your CDN/domain setup (root domain, www, and any CDN subdomain like cdn.example.com).
  2. If you use Cloudflare: open Scrape Shield (or Security > WAF > Tools) and enable “Hotlink Protection.” Test by viewing one of your image URLs inside an HTML file hosted on a different domain; it should be blocked or replaced.

    If you use another CDN, enable their hotlink protection/“Referrer check” in the dashboard and add allowed referrers (your site + CDN hostname).
  3. Replace blocked files (optional): instead of 403, you can redirect hotlinked images to a tiny placeholder; keep it tasteful to avoid SEO issues.
  4. Test thoroughly: try direct image URLs in a private window, on and off your domain, and through your CDN URL. Confirm your own pages still display images normally.
  5. Monitor logs/bandwidth: check your host/CDN analytics for reduced external referrers and lower image egress over the next week.

17. Reduce unnecessary database calls and use database caching

Difficulty: Pro
Impact: Medium

Database calls are the queries WordPress runs to fetch posts, settings, user data, etc. Many plugins and themes run extra queries—sometimes repeatedly—on every page load. “Database caching” in WordPress typically means the object cache: storing query results and computed data in memory (e.g., Redis or Memcached) so they can be reused without hitting MySQL each time.

Fewer and faster queries lower server work and TTFB, especially on dynamic pages (search, account, cart, checkout) that can’t be fully page-cached. 

  1. Back up your site and, if possible, use a staging copy for changes.
  2. Profile queries: install Query Monitor and load key pages (home, a heavy post, product, checkout). Note total queries, duplicates, and the slowest queries; identify the plugin/theme responsible.
  3. Remove or replace offenders: if a plugin triggers lots of duplicate/slow queries and has an alternative, switch. Turn off features you don’t use (e.g., related posts, “views” counters) that query every page.
  4. Enable a persistent object cache:
    • If your host offers Redis/Memcached, enable it in your control panel.
    • Install “Redis Object Cache” (or use LiteSpeed Cache/W3 Total Cache’s Object Cache). Connect to the Redis server (host/port or socket), click “Enable Object Cache,” and confirm the object-cache.php drop-in is active.
    • Verify a rising “cache hit ratio” in the plugin’s dashboard after some traffic.
  5. Cache expensive operations: for pricey queries (like complex WP_Query or remote API calls), use transients or wp_cache_set/wp_cache_get in custom code; set reasonable expirations so content stays fresh.
  6. Reduce autoloaded options: big wp_options entries set to autoload = yes load on every request. Use a database cleaner to find oversized autoloaded rows and remove leftovers from deleted plugins (cautiously—test first).
  7. Avoid query anti-patterns: don’t call get_option()/get_post_meta() thousands of times in loops; fetch in batches, or prefetch via a single query if you’re writing custom code.
  8. Tune WooCommerce (if used): disable cart fragments on non-cart/checkout pages via your performance plugin; use object caching so product/price/meta queries are reused efficiently.
  9. Index and optimize tables (advanced): ensure large custom tables have useful indexes; run OPTIMIZE TABLE via a plugin or host tool during low traffic.
  10. Re-test with Query Monitor: compare total/duplicate queries and TTFB before/after. Aim for fewer queries and a healthy object-cache hit rate (>60% on busy pages).

18. Remove or defer render-blocking JavaScript and CSS

Difficulty: Moderate
Impact: High

Render-blocking resources are files that stop the browser from painting the page until they’re downloaded and processed. By default, CSS blocks rendering; synchronous <script> tags block the HTML parser. 

“Deferring” JS tells the browser to continue parsing and run the script later; “async” runs it when it arrives. “Critical CSS” inlines just the minimal styles needed for above-the-fold content, loading the rest later.

Eliminating or delaying these blocks improves First Contentful Paint and Largest Contentful Paint because the browser can show useful content sooner. You’ll also cut Total Blocking Time by delaying heavy, nonessential scripts, which makes pages feel responsive faster—especially on mobile connections.

  1. Back up your site and work on staging if available.
  2. Audit blockers: run PageSpeed Insights and open Chrome DevTools > Coverage to see CSS/JS that blocks rendering and how much is unused.
  3. Enable CSS optimization: in your performance plugin (LiteSpeed Cache, WP Rocket, Autoptimize, Perfmatters), turn on “Optimize CSS delivery” or “Generate Critical CSS.” This inlines above-the-fold styles and loads the rest later.
  4. Remove unused CSS (carefully): enable “Remove Unused CSS” (RUCSS/UCSS). Start with a few templates (home, post, product), test thoroughly for styling regressions, and add exclusions for classes/IDs that are added dynamically (menus, sliders).
  5. Defer JavaScript: enable “Defer JS” or set scripts to load in the footer. If your tool supports it, also “Delay JS execution until user interaction” for noncritical scripts (analytics, social widgets, heatmaps).
  6. Handle dependencies: exclude core libraries that must run early (often jquery.min.js and anything inline that depends on it) from defer/delay; or convert dependent plugins to no-jQuery modes if offered.
  7. Combine judiciously: if you have dozens of tiny files, enable “Combine CSS/JS.” If bundles become too large or sourcemaps break, turn combination off (HTTP/2/3 handles many parallel requests well).
  8. Prioritize key assets: preload your main stylesheet or critical font files, and ensure your LCP image isn’t delayed (set fetchpriority=”high” on the hero image if your theme supports it).
  9. Tame third-party scripts: set external widgets to async or delay them; replace heavy embeds with “lite” versions that load on click (e.g., YouTube).
  10. Test for FOUC/FOUT: browse pages on mobile and desktop; if you see unstyled content flashes, widen the critical CSS and/or exclude the main stylesheet from delay.
  11. Clear caches (plugin + CDN) and re-measure: compare FCP, LCP, and Total Blocking Time before/after in PageSpeed Insights and WebPageTest; iterate exclusions until everything renders correctly and quickly.

19. Reduce redirects

Difficulty: Beginner
Impact: Medium

A redirect sends visitors from one URL to another (e.g., http:// → https://, example.com → www.example.com, old slugs to new ones). They’re useful for SEO and avoiding 404s, but each hop adds an extra round trip before the browser can request the final page, which increases latency and delays. 

Short, single-hop rules (or no redirect at all) keep navigation snappy and reduce wasted network requests.

  1. Inventory your redirects: open your homepage and a few key pages in Chrome DevTools > Network and look for 301/302 responses and chains. Also run PageSpeed Insights or WebPageTest to surface redirect chains.
  2. Fix site-level canonical settings: in Settings > General, set your preferred WordPress and Site Address (either https://example.com or https://www.example.com). Make sure they match what you actually want to serve.
  3. Collapse to one hop: combine http→https and www↔non-www into a single rule, not two.
  4. Update internal links and assets: search/replace old URLs in your database (use Better Search Replace or WP-CLI wp search-replace) so menus, images, CSS, and canonical tags already point to the final URLs.
  5. Prune plugin rules: in Redirection (or your redirect plugin), delete rules for URLs that no longer receive traffic; merge overlapping patterns to avoid rule-by-rule hops.
  6. Fix trailing slashes and uppercase/lowercase: choose a convention (usually lowercase with trailing slash for directories) and normalize with one rule. Update links to match.
  7. Watch UTM and tracking params: ensure your rules preserve query strings so you don’t bounce users through multiple destinations.
  8. Re-test: confirm only one 301 occurs (at most) before the final 200. Check key templates, old slugs, and campaign URLs.
  9. Cache and CDN: enable “Always Use HTTPS”/canonical host at the edge (if offered) so a single redirect happens at the closest location, not your origin.

20. Consider your hosting infrastructure

Difficulty: Moderate
Impact: High

“Infrastructure” is the hardware and software stack powering your site: CPU, RAM, storage (SATA SSD vs NVMe), web server (LiteSpeed/NGINX/Apache), PHP workers, database version/engine, and network. Even on the same host, a plan with more PHP workers, NVMe storage, and Redis can outperform a budget tier by a wide margin.

If your server is saturated, no amount of front-end tuning will fix slow time to first byte or failures under traffic spikes. Upgrading to better WordPress hosting removes CPU/RAM bottlenecks, reduces disk I/O wait with faster NVMe storage, adds concurrency via more PHP workers, and unlocks features like object caching and HTTP/3 that shave milliseconds on every request.

  1. Benchmark the symptoms: run PageSpeed Insights and note TTFB; use your host’s metrics or a monitor (UptimeRobot/New Relic/host panel) to check CPU, memory, and I/O during traffic. If TTFB is high even on simple pages, you’re resource-bound.
  2. Right-size PHP workers: for dynamic sites (WooCommerce, membership), increase PHP workers so concurrent users don’t queue. Ask your host how many workers your plan includes and what upgrade path exists.
  3. Prefer NVMe storage: upgrade from HDD/SATA SSD to NVMe for faster database and file access, especially on uncached requests and admin/editor actions.
  4. Choose a faster web stack: LiteSpeed or NGINX with HTTP/3 and Brotli typically outperforms basic Apache on busy WordPress sites; switch plans or providers if necessary.
  5. Turn on a persistent object cache: add Redis or Memcached (often an add-on). This cuts database trips on dynamic pages.
  6. Use the latest runtimes: run PHP 8.x with OPcache enabled, and current MySQL/MariaDB versions; ask your host to move you to a newer stack if yours is pinned.
  7. Separate tiers when needed: on heavy stores, move the database to a dedicated instance on the same LAN/region and keep Redis close to the app.
  8. Add a CDN for global users: offload static assets to a CDN with HTTP/3; keep origin fast for personalized/dynamic pages.
  9. Re-test after changes: compare TTFB, server CPU usage, and checkout/account page latency under a simple load test (20–50 virtual users) before and after upgrading.

21. Choose a reliable, fast hosting provider

Difficulty: Beginner
Impact: High

A fast provider offers modern hardware (NVMe, ample RAM/CPU), an optimized web/PHP stack, edge/CDN integration, and WordPress-specific tooling (staging, backups, malware protection). 

“Reliable” means consistent performance under load, strong uptime SLAs, responsive support, and transparent resource allocations (e.g., PHP workers, bandwidth).

The right provider prevents bottlenecks you can’t fix at the application level. Lower TTFB, better concurrency, and built-in caching/object cache/CDN support improve Core Web Vitals sitewide and reduce the time you spend firefighting performance issues.

  1. Define your needs: traffic pattern, logged-in usage, ecommerce, geographic audience, and budget. Dynamic sites need more CPU, PHP workers, and Redis than simple blogs.
  2. Check the stack: look for HTTP/3 + Brotli, LiteSpeed or tuned NGINX, PHP 8.x with OPcache, Redis/Memcached, and current MySQL/MariaDB. Prefer NVMe storage.
  3. Evaluate WordPress tooling: staging with push/pull, automated backups with retention, Web Application Firewall, malware scanning, and one-click Redis.
  4. Inspect resource policies: how many PHP workers, any burst capacity, bandwidth limits, and how throttling works. Transparent limits beat “unlimited.”
  5. Test before you commit: deploy a staging copy to a trial or month-to-month plan. Measure TTFB from your target regions and run through checkout/account flows.
  6. Review uptime/support: verify a 99.9%+ SLA, 24/7 knowledgeable support, and clear escalation paths.
  7. Consider data locality: ensure the provider has a data center near your audience and supports moving regions later without downtime.
  8. Confirm security and reliability: DDoS protection, automatic patching, isolation between tenants, and backups you can restore yourself.
  9. Plan for growth: make sure you can scale vertically (more CPU/RAM/workers) or horizontally (load balancer, multiple app nodes) without replatforming.

Learn more: How to choose hosting for WordPress →

22. Ask your host about speed/performance features 

Difficulty: Beginner
Impact: Medium

Hosts often include optimization features you can toggle: full-page caching, edge caching, Redis/Memcached object cache, image optimization, Brotli compression, HTTP/3/QUIC, database optimization tools, PHP worker tuning, and “delay JS/critical CSS” integrations.

Some bundle add-ons branded as “page speed” or “performance boost” suites.

Turning on the right features can deliver big wins without extra plugins or code. Edge caching reduces origin load and latency, object caching speeds dynamic pages, and compression/HTTP/3 shrinks and accelerates asset delivery—lifting Core Web Vitals with minimal effort.

  1. Make a checklist: caching (page + edge), object cache (Redis/Memcached), image optimization/WebP, Brotli + HTTP/3, CDN integration, PHP worker controls, automatic database optimization, and performance analytics.
  2. Contact support or open docs: ask which features are available on your plan, how to enable them, and whether they conflict with existing plugins. Mention any branded speed boosts available on your platform.
  3. Enable page caching: turn it on at the platform level if offered, then disable duplicate caching in plugins to avoid double-caching. Verify cache headers in DevTools (cache, age).
  4. Enable object caching: toggle Redis/Memcached, install the companion plugin if required, and confirm the object-cache.php drop-in is active.
  5. Turn on compression and HTTP/3: ensure Brotli (or Gzip) and HTTP/3/QUIC are active at the edge/origin.
  6. Image optimization/CDN: activate built-in WebP and resizing if your host/CDN supports it; set a sensible max width and automatic compression.
  7. Edge caching rules: cache anonymous pages at the edge, bypass for logged-in users, carts, and checkouts; add smart purge rules tied to content edits.
  8. Tune PHP workers and timeouts: request more workers if you see queueing; ensure timeouts are appropriate for your heaviest operations.
  9. Verify results: test before/after for TTFB/LCP and check error logs for conflicts. Keep notes on what you enabled in case you need to roll back.

23. Ensure database and site are in the same data center

Difficulty: Pro
Impact: High

Your WordPress app (PHP) and database (MySQL/MariaDB) should live in the same data center or at least the same region/availability zone with low-latency private networking. Many shared/managed plans keep them on the same machine by default; performance issues arise when the database is on a remote network or different region.

“Reliable” means consistent performance under load, strong uptime SLAs, responsive support, and transparent resource allocations (e.g., PHP workers, bandwidth).

Every query crossing regions adds tens to hundreds of milliseconds of latency and increases the chance of packet loss and timeouts under load. Keeping app and DB co-located (and on the same private network) lowers TTFB for uncached pages and reduces variability during traffic spikes.

  1. Identify your DB host: in wp-config.php, check DB_HOST. If it’s a hostname/IP that isn’t local (like 127.0.0.1 or localhost), note it.
  2. Resolve the DB location: run dig DB_HOST (or ask your host) to find the region/data center. In managed clouds (e.g., “us-east-1”), confirm the exact zone.
  3. Ask your host to confirm: request written confirmation that your app and DB run in the same data center (or same region/AZ) and communicate over private networking, not the public internet.
  4. Lock down networking: ensure the DB only accepts connections from your app’s private IP(s); disable public exposure where possible.
  5. Tune for low latency: enable a persistent object cache (Redis) to reduce round trips; keep PHP 8.x and OPcache on to minimize compute time per request.
  6. Test improvements: measure TTFB on an uncached page (e.g., a logged-in dashboard) before and after co-locating. Use mysqladmin status or your host’s metrics to watch query times drop.
  7. Plan for HA carefully: if you use multi-AZ or cross-region replicas for resilience, direct reads/writes to the local primary and reserve remote replicas for failover—don’t point production traffic across regions.

24. Use faster, well-coded plugins and avoid poorly performing ones

Difficulty: Beginner
Impact: Medium

“Faster, well-coded” plugins follow WordPress coding standards, load assets only where needed, minimize database queries, and stay actively maintained. Poorly performing plugins often enqueue large CSS/JS on every page, make duplicate queries, or run heavy tasks on each request.

  1. Make a list of what each plugin does and on which pages you actually need it.
  2. Check quality signals: last updated date (active maintenance), recent reviews, support responses, and tested WordPress/PHP versions.
  3. Test performance: install Query Monitor and open a few key pages; note total queries and slow/duplicate queries by plugin.
  4. Try lighter alternatives for heavy categories (forms, sliders, analytics, builders) and re-test the same pages.
  5. Keep only one plugin per job (e.g., one SEO plugin, one caching plugin) to avoid overlap.
  6. Load conditionally when possible (some plugins have a “load assets only where used” toggle; otherwise use an asset manager plugin).
  7. Remove anything you don’t need; then clear caches and re-check Core Web Vitals.

Learn more:  How to find slow plugins →

25. Remove useless social sharing buttons

Difficulty: Beginner
Impact: Low

Social sharing buttons add clickable icons and counters for networks like Facebook, X, LinkedIn, and Pinterest. Many include third-party scripts or iframes to track shares and show counts.

Those extras add external requests, JavaScript execution, and layout shifts, all of which can hurt Core Web Vitals. If your audience rarely uses them—or they appear on pages where sharing isn’t relevant—they’re just performance drag.

  1. Decide where sharing actually matters (usually blog posts, not home, product, or checkout).
  2. If a plugin injects buttons everywhere, turn off sitewide display and enable only on posts.
  3. Prefer lightweight buttons: static SVG icons that link to each network’s share URL (no counters, no third-party JS).
  4. Remove counters and follow widgets; they’re the heaviest part.
  5. If you must keep a plugin, disable networks you don’t use and enable “load JS async/defer” or “delay until interaction.”
  6. Re-test the same pages (before/after) to confirm lower request count and faster LCP/TBT.

26. Disable pingbacks and trackbacks

Difficulty: Beginner
Impact: Low

Pingbacks/trackbacks are old notification systems that try to alert a site when another site links to it. They arrive via XML-RPC and often become spam or needless database entries.

Disabling them reduces background requests and spam processing, cutting database work and eliminating a common slow path and attack surface—good for stability and speed under load.

  1. Go to Settings > Discussion and uncheck both “Allow link notifications from other blogs (pingbacks and trackbacks)” and “Attempt to notify any blogs linked to from the post.”
  2. Bulk-disable on existing content: Posts > All Posts (and Pages) > Bulk actions > Edit > Pings: Do not allow.
  3. Reduce XML-RPC exposure: if you don’t use apps/Jetpack, block xmlrpc.php at the server or with your security tool; keep REST API on.
  4. Clear out pending spam in Comments and trash it.
  5. Re-test performance on heavy posts and watch for fewer background hits in logs.

27. Use a DNS-level firewall

Difficulty: Moderate
Impact: High

A DNS-level firewall (often via a CDN like Cloudflare, Akamai, or Bunny) sits in front of your site. Traffic goes to the provider first, where bad bots and attacks are filtered, and static assets can be cached at edge locations near visitors.

Blocking junk traffic before it reaches your server preserves CPU/RAM for real users and shortens distance with edge caching, improving TTFB and overall stability during traffic spikes or attacks.

  1. Pick a reputable provider (Cloudflare is a common starting point). Create an account and add your domain.
  2. Import DNS records and change nameservers at your registrar to the provider’s nameservers.
  3. Enable the Web Application Firewall (WAF), bot protection, and basic rate limiting.
  4. Turn on CDN caching for anonymous pages; bypass cache for logged-in users, carts, and checkouts.
  5. Enable Brotli compression and HTTP/3/QUIC.
  6. Set SSL mode to “Full (strict)” with a valid certificate at your origin.
  7. Add page rules/security rules only where needed (login/admin tighter; public pages more permissive).
  8. Test from multiple regions for TTFB and verify that the edge cache is serving public pages.

Learn more: What is a web application firewall for WordPress? →

28. Fix HTTPS/SSL errors without plugins

Difficulty: Moderate
Impact: Medium

HTTPS uses an SSL/TLS certificate so your site loads securely at https://. Common issues include missing/expired certificates and “mixed content” (pages served over HTTPS but loading images/CSS/JS over HTTP).

Fixing HTTPS errors prevents redirect loops and blocked assets that slow or break rendering. A clean HTTPS setup lets you use HTTP/2/3, improves caching reliability, and avoids extra round trips caused by mixed content and certificate warnings.

  1. Install a valid certificate at your host (Let’s Encrypt or commercial) and confirm it covers your domain and www/non-www.
  2. Set WordPress Address (URL) and Site Address (URL) to https://… in Settings > General.
  3. Update internal links: use Better Search Replace (or WP-CLI) to replace http://yourdomain.com with https://yourdomain.com in the database.
  4. Force HTTPS once: add a single 301 rule (Apache .htaccess or Nginx server block) from HTTP to HTTPS—avoid multiple chained redirects.
  5. Fix mixed content: open DevTools > Console, reload, and note any blocked http:// assets. Update theme/plugin settings or media links to HTTPS; for hardcoded URLs, edit templates or CSS.
  6. Use protocol-relative or root-relative URLs for custom assets to avoid future mixed content.
  7. (Optional) Enable HSTS to enforce HTTPS: send the Strict-Transport-Security header after you’re sure everything works over HTTPS.
  8. Clear all caches (plugin, CDN, browser) and re-test pages, images, and admin login over HTTPS only.

Learn more:  How to force HTTPS in WordPress →

29. Conduct site speed diagnostics regularly

Difficulty: Beginner
Impact: Medium

“Site speed diagnostics” means running tests and checks (PageSpeed Insights, WebPageTest, Lighthouse, Chrome DevTools) on key templates—home, post/product, cart/checkout—to measure metrics like LCP, INP, CLS, and TTFB, then inspecting waterfalls to see which files or third parties slow things down.

Doing this on a schedule catches regressions early, shows which fixes actually move the needle, and keeps Core Web Vitals healthy. Regular testing prevents silent bloat from new plugins, design changes, or marketing tags that can degrade performance over time.

  1. Pick tools: PageSpeed Insights for lab + field data, WebPageTest for waterfalls, and Search Console’s Core Web Vitals report for real-user trends.
  2. Define a test set: one URL per template (home, blog/product, checkout/account). Test mobile first.
  3. Run baseline tests and note LCP, INP, CLS, TTFB, total bytes, and request count. Save screenshots/URLs.
  4. Use waterfalls/Coverage to spot culprits (large images, render-blocking CSS/JS, slow third parties).
  5. Fix the top 1–2 issues, then re-test the same pages to confirm improvement.
  6. Set performance budgets (e.g., LCP < 2.5s, CLS < 0.1, total JS < 300KB) and test monthly—or after any big theme/plugin change.

30. Use third-party platforms for heavy media (YouTube, Vimeo, SoundCloud)

Difficulty: Beginner
Impact: Medium

Video/audio hosting platforms stream media efficiently using global CDNs and adaptive bitrates. Instead of serving large MP4/MP3 files from your server, you embed the player from YouTube/Vimeo/SoundCloud so their network does the heavy lifting.

Offloading big media cuts bandwidth and CPU on your host, avoids timeouts, and reduces page weight. With lazy-loading or “lite” embeds, the full player doesn’t load until a user interacts, improving LCP and Total Blocking Time.

  1. Upload videos to YouTube or Vimeo; upload audio to SoundCloud (or a similar, reputable service).
  2. Copy the share/embed code and paste it into your post/page. Prefer the privacy-enhanced option (e.g., youtube-nocookie.com) when available.
  3. Enable lazy loading/“lite” embeds via your performance plugin so the page shows a thumbnail and loads the player on click.
  4. Replace any self-hosted media links with embeds, keeping captions/transcripts for accessibility and SEO.
  5. Test playback on mobile/desktop and confirm the page’s request count and LCP improve.

32. Optimize homepage for speed (use excerpts, limit posts per page)

Difficulty: Beginner
Impact: Medium

Your homepage is often the highest-traffic page. Optimizing it means showing only essential content, using short excerpts instead of full posts, limiting how many items appear, and avoiding heavy widgets, sliders, or multiple large videos.

A lean homepage reduces initial bytes, DOM size, and queries, which improves LCP and keeps the main thread free. It also makes caching more effective and prevents third-party bloat from dragging down your most important page.

  1. Decide on layout: consider a static homepage with a focused hero, short intro, and key links instead of a long blog roll.
  2. Limit content: Settings > Reading > “Blog pages show at most” set to ~6–9 posts. In your theme settings, show excerpts (not full content).
  3. Trim heavy elements: remove sliders/carousels and auto-playing videos; keep one optimized hero image as the LCP element.
  4. Lazy load images/embeds and ensure critical CSS is enabled so above-the-fold content renders immediately.
  5. Cache aggressively and serve via CDN; prefetch key internal routes (e.g., /blog/, /shop/) if your performance tool supports it.
  6. Re-test LCP/CLS and verify the hero image loads quickly on mobile.

33. Optimize Google Fonts (or host fonts locally)

Difficulty: Moderate
Impact: Medium

Google Fonts are web fonts loaded from Google’s servers. They look great but can add extra HTTP requests and delay text rendering. Optimization means limiting families/weights, controlling how text displays while fonts load, and optionally self-hosting the exact files you need.

  1. Inventory usage: keep to 1–2 families and only the weights/styles you actually use (e.g., 400/700).
  2. Ensure font-display: swap (theme or performance plugin setting) so system text shows immediately while web fonts load.
  3. If staying on Google-hosted fonts, add preconnect for fonts.gstatic.com (many performance plugins expose a “Resource Hints” field).
  4. To self-host, download WOFF2 files for the needed subsets (e.g., Latin) and enqueue them with @font-face in your theme or a fonts plugin.
  5. Preload your primary WOFF2 files (<link rel=”preload” as=”font” type=”font/woff2″ crossorigin>) so the hero text renders quickly.
  6. Test on mobile: confirm text renders immediately (no FOIT) and that total font bytes are minimized; fall back to a system-font stack if you can’t justify custom fonts.

WordPress site speed FAQs

Speed matters because it directly affects user experience, SEO rankings, and conversions. Visitors often leave if a page takes more than a few seconds to load. For businesses, this can mean losing customers before they even see your product or service.

Search engines like Google also rank faster websites higher, so optimizing speed improves both visibility and engagement.

You can test your website speed with tools like Google PageSpeed Insights, GTmetrix, and Pingdom.

These tools don’t just measure how quickly your site loads, but also provide detailed suggestions for improvement. They evaluate factors like server response time, file sizes, caching, and image optimization so you know exactly what’s slowing your site down.

Several issues can drag down performance. Common causes include:

  • Large unoptimized images
  • Too many active plugins
  • Bloated themes with unnecessary features
  • Uncleaned databases. 
  • Poor-quality hosting

Additionally, not using caching or a CDN forces every visitor to load content directly from your server, which increases load times.

There isn’t a single best option for everyone, but some popular caching and optimization plugins include WP Rocket, W3 Total Cache, and WP Super Cache.

  • WP Rocket is known for its user-friendly setup and all-in-one optimization features, though it’s paid.
  • W3 Total Cache and WP Super Cache are free, powerful, and widely used.

The right choice depends on your needs and budget, but installing a caching plugin is one of the easiest ways to speed up your site.

Additional resources

Easy SEO for WordPress: 7 things to try →

The goal of SEO is to get more people to find your website through search engines, and thus drive more traffic to your website. 

WordPress speed optimization 101: Performance tuning →

If your site isn’t getting the attention you think it deserves, you may need to learn how to create a WordPress performance tuning strategy.

Best SEO plugins for WooCommerce sites →

In this article, we’re going to talk about the two best WordPress plugins for improving SEO on WooCommerce sites.

Originally from Albuquerque, New Mexico, Leslie Bowman has hopped around the country since graduating from undergrad. She focused on English and Latin American History in college and eventually attended graduate school in New York City. There, she developed a passion for short, persuasive arguments. Bowman found a love of copywriting and is now a Senior Copywriter at Liquid Web.