Troubleshooting a Slow WordPress Website

Test the speed of your website with Google’s PageSpeed Insights.

Waiting more than 1.65 seconds may result in a customer leaving the site (known as a bounce rate) and searching for a different solution offered on a faster competitor’s website. According to Google assessments conducted in 2017, bounce rates increase 32% when website page load times rise from 1 second to 3 seconds! That’s proof that nobody likes a slow WordPress website.

In 2024, optimal page load times are 0–2 seconds. Adding more time results in lower engagement, conversion, customer referrals, and search engine traffic.

Luckily, there are methods for measuring and improving on-page speed metrics. However, gaining insight into page speed takes time and requires carefully auditing of many website aspects.

7 Steps to Improve Speed  and Landing Page Performance

1. Evaluate the Platform: Consider whether the codebase of your website is open source and if it has a reputation for speed and performance. WordPress websites meet both of those requirements.
2. Assess Performance with Core Web Vitals (CWV): Insight gained from CWV illustrates how website visitors interpret and use the site. These metrics calculate the Largest Contentful Paint (LCP) or how fast a webpage loads. Combined with Interaction to Next Paint (INP), which gauges the interactivity of clicks, taps, and key presses, and Cumulative Layout Shift (CLS), which measures the website’s structure and stability, these three indicators allow you to analyze your website from a search engine perspective.
3. Choose the Right Theme: The WordPress Block Editor offers the lightest, cleanest option for responsive website design and development. It consistently ranks faster on speed tests in load times and content creation than traditional themes and non-native builders.
4. Optimize Images: The WordPress Block Editor natively compresses images, allowing page images to match the needed size, resulting in a faster load time. Additionally, many image compression plugins enhance this further.
5. Activate Browser Caching: Determine and cache any assets web browsers need to accelerate webpage load times for returning visitors. Without caching, the website must repeatedly refresh the content, which takes longer.
6. Evaluate Hosting and Employ a Content Delivery Network (CDN): Web hosting service performance and pricing vary widely. Migrating to a new host and service may be a worthwhile answer, particularly if the host provides a CDN. A CDN identifies user locations and provides users with data from their nearest server, reducing load times globally.
7. Remove Unnecessary Files and Optimize CSS Delivery: When above-the-fold content loads first, visitors view the site as blazing fast. Removing unneeded CSS, JavaScript, and plugin files, and activating asynchronous file loading also speeds sites up.

As you can see, many factors determine website page speed. Following the seven steps outlined above will transform your slow website, allowing you to deliver rapid results and an enhanced user experience.

Are you still struggling to improve your slow WordPress website? Contact WebDevStudios. We’d love to look under the hood of your WordPress site and make recommendations.

The post Page Speed Insights: 7 Steps to Transform Your Slow WordPress Website appeared first on WebDevStudios.

Below we’ll look at the evolution of the protocol and discuss how to evolve our asset delivery strategy to deliver CSS and scripts in the fastest way possible for the latest version.

1997 – HTTP/1.1 – History and Asset Loading Strategies

Implemented in 1997, HTTP/1.1’s main performance pain points were head-of-line-blocking and redundancy of the request header happening for each call.

Connecting to the server, transmitting headers, and requesting data was so time consuming for each file that we tried to get as much as we could into each file we called.

To do this, we preprocessed our scripts and styles in single file calls, inlined code, vulcanized, and made image sprites. It was paramount to limit the number of calls to the server. Much of the internet is still built this way.

2015 – HTTP/2 – Let there be multiplexing.

What is HTTP multiplexing?

From Stack Overflow:

Put simply, multiplexing allows your Browser to fire off multiple requests at once on the same connection and receive the requests back in any order.

As browser support became real in 2015, HTTP/2 offered compressed headers and multiplexing to a single TCP connection. This allows multiple assets to be loaded simultaneously, rendering the page faster.

While this is a vast improvement, there is still a catch.

If any asset being requested within that multiplexed TCP connection experiences packet loss, then the entire group of multiplexed streams after that point would be paused until the data packet could be corrected.

Because TCP doesn’t have any context on the multiplexed files to know which can move on and which can’t, packet loss can have HTTP/2 still dealing with head of line blocking.

HTTP/3 – Now and the Future

HTTP/3 seeks to solve the problems of HTTP/2 by not using the TCP at all and instead using QUIC. Because QUIC provides native multiplexing, lost packets only impact the streams where data has been lost.

But can I use it? Kinda.

Most browsers support it by default. However, (as of this writing) in Safari you need to activate it as an option on your device.

Implications

To take advantage of multiplexing we have to break out of the concatenation mindset where the focus was on limiting calls and have a more nuanced asset delivery strategy prioritizing assets crucial to render.

Most browsers and servers seem to default the concurrent connections to about 100. Smaller files delivered largely simultaneously can drastically improve render time and page speed performance.

Google Page Speed Performance Metrics

Largest Contentful Paint, First Input  Delay, and Cumulative Layout Shift are Google’s strategy to help improve web performance; this is cumulatively named “Core Web Vitals.” The biggest enemy of scoring well in these metrics is render blocking assets.

Luckily HTTP/2/3 gives us ways to address render blocking issues much better than before.

Optimization Strategies

Google’s algorithms will down-rank pages that have pipelines with render blocking resources. However, unused JS and CSS resources are weighted almost as strongly.

Although Google only knows for sure (these algorithms aren’t public), it is likely because unused resources bloat a site’s payload and are often render blocking, resulting in causing the user waiting for resources that aren’t even used on a page.

Taking on the task of eliminating unused CSS and JS can also cut the file sizes of your minified assets. Seek out parts of your code base that aren’t used on every page/post/condition and find ways to dynamically enqueue the related assets.

For example ACF Gutenberg blocks:

It is common practice to be concatenating and enqueueing one large CSS and or JS file for all of your custom blocks. ACF block registration lets you enqueue related assets only if the block is used on a page eliminating unused CSS while not duplicating it by including it inline. This is a reasonably easy enhancement that provides a good result for minimal effort.

Another point of attack could be any global options set via the admin that might trigger a class or attribute change that you are then applying CSS or JS to affect (any global option affecting render). Those styles could be in their own sheet and the condition used to set the class or attribute could be used to enqueue the asset instead.

These kinds of strategies may require a more complicated preprocessing of files and JS route building, but the results will be substantial. You will serve less unused code and by pulling the conditional code out it will also make your concatenated files smaller and therefore less render blocking, leading to faster page loads and better Google ranking.

View the code on Gist.

Finding Balance

Knowing how much there is to be gained it’s easy to over simplify your asset loading strategy by loading every little file independently—going to the opposite extreme. There are limits, however.

Servers and browsers set their own restrictions for concurrent connections so we should focus on loading render driving assets first but related parts of your code base should still be concatenated and minified. Each project is different and will require a slightly different approach but HTTP/2/3 gives us the options to improve end user experience and make the internet generally more efficient.

The post HTTP/2 and HTTP/3 Flipped the Performance Optimization Script appeared first on WebDevStudios.