BajanThings mobile PageSpeed results 11 October 2023 post integration of: SiteGround Speed Optimizer + FlyingPress + Shortpixel Adaptive Images.
This is how BajanThings boosted its mobile PageSpeed score from 26 (Poor) to 90+(Good). BajanThings uses the responsive WordPress theme: Astra Pro, hosted on SiteGround. This is a hobby site which was launched in December 2014. In 2017 we moved from a http:// to a https:// format. And in 2020 we gave the look and feel of BajanThings a little facelift. We have a GoGeek hosting plan with SiteGround and use the free version of SiteGround’s CDN.
This post is aimed at other hobby site operators, like ourselves, who might be struggling to increase the mobile PageSpeed score for their WordPress website.
The key benefit of a mobile PageSpeed score of 90 or above is that pages served on tablets and mobile devices should now load much faster.
It’s been really hard work increasing the mobile PageSpeed score. During September, October and November we have focused our effort at optimising the BajanThings mobile PageSpeed score. As part of the giving-back process we thought we would share what we did. Along the way we’ve had to learn some technical skills like using: Chrome DevTools!
In the past our focus was on optimising the desktop PageSpeed score for BajanThings. At that time Google placed a lot of weight on the desktop PageSpeed score when ranking posts on Google Search.
With the increase in the power of mobile devices, Google has shifted its emphasis from focusing on how fast a page loads on a laptop/desktop to how fast a page loads on a mobile device. Achieving fast loading pages on a mobile device is now a critical focus for Google – especially for Google search results. To do this we have been tweaking lots of things under-the-bonnet (under-the-hood for those in North America) to increase the BajanThings mobile PageSpeed score.
It is a lot more difficult to increase one’s mobile PageSpeed score due to factors such as: mobile devices have less processing power than laptops or desktop devices, mobile network connectivity is generally slower than fibre connected homes or offices with fast WiFi, mobile devices typically have smaller, lower resolution screens than laptop or desktop monitors. One of the major things that slows down the loading of a webpage on a mobile or tablet device is loading large format images optimised for a desktop screen onto a small mobile device screens! Here is a real example: A typical full-size image might be 1024x730px when served onto a desktop might be 46KB in size. That same image reduced to 300x214px and optimised for a mobile device might be 6KB. That’s a 7x multitier in weight between what’s needed on a desktop and what’s needed on a mobile device. The other thing, mobile devices are typically tied to a data plan.
Some of the tweaks we have been working on have ranged from re-sizing some of the original feature images on popular posts so that they are smaller in size and so load faster, increasing the compression ratio of images, to tweaking the order that some sections of code load to implementing new mobile caching and dynamic image re-sizing tools.
Another thing we have done is tweak the homepage to reduce the page weight in terms of the number of post summaries that are displayed and to reduce the number of widgets we call in the righthand sidebar.
The baseline PageSpeed score that is needed for mobile devices and desktop devices is a score of 90 or above. The benchmarking tool is: Google PageSpeed. A score of:
0 to 49 is ranked as: Poor.
50 to 89 is ranked as: Needs Improvement and
90 to 100 is ranked as Good.
Search Engine Optimisation (SEO) and mobile PageSpeed now go hand-in-hand.
The desktop PageSpeed score for BajanThings has consistently been about 95, so it was ranked Good.
At the beginning of September the mobile PageSpeed score for BajanThings was 26, so it was ranked as very Poor!
Google gives with one hand and takes away with another. We use two Google products on BajanThings: Google Analytics and Google AdSense. When these are added to a website they significantly reduce the mobile PageSpeed score!
In the past for our homepage we cheated in an effort to increase the the mobile PageSpeed result. We opted not to include Google AdSense code on the home page! This has a monetisation impact, as our homepage is an entry point for BajanThings.
BajanThings is very much a hobby site. Google AdSense advertising makes a contribution to the cost of running BajanThings. Advertising does not cover to the full cost of: Registration, Hosting and the paid plugins we use. With what we have now achieved optimising the mobile PageSpeed score, we have now added back Google AdSense ads onto the homepage of BajanThings to help contribute to the cost of some additional plugins we have purchased to help us move our mobile PageSpeed score from: Poor to Good.
So what did we do?
BajanThings is hosted by SiteGround. SiteGround include an optimisation tool: Speed Optimizer (pka SiteGround Optimizer).
The first thing we had a look at was making images load fast. We re-sized some of the feature images on some of the most popular BajanThings posts. Making these feature images smaller within PhotoShop setting the max width to 1024px. We tend to use landscape feature images 1024px x768px and we try to make sure the jpg images are 50KB to 100KB in size. Having done this we tweaked the compression Media setting that Speed Optimizer | Media uses. We changed from Low compression (25%) to Medium compression (60%) and we re-calibrated the image format to WebP format. Prior to SiteGround | Speed Optimizer | Media we used to use Smush by WPMU Dev.
In addition we tweaked the BajanThings flying fish logo and reduced the size – this was just one of many incremental tweaks we made.
We also reduced the weight of the homepage by changing the number of post listed from 8 to 6. This was done by changing: Settings | Reading Settings – Blog pages show at most and Settings | Reading Settings – Syndication feeds show the most recent.
Another thing we did was to look at the the widgets we called in the right-hand sidebar. In the current version we use 3 Jetpack widgets: Listing of Last 5 Posts, Recent Post Comments and Post Categories. We lightened up the load by removing two widgets: Google Translate (a Jetpack legacy widget) and Trending Posts & Pages over the last 24 to 48 hours.
Next we looked to reduce the impact of the Google Analytics and Google AdSense code on our mobile PageSpeed results. When we started the website we used to manually load the code snippets for Google Analytics and Google AdSense in the header as recommended by Google. To do this we used a feature of our WordPress theme Astra Pro – Custom Layout using a custom page layout set to Hooks where the hook was set to load the code snippet within: Head Top. As the Site Kit by Google plugin matured we swapped from using the Astra Pro – Custom Layout page hooks to using to using Site Kit by Google. A side advantage of this is Site Kit by Google displays the summary results in the WordPress Dashboard Home page – a handy bonus.
As part of this optimisation process we noticed that Site Kit by Google had a pretty severe impact on the mobile PageSpeed results. We were able to bump the PageSpeed result up by deactivating Site Kit by Google and reverting to using the Astra Custom Layout pages to serve the Google code snippets, but there was a twist. We changed from loading the code snippets for Google Analytics and Google AdSense in Head Top to After Footer.
The downside of removing Site Kit by Google was to see summary results we now need to physically login to Google Analytics and Google AdSense. An annoyance but one we can live with!
Having done this we hit a road-block and could not increase our mobile PageSpeed score which was standing now at about 47. We had made progress and jumped our mobile PageSpeed score from from 26 to 47 and were nearly at, but not quite at the Needs Improvement level!
One of the top issues for getting mobile PageSpeed scores down is to reduce the impact of large images served onto small mobile and tablet screens. Our next move was to purchase a specialist plugin: Shortpixel Adaptive Images. This plugin, on-the-fly looks at the size of the screen that an image is to be loaded on and then dynamically resizes the images based on the screen size. So if your feature images is say 1024x768px and the image is being served onto a mobile phone or a tablet the image size is dynamically resized, ipso facto, as a smaller sized image is being served it therefore loads much more quickly on a mobile device. This had a pretty significant impact on our mobile PageSpeed score. Using Shortpixel Adaptive Images to dynamically re-size images served onto mobile devices and tablet devices saw our mobile PageSpeed score jump from 47 to 80!
It didn’t seem to matter what we did we could not jump the mobile PageSpeed score results up from 80 to 90+ which equated to a jump from the Needs Improvement level to the Good level.
Having done a lot of head scratching and reading around the subject we came across two post, one by Tom Dupuis and one by Jake Pfohl (referenced at bottom of post) and opted to try disabling some of the SiteGround Speed Optimizer settings and replacing them with FlyingPress – a lightweight speed optimization plugin for WordPress which we had to purchase. FlyingPress is described as an updated version of WP Rocket.
With the help of Tom’s and Jake’s posts we tweaked the SiteGround Speed Optimizer settings and FlyingPress settings.
Within the Cache section of FlyingPress we have opted to activate the option: Flying Press | Cache | Generate separate cache for mobile. Our WordPress theme Astra Pro is responsive and serves a slightly altered version of the website for mobile and tablet devices. It’s mainly to do with the header and menu display and how the body and right sidebar are displayed on mobile devices.
Whey Hey Hey – using SiteGround Speed Optimizer + FlyingPress + Shortpixel Adaptive Images our mobile PageSpeed score jumped to 90+. You can imagine our exhilaration when we hit the mobile PageSpeed score Good level!
A key thing to remember is: there is duplication between SiteGround Speed Optimizer + FlyingPress + Shortpixel Adaptive Images. Its important to de-activate the duplicated functionality. We had a few small glitches which we fixed by a bit of trial and error experimentation.
First Glitch
With some posts where we were getting blank images appearing. It was a duplication issue.
In FlyingPress we had Lazy Load activated and in Shortpixel Adaptive Images we had two Lazy-load settings activated: Lazy-load the background images from inline STYLE blocks and Lazy-load and resize the background images in TAGS inline styles. Once we turned off the FlyingPress lazy-load settings the blank images appeared!
Second Glitch
With the mobile version of our Astra Pro theme the Menu hamburger appeared open and the header was duplicated. This was not a show stopper…
The fix was a tweak to FlyingPress: FlyingPress | CSS | Remove unused CSS. This was initially set to: Remove. We have changed this setting to: Asynchronously.
Brainstorm Force Astra our theme developers also suggested a temporary fix. They were aware of the issue and suggested we add some Additional CSS until Astra Pro is next patched:
/* Astra temp fix associated with duplicate header on mobile when FlyingPress implemented */
@media (max-width: 1050px) {
#ast-desktop-header {
display: none !important;
}
}
@media (min-width: 1051px) {
#ast-mobile-header {
display: none !important;
}
}
NOTE: The above Additional CSS needs to be removed with the latest update of Astra 4.5 and Astra Pro 4.5
We also added some CSS classes to: FlyingPress | CSS Settings | Remove unused CSS | Include selectors:
The above fixed the mobile menu hamburger display glitch.
Third Glitch
With the desktop version if we viewed a post with a gallery (we use Meow Gallery) the gallery was visible. However, if we viewed that same post on a mobile device the gallery disappeared.
The fix was a tweak to FlyingPress: FlyingPress | JavaScript Settings | Delay JavaScript. This was initially set to: Delay all. We changed this setting to: Delay selected (using the suggested settings) and this added back galleries when a post was viewed on a mobile device.
That’s been the extent of the glitches we have observed. The fixes, however, came with a price – a drop in our mobile PageSpeed score from Good back to the the Needs Improvement level!
A little hiccup, post implementation!
Having got everything working on mobile and desktop our mobile PageSpeed score dropped below the magic 90 threshold and put us back in the Needs Improvement level – so we started experimenting again:
SiteGround Speed Optimizer + FlyingPress + Shortpixel Adaptive Images: where the image section of FlyingPress was disabled and the image management was handled by Shortpixel Adaptive Images.
SiteGround Speed Optimizer + FlyingPress + FlyingCDN: where FlyingCDN is the FlyingPress equivalent of Shortpixel Adaptive Images.
On paper SiteGround Speed Optimizer + FlyingPress + Shortpixel Adaptive Images should give the best mobile performance. The Shortpixel Adaptive Images tools sits on top of BunnyCDN image optimisation tools. Flying CDN also sits on BunnyCDN.
In our testing using: SiteGround Speed Optimizer + FlyingPress + FlyingCDN has given slightly better results, so this is our current set-up that has got us back to the Good level.
Our mobile PageSpeed score currently hovers at 90 to 96 and our GTmetrix score is A.
Now that our mobile PageSpeed score was again stabilised we ran another experiment – reverting back to using Site Kit by Google for managing Google Analytics, Google Search Console, Google AdSense, Google PageSpeed.
Our testing showed that by deactivating the Astra Pro Custom Layout that uses hooks to load the Google Analytics and Google AdSense code in the footer and re-activating Site Kit by Google that our mobile PageSpeed score dropped from 90+ to a mobile PageSpeed score of: 75 to 85! So back in the Needs Improvement level!
Based on the above we have for now removed the Site Kit by Google plugin and reverted to loading the Google Analytics and Google AdSense code with a footer hook via a Astra Custom Layout. We really, really miss the Google summary results in the WordPress dashboard – it’s just one of the things we have had to forego in our mission to BUMP-UP our mobile PageSpeed score! We will re-look at the Site Kit by Google and FlyingPress settings when we have a bit more time and have increased our tech skills interrogating Chrome DevTools within the Chrome web browser.
We have also tweaked the FlyingPress | JavaScript | Scripts to delay list:
The above was developed from some examples of common JavaScript delay exclusions listed by: Online Media Masters by Tom Dupuis, Start Blogging 101 by Jake Pfohl, perfmatters and by inspecting the source code for BajanThings following various runs of PageSpeed Insights and GTmetrix.
One of the PageSpeed Diagnostic items we kept seeing was: Avoid an excessive DOM size. What was highlighted was the righthand sidebar html block of: Contributing Authors. The fix was to add the selector for this block to the FlyingPress | CSS | Lazy render elements. To do this you need to use Chrome inspector to find the elements then “Copy selector”. Click here to see the FlyingPress tutorial: “Introducing Lazy Render”. This is what we added which identifies the : Contributing Authors H2 heading and list of authors with links:
#block-13 > h2
#block-13 > p
or you can delay the whole righthand sidebar wrapper:
#secondary
Both worked! Fixing this has bumped the score up a a few more point!
Another issue we have had is with out Contact Us form. For our contact form we use the free version of Formidable and use a simple contact form. It includes a reCAPTCHA block. That reCAPTCHA block stopped working and we had to add some code:
To FlyingPress | CSS Settings | Lazy render elements, we added:
#recaptcha-anchor-label
#rc-anchor-container
This now is the updated "Lazy render elements" list:
#secondary
#recaptcha-anchor-label
#rc-anchor-container
To FlyingPress | JavaScript Settings | Scripts to delay, we added:
recaptcha-anchor-label
grecaptcha.execute
This now is the updated "Scripts to delay" list:
astra
jquery.min.js
adsbygoogle.js
googlesyndication.com
googleoptimize.com
fundingchoices.google.com
google-analytics.com
googletagmanager.com
gtag.js
gtag(
/gtag/js
/gtm.js
/gtm-
/gtm.
recaptcha-anchor-label
grecaptcha.execute
Those CSS and JavaScript additions seem to have fixed the contact form reCAPTCHA block issue.
We have had one other issue. We use the plugin TablePress by Tobias Bäthge to manage tables – some of which push the use of tables to the limit, like this one!
TablePress uses the jQuery JavaScript library and when it is “Defer” loaded or “Delay” loaded it interferes with how TablePress tables work. Specifically it removes the search box and pagination. To fix this within FlyingPress we have moved jquery from “Scripts to delay” and added it to the area “Exclude scripts from defer”. This fixed the issue and our massive research tables are again working.
With another site that uses Astra we use the Astra Mega Menu function. The Mega Menu also makes use of the jQuery to display menu elements. According to Brainstorm Force if you use Mega Menu then you need to exclude the following CSS and JS from being cached. The key is the jquery.min.js as without this key component the Mega Menu does NOT work!
The site that uses Astra Mega Menu only uses the SiteGround optimizer tool. In testing the following CSS and JS exclusions gave the best PageSpeed results:
CSS:
wp-content/themes/astra/assets/css/minified/frontend.min.css
wp-content/uploads/astra-addon/astra-addon-654a3d38a094b3-81992328.css
wp-includes/css/dist/block-directory/style.min.css
JS:
wp-content/themes/astra/assets/js/minified/frontend.min.js
wp-content/uploads/astra-addon/astra-addon-654a3d38a25df3-28348014.js
wp-includes/js/jquery/jquery.min.js <- without this excluded from the cache Mega Menus DO NOT work!
It was very simple if jquery.min.js was NOT excluded from the cache then when you scrolled over a Mega Menu item it would NOT open!
Below is our current mobile PageSpeed score:
Current PageSpeed Insights using SiteGround Speed Optimizer + FlyingPress + FlyingCDN.
Below is our current GTmetrix score:
Current GTmetrix using SiteGround Speed Optimizer + FlyingPress + FlyingCDN.
This is just for info. The SiteGround Speed Optimizer will likely remain unchanged.
SiteGround Speed Optimizer
Note: There appears to be an issue with SiteGround Dynamic Caching having loaded FlyingPress + FlyingCDN (same when we were also using Shortpixel Adaptive Images). Within SiteGround Speed Optimizer – Caching – we have activated Dynamic Caching and Memcached and deactivated File-based Caching. It allows us to save those settings, however, when we come back to the Speed Optimizer – Caching page – Dynamic Caching is always deactivated!
We have subsequently amended the Flying Press | CSS Settings | Lazy render elements:
We removed the individual Contributing Authors block from the the "Lazy render elements" listing:
#block-13 > h2
#block-13 > p
We subsequently replaced above with right sidebar wrapper within the "Lazy render elements" listing:
#secondary
And we have added the Formidable Form reCAPTCHA blocks to the "Lazy render elements" listing:
#secondary
#recaptcha-anchor-label
#rc-anchor-container
FlyingPress – JavaScript Settings.
Added to the Flying Press | </> Javascript Settings | Scripts to Delay is the script to allow the Formidable Form reCAPTCHA to work: recaptcha-anchor-label and grecaptcha.execute.
Removed jquery.min.js from Flying Press | </> Javascript Settings | Scripts to delay and added jquery.min.js to the Flying Press | </> Javascript Settings | Exclude scripts from defer. This fixed the plugin TablePress. The TablePress creator Tobias Bäthge told us when jquery is “Defer” loaded or “Delay” loaded it interferes with how TablePress tables work. Specifically we found it removes the search box and pagination. The above worked. The team at FlyingPress suggested that the delaying jQuery file may affect the functionality of a website so it is not recommended to delay jQuery so we have removed the ref to jquery.min.js in the FlyingPress JavaScript settings and TablePress appears to be working…
FlyingPress – JavaScript Settings. – jquery.min.js removed from Exclude scripts from defer and Scripts to delay.FlyingPress – Font Settings.FlyingPress – Image Settings – (when using Shortpixel Adaptive Images these were all deactivated).
The Exclude above-fold images value of 5 was set by trial and error based on an error we were getting with PageSpeed / GTMetrix Diagnostic: Largest Contentful Paint (LCP) image was lazily loaded. Above-the-fold images that are lazily loaded render later in the page lifecycle, which can delay the largest contentful paint. (We think the 5 relates to: flying fish logo, Astra menu icon, Astra search icon, first two feature images for the first two posts?)
In addition “wp-post-image” has been added to Exclude Images as were the two BajanThings flying fish logo images.
FlyingPress – iFrame Settings.
We have tweaked this setting and deactivated: Use placeholder image for YouTube videos.
FlyingPress – CDN Settings using FlyingCDN.
FlyingCDN is the FlyingPress equivalent of Shortpixel Adaptive Images which we started using and which initially gave us a significant boost in mobile PageSpeed before we started experimenting with FlyingPress.
FlyingPress – Bloat Settings.
Shortpixel Adaptive Images
This is for info only. These are the settings when we were using: SiteGround Speed Optimizer + FlyingPress + Shortpixel Adaptive Images. When we did this all the FlyingPress Image settings were deactivated so Shortpixel Adaptive Images took priority.
We have transferred our Shortpixel Adaptive Images account to another site we manage that uses fewer Google products. Shortpixel Adaptive Images helped us move from our initial mobile PageSpeed score of 47 to 80. Our thanks to Shortpixel Adaptive Images for allowing us to transfer the account.
Shortpixel Adaptive Images – Compression Settings.Shortpixel Adaptive Images – Behaviour Settings after setting Shortpixel Adaptive Images as lazy-Load priority.Shortpixel Adaptive Images – Areas Settings, after setting Shortpixel Adaptive Images as lazy-Load priority.Shortpixel Adaptive Images – Exclusions Settings.
So what do we still have to do?
There are 3 Core Web Vitals we are still failing on:
Note the differences between the Google PageSpeed and GTMetrix summary scores: LCF: 2.9s vs 1.5s; FCP: 2.4s vs 952ms; and TTFB: 1.8s vs 701ms.
What is a good LCP score? As of 29 October 2023 BajanThings mobile PageSpeed LCP = 2.9s. Aim is 2.5s.
Largest Contentful Paint (LCP) is an important, stable Core Web Vital metric for measuring perceived load speed because it marks the point in the page load timeline when the page’s main content has likely loaded—a fast LCP helps reassure the user that the page is useful
Aim: To provide a good user experience, sites should strive to have Largest Contentful Paint of 2.5 seconds or less. To ensure you’re hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.
Largest Contentful Paint (LCP)
LCP definition from Google’s: web.dev.
The key driver for the LCP metric is image size and we are working on this.
What is a good FCP score? As of 29 October 2023 BajanThings mobile PageSpeed FCP = 2.4s. Aim is 1.8s
First Contentful Paint (FCP) is an important, user-centric metric for measuring perceived load speed because it marks the first point in the page load timeline where the user can see anything on the screen—a fast FCP helps reassure the user that something is happening.
Aim: To provide a good user experience, sites should strive to have a First Contentful Paint of 1.8 seconds or less. To ensure you’re hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.
First Contentful Paint (FCP)
FCP definition from Google’s: web.dev.
The key driver for the FCP metric is what we are doing with FlyingPress and Flying CDN – we are working on this increasing our tech skills here!
What is a good TTFB score? As of 29 October 2023 BajanThings mobile PageSpeed TTFB = 1.8s. Aim is 800ms.
Time to First Byte (TTFB) is a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field. It helps identify when a web server is too slow to respond to requests. In the case of navigation requests – that is, requests for an HTML document – it precedes every other meaningful loading performance metric.
TTFB is the sum of the following request phases:
Redirect time
Service worker startup time (if applicable)
DNS lookup
Connection and TLS negotiation
Request, up until the point at which the first byte of the response has arrived
Time to First Byte (TTFB)
TTFB definition from Google’s: web.dev.
Our Time to First Byte (TTFB) is driven by the response speed for the SiteGround servers where BajanThings is hosted. We are on shared hosting with SiteGround so there is not much we can do about this, apart from upgrading our hosting plan or changing our web hosting partner! This is not currently on our to do list! The move from our previous web host Bluehost to SiteGround back in 2016 was painful – we moved as Bluehost wasn’t the Bluehost we originally signed up with way, way back when. What we really detested was that Bluehost went out of their way to make the move difficult. It made me especially wary when our SEO tool Yoast SEO Premium was bought by Newfold Digital (the company that owns the hosting provider Bluehost) in August 2021 – especially after the founders departed in April 2023 ushering in new leadership under the Newfold Digital!
Final Thoughts
This is not a fix and forget set-up. We perceive BajanThings will need to continue to tweak the settings to consistently maintain a mobile PageSpeed score of 90 or above.
We hope our learning will help other hobby site owners to increase the mobile PageSpeed score for their sites.
A big thank you to Tom Dupuis and Jake Pfohl who pointed us at FlyingPress.
FlyingPress don’t have a trial version but they do have a no quibble 14-day refund policy so if you try it and it does not work for you – you can get your money back. FlyingPress also have a pretty responsive support team.
Other Updates
Update on Site Kit by Google – 5th December 2023 We love the summary that Site Kit by Google provides in the WordPress Dashboard Summary – which is why we keep coming back to this. During wc 5th December 2023 we opted to try something a little different. We left in place the Goole Analytics and Google AdSense scripts we load via a Hook After the Footer. When we set up Site Kit by Google – it recognised that the Analytics and AdSense scripts were already in place and we chose NOT to have Site Kit by Google auto insert the scripts. This appears to have given us the best of both worlds. Our mobile PageSpeed score prior to installing Site Kit by Google was 94. After implementing Site Kit by Google with manual placement of our Goole Analytics and Google AdSense scripts our mobile PageSpeed score dropped only 2 points to 92. We will be monitoring this set-up and will report back.
Update on Site Kit by Google – 27th November 2023 We love the summary that Site Kit by Google provides in the WordPress Dashboard Summary. During wc 20th November 2023 having gained a pretty steady state mobile PageSpeed score of 90+ we gave Site Kit by Google another go. It was lovely having the summary stats available in the WordPress summary dashboard. Sorry to report – not too much changed. Our steady state score dropped to between 75 to 89 so regrettably after a week we reverted back to using hooks to load the Google Analytics and Google AdSense scripts. Both loaded After the Footer. Having reverted our mobile PageSpeed score is back at 90+.
Useful references
Shortpixel Adaptive Images – on-the-fly resized images based on the screen size the image is being viewed on to reduce the load time especially on mobile devices.
FlyingPress – a lightweight speed optimization plugin for WordPress.
FlyingCDN is the FlyingPress equivalent of Shortpixel Adaptive Images which we started using and which gave us a significant boost in mobile PageSpeed before we started experimenting with FlyingPress. FlyingCDN includes Bunny Optimizer which is BunnyCDN’s image optimization service for compression, WebP, mobile resizing, and other features. It’s used automatically with FlyingCDN.
To get an e-mail update when a new post is added to BajanThings add your e-mail address below and click on the SUBSCRIBE button. Your e-mail address will automatically be added to the BajanThings subscriber list. Whenever there is new content added to BajanThings you will receive an e-mail telling you of the update.
