WordPress website uses multiple page requests to display site content to the visitor. Performing multiple page requests will make your website load slow. Reduce page requests and optimize its delivery to speed up your website and load it in less than 2 seconds.
2 seconds are the maximum time by which your content should be displayed to the site visitor.
There are multiple asset delivery optimization techniques including reduction number of requests, size of requests and time of requesting page assets. All of this will help to show initial content as fast as possible so visitors can consume your content without waiting much.
Before starting request optimization and reduction for WordPress websites let’s make clear what are page requests, why reduce them and how to analyze request information for any web page.
Table of Contents
What are page requests?
Page requests are additional files loaded with web pages. They are used to style pages (css files and fonts), add client side functionality (JavaScript files), and enrich page information with media files like images and videos.
Common page request file types that most websites will load 99% of time:
- Images – .jpg, .gif, .png
- JavaScript – .js
- Stylesheet – .css
- Fonts
- Video & audio files – .mp3, .mp4
When a web page is loaded it will need all related files to be loaded as well. So for example page will ask for theme .css file then theme .js file, then some image.jpg. Then maybe it will ask for other css and js files provided by WordPress themes. Then will load all images (20-100 files).
When page requests are not optimized, site visitors will wait until multiple files around 50-100 files to be requested and loaded before any content is shown to them. This will take 5-10 seconds to load on a mobile device.
Page requests are also known as page assets or http requests.
WordPress has different functionality with a similar name known as WP_HTTP Requests. WP_HTTP Requests are used to communicate to remote API servers within PHP files. Which should not be confused with page requests which are handled by a web browser. Learn more about the difference between WP_HTTP Requests vs Page Requests here.
Why reduce page requests?
Page requests are used to load page assets for displaying complete web pages. When there are too many page requests, the page will load after completing all those requests. For example page with 100 requests will load slower than page with 10 requests.
Unoptimized WordPress pages generally can have too many requests. Because every plugin can add additional CSS and JavaScript files. Also long form blog content and blog category pages may have many images as well.
Check before and after page requests optimization report generated by gtmetrix.
When you optimize page requests WordPress pages will load much faster and site visitors will be happy to read your blog.
How to view page requests?
To check if your pages are slow because of having too many page requests you can use free online measurement tools or use web developer tools by pressing F12 in your chrome browser.
If you prefer using chrome web developer tools then make sure that you are visiting your blog in an incognito window without logging in. That is how most site visitors will see your blog.
To measure page requests more precisely you can use Gtmetrix or WebPageTest free page speed measurement tool. It will show how each page request loaded and how much blog content was delayed because of those page requests.
After the test is finished summary of requests will be shown at the bottom of the page titled as “Page details”. To view each request and filter by file type navigate to the “Waterfall” tab. Use search input in waterfall to filter requests by typing in theme or plugins.
Similar waterfall reports can be generated using WebPageTest tool as well. Check more tools to measure website speed.
How to optimize page requests?
We learned that page requests are the main reason for slow web pages. To speed up page load times we need to optimize page requests without harming page functionality.
Methods to speed up page load by optimizing page requests.
- Reduce the number of requests – pages with few requests load faster than pages with hundreds of requests. For example optimized pages with 10 requests will load faster than a page with 100 requests.
- Reduce size of request – small files complete downloading faster than big files.
- Delay render blocking requests – load requests only when needed. This will render and display pages much faster without downloading files that are not needed for displaying initial page content.
To apply these optimizations to page requests there are different methods for each request type. Lets see how each request can be reduced and optimized.
Reduce requests by removing unused JavaScript and CSS
WordPress core has some features that are not used on modern browsers. For example WordPress uses JavaScript to add emoji support for old browsers. It adds extra JavaScript requests to every page of your website. You can safely remove it using the Disable Emojis plugin. Plugin automatically works when activated without any settings.
Load plugins only on related pages
Similar to emojis you can disable certain plugin features on unrelated pages. You can disable other plugins on blog pages as well. For example I am using the bbPress forum which is not used on all pages. I can safely disable bbPress on all other pages except forum pages.
For restricting some plugins to related pages only I use the “Plugin Load Filter” plugin. Other alternatives are: Plugin Organizer , Freesoul Deactivate Plugins , Plugin Logic.
Same principle applies to contact form plugin, woocommerce, buddypress, download monitor plugins as well. You can enable them only on related page types or per individual page.
Replace plugins with simple html widgets
Regular social sharing plugins rely on using additional JavaScript and CSS files.
If you are using social sharing plugins then replace it with inline native share widget. Native social share widget works with inline code and does not use additional page requests.
Reduce requests by reducing plugin usage
Some plugins use css and js files in the front end to add extra functionalities. Try to reduce plugin usage and replace them with faster alternatives.
For example if you have 20 plugins and 10 of them adding additional page requests. Then reducing plugins with page requests will also reduce overall page requests for your WordPress website.
Learn how to reduce plugin usage on the WordPress website.
Reduce number of requests by merging (combining) files
WordPress pages can have multiple CSS and JavaScript files. This can be because of not optimized themes and using multiple plugins that require additional javascript and css files.
After removing unnecessary JavaScript and CSS files if you still have many page requests then you can merge multiple files into one.
Before merging you may have more than 10 .js and .css files. After merging you will have one or two .css and .js files.
There are many popular asset (.js and .css files) merging plugins. I use the Fast Velocity Minify plugin for merging files. I like that it has the feature to keep merged files cached for one week. It makes sure that your blog will not load unformatted pages due to missing merged files.
Alternatives to Fast Velocity Minify plugin are listed below.
Test asset merging plugin thoroughly to make sure that all pages are fully functional and pages are loading fast.
Merging page requests should be applied after removing unused requests. If after removing requests you still have too many page requests only then use merging them.
Only internal requests, requests that load from your web server, can be merged. External requests like google analytics, adsense, google fonts etc. cannot be merged. You can optimize external requests by delaying them which I explain below in the article.
Reduce request size by minification and compression
Reduce css and js file size with minification and compression. Regular javascript, CSS and HTML files can reach a couple megabytes file size in total. Big data size is slow to download which will delay page load time. To optimize website speed you have to compress and minify all text based page assets including HTML document files.
Text based content can be compressed and minified.
What is the difference between compression and minification?
- Minification – remove empty spaces from text documents. Also rewrites some .css and .js files to reduce character count of the document without affecting its functionality. You can expect 2x reduction with minification.
- Compression – reduce file size with gzip. You can expect from 4x to 6x size reduction with compression.
- Minification + Compression – will give maximum size reduction to your page requests. You can expect 6x to 10x size reduction when applied together.
Now lets see how to apply minification and compression to page requests for WordPress website.
How to reduce request size?
- Server side compression – gzip compression performed by server software like apache and nginx. Prefer using server side compression because it is fast and does not use much server resources. Most popular WordPress hosting providers have server side compression enabled automatically. You do not have to do anything if server side compression is enabled. If it is not enabled on your server then ask your hosting support to enable text compression in your server.
- Compress and minify using Cloudflare CDN servers. Cloudflare has a feature to compress and minify page requests on their servers. If your blog uses cloudflare services then enable minification and compression using corresponding options in cloudflare user interface.
- Compress and minify inside WordPress using plugins. Use only when none of the above compression methods are available. This is the slowest solution and will use more server resources compared to other solutions. But it is still better than serving content and page assets without any compression. Asset merging plugins mentioned above (Fast Velocity Minify, Autoptimize, Merge + minify + refresh) have minification features.
Apart from text compression you should compress your images as well. Images are also page requests and need to be optimized. When compressing images use the correct file format. For photos use jpeg, for drawings and text use png format. Learn more about image compression, optimization and lazy loading.
Lazy load images, videos, JavaScript files
Lazy loading is a feature that delays loading page content until it is needed. For example in initial page load you do not need to load images and videos that are not visible. They need to be loaded later when the user scrolls down. Videos need to be loaded only if the user clicks on video play. Javascript needs to be loaded only if the user interacts with the page by scrolling, swiping or clicking.
By delaying most of the page content you will reduce the initial number of requests. Meaningful page content will load much faster. Users can see your page and start reading immediately. Other content will load over time and the user will not notice any delay while it is loading.
Using lazy load your page load time can reduce from 3+ seconds to 1 second. This applied to all WordPress websites no matter how many plugins, images, javascript and css files it has.
Lazy load images
Starting from WordPress 5.5 all images below the fold have lazy loading enabled by default. If you notice that some images are not lazy loaded then make sure that they have width and height attribute set and they are using https protocol.
I had an issue with the Contextual Related Posts plugin in one of my blogs where images were not lazy loaded. Checked plugin settings page and found that width and height attribute for thumbnails were not set in HTML. Selected corresponding options and saved settings and lazy loading for related posts was fixed.
Sometimes simple settings can fix lazy loading when you know exactly what is required for it.
Remember in WordPress images should have width, height attribute and be served over https protocol for lazy loading to work. Only then WordPress adds the loading=”lazy” attribute to images.
Lazy load videos
Videos on WordPress sites are generally hosted on YouTube. YouTube videos provide additional social traffic to your blog and help to better explain the topic.
When youtube videos are embedded to your blog pages it will add additional javascript and for every video the same javascript files will be added multiple times.
Check PageSpeed report (done using free service PageSpeed insights by Google ) for WordPress blog page that contains 7 youtube videos. When not optimized all javascript files for videos loaded at the beginning and delays page rendering. So users will have to wait until huge javascript files are loaded even if they do not see video at the beginning of the page.
Solution is to lazy load youtube videos. Lazy loading will load a clickable image with a play button for the video. When the play button is clicked the video and its assets like javascript will be loaded. This will be much faster and reduce page load time by a couple seconds.
There are many plugins that add lazy loading functionality to youtube videos. I use “Lazy Embed” plugin which will automatically add lazy load functionality to all youtube videos on your WordPress website.
Check how to get PageSpeed Insights score 100 using Lazy Embed plugin.
Lazy load JavaScript (delay until user interaction)
Similar to images and videos javascript also can be lazy loaded. Lazy loading for javascript is performed on user interaction like scroll, click, swipe, resize. If no user interaction happens then there is no need to load those javascript files.
Javascript files are slow to load and execute. More files will make pages even slower. Loading all javascript files at the beginning will delay page rendering and users will have to wait longer before seeing any readable or meaningful content.
There is a neat plugin that loads javascript on user interaction called Flying Scripts. It does only one thing. Loads the defined javascript on user interaction.
This is my setup for the current website. I lazy load all JavaScript files defined by plugins, inline scripts relying on jQuery, external analytics scripts and other .js files that are not critical for initial page load. With this setup my WordPress website loads fast and page speed score is always above 90.
Here are common scripts that can be lazy loaded. You can copy and paste it to your plugin settings page.
/plugins/ jQuery( comment migrate gtag
I prefer using the lazy load (delay until user interaction) method for JavaScript instead of merging js files. Because I do not have too many JavaScript files in my blog. The only big plugin with extra page assets is bbPress, which is enabled only on forum pages.
Additionally you can lazy load external javascript files like analytics and adsense. Check how I use it to improve PageSpeed score.
Async/defer JavaScript (non blocking)
Async JavaScript is another way of speeding up WordPress pages. It is better than default blocking javascript behavior. When javascript is blocking it will pause page loading and pages will take longer to display.
Async will download JavaScript without blocking the main document. Once finished downloading it will pause the page and execute javascript code. Defer is similar to async but executes after page rendering is finished.
Here are loading and execution order for JavaScript files with suggested usage:
- Regular javascript (blocking) – slowest. Prefer not using any.
- Async javascript (non blocking) – faster. Use only jquery if other scripts depend on it.
- Lazy javascript (on user interaction) – fastest. Use all plugin scripts, core scripts (comments), external (analytics, ads, chat etc.) and inline JavaScript (including those which rely on jQuery).
Important point is to make sure that site functionality is still working after these optimizations.
To not get any jQuery errors make sure that it is loaded before others by moving its loading priority one level higher. If all scripts are lazy then jQuery should load as async. If all scripts are async then jQuery should load as regular blocking.
With this setup your website will always load fast for the end user.
Reduce requests by inlining small CSS and JS code from plugins
Some plugins have an option to use separate js and css files or inline them. Usually it is better to inline those assets if they are only several lines of code. Inlining small code will reduce the number of page requests and speed up your WordPress page load time.
I am using inline css for Contextual Related Posts plugin and Easy Table of Contents plugin.
Use optimized themes and plugins
When choosing themes and plugins for your WordPress website check how well it is optimized in terms of page requests. Choose a theme that has one CSS and at most one js page asset. Also prefer a theme that is using native JavaScript instead of depending on jQuery JavaScript library.
I use the Neve theme which is optimized for a minimal number of requests. Theme does not depend on the slow jQuery library as well which makes it even faster.
WordPress Plugins to optimize page requests
Here are plugins mentioned in this article that can help to optimize page requests:
- Fast Velocity Minify – merge (combine), defer, remove js and css files. Alternative plugins are Autoptimize, Merge + Minify + Refresh.
- Flying Scripts – lazy load JavaScript on user interaction.
- WP Youtube Lyte – lazy load YouTube videos.
FAQ
How many page requests are too many?
Optimized web page on average should have less than 20 page requests. Pages with more than 50 page requests are considered as too many.
Here is the ideal number of page requests by asset type for content blogs:
| Type | High priority | Low priority (lazy, async) |
|---|---|---|
| HTML document | 1 | – |
| .css | 1 | – |
| .js | – | 1 |
| .js external (analytics, ads, chat) | – | 1-2 |
| Images | 1-3 | 10 |
| Font, video, audio, etc. | – | – |
Why is it important to optimize page requests for not logged in users?
Most page requests, assets like javascript and css, are loaded once and used on all pages. So they will be loaded only once for first time visitors. First time visitors are always not logged in users.
Not logged in users are generally 99% of all visitors.
For most WordPress websites logged in users are generally site owners. Site owner logs in to perform site administration. When a site owner logs in there will be a lot more page requests that are used only for managing the website. Most administrator assets are dynamic and optimizing them can break site functionality. Also it will not be efficient.
How to optimize page requests for repeat view?
Page assets are static so they should be cached on the user browser for a long time like a year. When a user navigates to other pages on your website, page assets will be loaded from cache without making a request to the web server.
This way every page will load a single HTML document and new images only.
Check this PageSpeed report for WordPress blog. Page assets are cached for a short time. If a user visits a website after 2 weeks they will have to download most of these assets again because of too short browser caching time.
Use browser caching to optimize page requests for repeat view. Browser caching is configured on server software like apache, nginx. For most WordPress sites it is handled by a web hosting company.
How to optimize requests for resources from other domains?
Resources from other domains like JavaScript can only be delayed. Delay them using the Flying Scripts plugin. Page will load much faster when external JavaScript files are delayed until user interaction like move, scroll, click.
External fonts should be avoided by removing fonts completely or use local fonts only for font icons.
Conclusion
We viewed various ways to reduce page requests for improving page speed.
To summarize page requests optimization in 3 simple steps:
- Remove as many page requests as possible.
- Merge if there are more than 5 css and js files.
- Lazy load javascript, images, videos.
When applied correctly your page load time (First Contentful Paint & Largest Contentful Paint) will be reduced to 1 second.
This is ideal load time for most websites.
Also keep your TTFB (Time To First Byte) low by: