How to Improve the Load Speeds of Your LMS Website with Pratik and Chris
Pratik’s goal is to load any website that he works on in no more than 3 seconds. Learn about website speed and how to make your WordPress LMS website load fast.
How To Speed Up Your LMS Website
Chris Badgett sits down with Pratik Ghela of PressMate, a WordPress speed specialist, to test and fix real LifterLMS and membership sites live. They cover how to measure load speed with WebPageTest and Chrome’s Lighthouse, how a caching plugin can speed up a site without breaking student logins, what a CDN like Cloudflare actually does, and why hosting quality and plugin choices matter more than most course creators realize.
What You’ll Learn
- How to measure real page load speed using WebPageTest and Chrome’s Lighthouse audit
- Why cheap shared hosting and page builders like Elementor or Divi slow LMS sites down
- How to set up a caching plugin so it never breaks student logins or checkout
- What a CDN like Cloudflare actually does and why server location matters
- Why fixing small things, like a missing favicon, can meaningfully speed up a whole site
Key Takeaways
- Test your site with WebPageTest.org and Chrome’s Lighthouse audit before changing anything, so you know what actually needs fixing
- Turn on a caching plugin like WP Fastest Cache, but exclude logged-in users so students never see stale carts or progress
- Move off the cheapest shared hosting plan you can find and add a CDN like Cloudflare
- Clean up 404 errors, like a missing favicon, since your browser waits on every missing file
- Keep your plugin count lean and question whether a page builder’s extra markup is worth the load time it costs
Frequently Asked Questions
Browser choice was not treated as a major factor on the webinar. Load speed comes mostly from server response time, caching, image size, and how much code a page has to load, not from which browser a visitor uses. Any browser will render a slow WordPress site slowly.
Not if you configure it correctly. A plugin like WP Fastest Cache lets you exclude logged-in users from the cached version entirely, so students always see their live dashboard, progress, and cart instead of a stale cached page. You can also cache mobile and desktop separately so responsive styles never cross.
Yes. Once a caching plugin is active, the browser does not have to ask the server to rebuild the page from scratch on every visit. On the webinar’s live test site, enabling free caching cut time to first byte from 1.7 seconds down to roughly 0.5 seconds, about a third of the original time.
No guarantee either way. A quality managed host like WP Engine or Pantheon usually helps, but switching hosts alone will not automatically fix your speed. What matters more is whether the server gives your site dedicated RAM instead of splitting a small pool across dozens of other sites.
There is no reliable shortcut from reviews alone. The more dependable approach, though not one every site owner can do themselves, is renting a VPS directly from a data center and configuring the server yourself, which requires learning server management and SSH. For most course creators, testing your own site’s real numbers on WebPageTest matters more than any host’s marketing claims.
Generally yes, when you stick to native Gutenberg blocks, because the underlying HTML is much cleaner than what most page builders generate. A single design element in a page builder can output dozens of nested div elements, where the same design coded directly might need only two or three.
The free version handles basic caching, gzip compression, and HTML minification. Premium tiers typically add CSS and JavaScript minification, combine multiple JavaScript files into one to cut down on server requests, load Google Fonts asynchronously so they do not block rendering, and lazy load images and iframes until they scroll into view.
Yes. Image-heavy sites can still load quickly if the images are properly compressed and lazy loaded so only the images in the visible viewport load right away. The webinar showed a photography client site with heavy imagery, video, and social login that still loaded quickly because it followed the same core speed principles.
Full Webinar Transcript
Meet Pratik Ghela And What This Webinar Covers
Chris Badgett: Welcome to this training. I am here with Pratik Ghela from PressMate, and I met Pratik at a WordCamp in Portland, Maine. He is a man of many talents. He has built some incredible stuff with LifterLMS, and he is also an expert at website speed and speed optimization, especially for WordPress sites. I am excited to get into this training with you today.
Pratik Ghela: Thanks so much for having me on for the LifterLMS audience. I am excited to get into it with you today. So I was just checking out the website you sent me, the one on your Academy site. I want to ask you one question: what continent are you hosting this website on?
Chris Badgett: The academy.lifterlms.com site. I believe it is hosted in the United States.
Pratik Ghela: Great, let me share the results for this. Let me share my screen.
How To Test Your Website Speed With WebPageTest
Pratik Ghela: I just ran a test from Orlando, Florida, using a cable internet connection at about 13 megabits per second. Your website took about 5.4 seconds to load. The best way to test your own website is a tool called WebPageTest.org.
Enter your website’s URL, and you can select the test location: North America, South America, Europe, and so on. If most of your customers are in Europe, you want to test from Europe, because you really do not want to prioritize someone in Australia loading fast if ninety percent of your customer base is in Europe. You worry about the rest of the world after you have taken care of your primary audience.
The Five Metrics WebPageTest Measures And What They Mean
Pratik Ghela: Whenever you run this test, you get five parameters back.
The first is time to first byte, sometimes shortened to TTFB. This is how long the browser waits before it gets anything back from the server at all. It should ideally land somewhere between 300 and 700 milliseconds. Your site’s first byte came in at about 1.7 seconds, and ideally your whole website should load in under two seconds.
The second is Keep-Alive, a score for how well your site holds cached data in the visitor’s browser so images and assets do not have to reload again and again. The third is compressed transfer, which covers things like gzip compression and minification. The fourth is caching, whether your assets are actually being cached at all, and right now nothing on your site is. The fifth is a content delivery network, or CDN.
A CDN takes your resources and replicates them to multiple data centers around the world. If a visitor is coming from India and there is a data center in Mumbai, the CDN finds the location closest to that visitor and serves the files from there instead of from your original server. The CDN we recommend is Cloudflare, because it is a strong CDN to build on.
Auditing Carlos’s Site From An Amsterdam Test Location
Chris Badgett: While that test runs, I want to welcome the people jumping in. We also had a question on Facebook about whether it matters which browser you are using, Chrome versus Safari.
Pratik Ghela: I do not think browser choice makes a meaningful difference here. Let me ask Carlos where his site is hosted.
Chris Badgett: Carlos, where are you hosted, and where is your user base?
Carlos is using A2 Hosting in the European Union, with a user base in Europe, so Pratik runs the test from Amsterdam instead of Florida.
Pratik Ghela: Carlos’s site is loading in about 3.5 seconds, with a time to first byte around 1.1 seconds, which is a fairly good number. Looking at the plugin list, there are about 20 active plugins running.
A few I would get rid of. A dedicated 404 monitoring plugin is not necessary. A custom admin login plugin does not make much visible difference and can actually make the admin area feel more cluttered. The cookie notice plugin is a good one to replace, since a developer can code a small notice bar directly instead of loading a whole plugin for it. Every plugin you add has to be read by WordPress and combined with your HTML and CSS on every request, so each one adds a little bit of weight.
I would also load Google Fonts directly through fonts.google.com and have a developer embed the font, rather than relying on a plugin to fetch and load it separately. The LifterLMS tab and the local translation plugin are both fine to keep.
Why Custom-Coded Sites Often Load Faster Than Plugin-Heavy Sites
Chris Badgett: Carlos asked in the chat how to build the cookie notice himself. Can you explain again why custom code sometimes makes a site faster than a plugin?
Pratik Ghela: Here is one of my client’s websites. It has a lot of expensive-looking video content, and we coded it from the ground up. You can see how fast it loads even with a custom login flow, where clicking login brings you right back to the same page with a completely different view for someone who has already purchased.
This particular site actually runs 28 active plugins, more than Carlos’s site, but we only use a plugin when it is genuinely needed. This build combines LifterLMS and WooCommerce together, with events on top of that, and the client wanted checkout to skip the cart entirely. There were existing plugins for skipping the cart, but because we built so much of this custom, the site still loads quickly despite everything it is doing.
Chris Badgett: Carlos, are you backing your website up to a separate server, or just relying on your host?
Carlos confirms he keeps a backup copy on Google Drive.
Pratik Ghela: Good. Carlos already has a solid time to first byte. He just is not caching his assets yet and is not using a CDN. I want to shift focus to the Academy site instead, since it has more room for improvement and will give us a deeper look at what actually needs fixing.
Why Cheap Shared Hosting Hurts LMS Site Speed
Pratik Ghela: All Carlos really needs is a CDN and to start caching his content, and his first byte time will likely improve.
Chris Badgett: I have a question about caching. I hear a lot of advice that LMS or membership sites should avoid caching plugins entirely, because of all the different logged-in states. People install a caching plugin and then start getting reports that students cannot log in or password resets stop working. Can you speak to that?
Pratik Ghela: That is a big misconception. A plugin like WP Fastest Cache lets you control exactly what gets cached. If a user is logged in, you can simply show them the live version instead of the cached one. I will walk through that configuration.
Right now I am exporting your Academy site to another environment I have set up, called lmspeed.3sdemo.com, so we can test changes safely.
One thing to really consider is your server configuration. If you are running 25 different plugins on a shared server, especially one of the five or ten dollar a month hosting plans, do not expect good site speed. Hosting companies selling plans that cheap are packing something like 100 sites onto a single server with maybe 20 gigabytes of RAM total. Your site ends up with a few hundred megabytes of that, not the 5 gigabytes advertised, because that 5 gigabytes is being shared by 20 other websites.
The environment I use for demos runs on a server with 4 gigabytes of RAM dedicated entirely to this one site. You can see it in how fast plugins install and activate, because the site is not fighting other sites for resources.
Chris Badgett: While that processes, there is a comment on Facebook asking you to make a course about this.
Pratik Ghela: The demand for site speed knowledge is real. A lot of people just want to hire someone to fix it, or get a better, faster host. I am actually starting my own hosting company.
Chris Badgett: What is it called?
Pratik Ghela: PressMate started as a WordPress maintenance service, but we found that so many people had WordPress speed issues that we are moving from general maintenance into a hosting company built specifically around speed. Most hosting companies just give you the server configuration you asked for. We take a different approach: we analyze your website, figure out why it is slow, and try to cut the load time significantly. If you are loading in ten seconds, our aim is to bring that down to four or five. Once we do that, we also host and maintain the site going forward. That is coming later this year, probably around September, since right now I have a handful of clients to manage and want to scale carefully rather than take on too many sites at once.
Chris Badgett: Speed is one of the most common complaints about WordPress.
Pratik Ghela: I think that is less about WordPress itself and more about how people build their sites and how many plugins they use. WordPress gets blamed for being slow, but that is one of the biggest misconceptions out there. You cannot dump in a pile of plugins, including heavy page builders like Elementor or Visual Composer, and expect a fast result. Those builders are genuinely good for end users designing a page, but the code they output can be pretty bad.
Is Managed WordPress Hosting Always Faster Than Shared Hosting
Chris Badgett: So better hosting is huge for speed?
Pratik Ghela: I would say huge, yes.
Chris Badgett: Is managed WordPress hosting always going to be faster than shared hosting?
Pratik Ghela: It usually is, and a company like WP Engine or Pantheon will generally give you good results. But it does not automatically mean your site will get faster just from switching hosts. There is no guarantee that moving to managed hosting will improve your speed by some fixed multiple. It depends on the plan and the provider.
How To Use Chrome DevTools And Lighthouse To Audit Your Site
Pratik Ghela: There are two main ways to test your WordPress site’s speed. The first is WebPageTest.org, which we have already used. You can also open your browser’s inspector, go to the Network tab, and reload your site to see a full breakdown of what loads and when, plus a recorded video of the page loading, which helps you understand what an actual visitor experiences.
The second is Chrome’s built-in Audits tool, now called Lighthouse. You open your site, click Run Audits, and choose whether to simulate a fast 3G connection, a slower connection, or no throttling at all, and whether to test mobile or desktop.
Time To First Byte Versus Time To First Paint Explained
Pratik Ghela: On the original Academy server, Lighthouse scored performance at 65. After moving the site to my demo server with 4 gigabytes of dedicated RAM, that jumped to 84, just from the hosting change alone.
If you open the trace view in Lighthouse, you can see filmstrip-style screenshots of how the page appeared to a real visitor over time. On the original server, the browser received the first byte from the server at around 650 milliseconds, but then nothing appeared on screen until about 1,500 milliseconds. For a second and a half, the visitor just saw a blank page.
There are two different measurements people often confuse. Time to first byte is when the browser receives the very first byte of HTML from the server. Time to first paint is when the visitor actually sees something meaningful on the screen. Time to first paint should ideally land around 1.2 to 1.5 seconds. On the original server, it was closer to 4.5 seconds, which is rough.
Back on WebPageTest, the same comparison held: the original site loaded in about 4.7 seconds, and just from the server change alone, that dropped to about 2.8 seconds.
Will A Caching Plugin Break Student Logins On An LMS Site
Chris Badgett: A question came in from Donna about whether her host, InMotion Hosting, is any good.
Pratik Ghela: That is hard to answer in the abstract, since not every server at the same hosting company performs the same way, and it depends heavily on the plan. It is a complicated question, not a simple brand-is-good-or-bad answer.
Now let’s move on to improving the site’s time to first byte by installing a caching plugin. The one I use is called WP Fastest Cache.
Chris Badgett: Can you show us how to do that without breaking anything an LMS site depends on, like user logins?
Pratik Ghela: Once the plugin is installed, you enable the cache system and generate a cache for the whole site. You can choose exactly which parts get cached. Importantly, there is an option to not show the cached version to logged-in users, which is exactly how you protect student sessions. There is also a separate option to keep mobile and desktop caches apart, since serving a cached desktop layout to a mobile visitor, or the reverse, can break your site’s responsiveness entirely.
Setting Up A Caching Plugin Step By Step
Pratik Ghela: The rest of the settings are fairly self-explanatory. You want the cache to clear automatically whenever you publish a new post, and to update when you edit an existing one, since the content may have changed.
Then there is HTML minification, CSS minification, and combining multiple CSS or JavaScript files into fewer files, though you want to test that carefully to make sure it does not break your design or functionality. Gzip compression zips everything that travels from the server to the browser, HTML included, before sending it. Browser caching saves images, JavaScript, and CSS locally in the visitor’s browser so repeat visitors do not reload every asset from scratch. You can also strip out the built-in WordPress emoji scripts if you do not need them. Everything past this point in the free version is part of the premium tier, which runs about 49 dollars.
I have the premium version, so let me install it and check the site’s speed with it enabled. Once you turn on caching, you need to generate the cache once by loading the site yourself, which caches the homepage and everything tied to it.
Does Caching Actually Improve Time To First Byte
Chris Badgett: Ziv is asking in the Facebook comments. His site gets good marks on WebPageTest except for time to first byte. Does caching actually help with that?
Pratik Ghela: Yes, it does. Once caching is enabled, the browser no longer has to go back to the server every time to fetch the same resources.
Chris Badgett: Amy is asking what the difference is between a caching plugin and a managed host that does server-side caching. Are they doing the same thing?
Pratik Ghela: Not exactly. Browser caching stores content locally on the visitor’s own device. Server-side caching, which is closer to what a CDN does, stores your content on the server or across the CDN’s own network. After enabling the plugin here, our load time went from about 2.7 seconds down to 2.5 seconds, a savings of about 200 milliseconds. Speed improvements like this tend to come in small increments of 50, 100, or 200 milliseconds at a time rather than one dramatic jump.
Our time to first byte went from 1.7 seconds on the original server down to about 0.5 seconds after moving hosts and enabling caching, roughly a third of where it started.
Why A Missing Favicon Or Other 404 Error Slows Down Your Whole Site
Pratik Ghela: One more thing to check after your site loads: click on the section labeled Waterfall. If you see anything highlighted in red, that means a resource is missing entirely. When a browser requests something like a missing image or favicon file and gets a 404 error back, it still waits a while before giving up on that request, which slows down everything else on the page. It is not an infinite wait, but it does take real time before the browser realizes the file is never coming.
In this case, the site was missing its favicon.ico file, so I grabbed one and uploaded it to the root folder to fix that.
What The Premium Version Of A Caching Plugin Adds
Pratik Ghela: The biggest benefit of the premium version is combining multiple JavaScript files into a single file. If you look at the waterfall chart, you can see how many separate JavaScript files are loading. Every plugin tends to add its own JavaScript file, so a site with 20 or 25 active plugins can end up with 20 or more separate JavaScript requests.
With the older HTTP/1.1 protocol, the browser has to request files one at a time, so more files means more waiting. HTTP/2 lets the server send many files in parallel, which helps a lot, but it is still better to have as few JavaScript and CSS files as possible. The premium version’s job is combining all of those separate JavaScript files into as few files as it can.
Once premium is enabled, you get additional options beyond the free version’s HTML minification: CSS minification, JavaScript minification, combining multiple JavaScript files into one, removing render-blocking CSS and JavaScript, and loading Google Fonts asynchronously. Google Fonts normally load synchronously alongside your CSS and JavaScript, competing for the same loading time. Asynchronous loading means the font only loads once your page actually needs it.
There is also lazy loading for images and iframes, so they only load once they scroll into the visible part of the screen. On a course page full of images, for example, an image far down the page that is not visible yet simply will not load until the visitor scrolls down to it.
The Academy Site’s Full Speed Transformation
Pratik Ghela: After enabling all of the premium optimizations, the Lighthouse performance score went from 84 up to 96, and the page reached a fully rendered state in about a quarter of a second for the visitor.
Chris Badgett: You are going for a perfect score.
Pratik Ghela: Running the homepage test again, we hit 100 in performance. Looking at the trace, the site now starts appearing to the visitor at around 500 milliseconds, compared to about 1.5 seconds earlier, and 4.5 seconds on the very first test.
Comparing every stage side by side: the Academy site started at 4.7 seconds, dropped to 2.8 seconds after the hosting change, dropped again to 2.2 seconds with free caching enabled, and landed at 1.9 seconds with the premium caching features turned on. Time to first byte is still not perfect at this point, but 1.9 seconds overall is a strong result to be happy with.
Auditing Arnold’s Site And Why Heavy Animation Effects Slow Pages Down
Chris Badgett: Arnold posted a link in the chat. He said his site takes about 10 seconds to load. Can you run it through the same test?
Pratik Ghela: Just watching it load, I can already tell it is taking a while. I would get rid of this animated effect right away, since it is visually distracting and appears to be pulling a lot of GPU resources just to render.
Chris Badgett: That is one of the challenges with page builders. They make it easy to add a lot of animation, which you have to be careful with.
Pratik Ghela: Running the full audit now, it is taking about 11 seconds, with the first byte coming in around 4.2 seconds. Even without seeing the back end, I can tell there are a lot of JavaScript files loading, including Revolution Slider, which I would avoid using altogether. There is also a Facebook Customer Chat widget running. A better host alone could likely bring this down to somewhere around four or five seconds.
How To Actually Evaluate Whether A Web Host Is Fast
Chris Badgett: Sometimes it is hard to tell what actually makes a host good, especially when reviews might involve affiliate relationships. How do you personally evaluate a host?
Pratik Ghela: After running into enough of these issues with hosting companies, I learned server management myself, including how to install SSL certificates and how to use SSH, which meant learning some Linux basics. Now I buy VPS servers directly from data centers rather than going through a typical hosting company. That is not something I would recommend for someone without server management experience, since the servers I use do not come with cPanel and require real technical comfort. But it is a big part of why the demo site I have been using gets the speeds it does. Once configured this way, navigating from page to page on that demo site is close to instant.
That speed also comes from the caching plugin essentially serving a full static copy of each page directly, rather than asking WordPress to rebuild the page from scratch every time a visitor requests it.
Is The Gutenberg Editor Faster Than Page Builders Like Elementor Or Divi
Chris Badgett: Kurt is asking whether the Gutenberg block editor is any better from a speed perspective compared to page builder plugins.
Pratik Ghela: It depends on what you are using. Gutenberg itself is not doing anything special to slow things down, but if you are using a theme that adds its own custom blocks on top of Gutenberg, you need to check how clean that block’s HTML actually is. If it is not well optimized, you can end up with the same bloat problem a page builder creates. Sticking to native Gutenberg blocks is generally better than using page builders like Elementor or Visual Composer.
I can show you what I mean visually. If you inspect a single design element built with a page builder, like one div and some text, you often find dozens of nested div elements stacked underneath it just to render that one piece. On a site we built without a page builder, the same kind of section might use a single div, an image, and a heading tag. That much less markup for the same visual result is where a lot of the speed difference comes from.
Chris Badgett: So minimal plugins and minimal extra markup really helps.
Pratik Ghela: Yes. I have seen plugins used for things as small as changing site credit text in the footer. Every one of those adds a little bit of weight.
Chris Badgett: Jack made a comment that hand-coding is not really an option for everybody.
Pratik Ghela: That is fair, and it is part of why I wanted to walk through this today. It is one way to approach it, not the only way.
Speeding Up The Academy Site With Cloudflare’s Speed Settings
Pratik Ghela: One more thing anyone can do is sign up for a Cloudflare account and point your domain to it. Inside Cloudflare, there is a Speed section. Turning that on gives you automatic minification of your JavaScript, CSS, and HTML. Turning on Brotli compression, an algorithm Cloudflare uses to compress your traffic, and turning on Rocket Loader, makes a noticeable difference on top of everything else we have already done.
Chris Badgett: Can you explain what Cloudflare actually does, for anyone who is not familiar with what a CDN is?
Pratik Ghela: A CDN serves your visitors from whichever location is physically closest to them. Say you have one logo file. Cloudflare takes that file and distributes copies of it across somewhere between 200 and 500 data centers around the world. If a visitor comes from Australia, Cloudflare finds its own server closest to that visitor and serves the file from there, instead of sending it all the way from your original server in the United States. That is how a CDN works.
After turning on minification, Brotli compression, and Rocket Loader, the site’s load time dropped all the way down to about one second.
Troubleshooting A Slow First Byte Time On An Already-Optimized VPS
Chris Badgett: Ziv has a question about his own site. Let’s see if we can offer any tips once Pratik is back.
While we wait, speed can feel overwhelming if you are newer to this. Terms like CDN and caching can pile up fast if you are not especially technical, but the short version is: get quality hosting, use a caching plugin correctly, use a CDN or make sure your host handles that for you, and take a minimalist approach to plugins. Those four things alone go a long way.
Ziv’s site is running the WP Rocket caching plugin, on a SiteGround VPS, with Cloudflare enabled and 31 active plugins, and he is hosted in a European data center. Even with all of that in place, his time to first byte is coming in at seven to ten seconds.
Pratik Ghela: That is unexpected. I have never seen a site load in one second the way this test just showed for a different site earlier, so let’s actually look at ziv’s numbers.
Chris Badgett: While that loads, another thing that trips people up is oversized image files.
Pratik Ghela: Definitely. Images always need to be compressed properly. For now, looking at ziv’s site: it is running the Divi theme, specifically a Divi child theme from Elegant Themes, with 31 plugins, which by itself should not be a problem. A time to first byte in the seven to ten second range with a VPS, caching, and a CDN all already in place is not normal. I want to investigate this further, ideally by getting access to look at the site directly.
I noticed there is a PHP function called sleep that can be used to intentionally add a delay to a website. It is possible, though not confirmed, that a previous developer left something like that in the code, since developers who leave a project on bad terms have been known to do that kind of thing. Ziv mentioned the site used to load in about 3.5 seconds, so something changed along the way.
Chris Badgett: Ziv, can you share access so Pratik can take a look?
Ziv shares a login, and Pratik takes a look directly.
Pratik Ghela: I am not seeing an obvious reason for an issue this severe. SiteGround’s VPS and shared plans are usually solid, so this level of slowness is not typical. Ziv mentioned there are two WordPress sites running on this particular server, which by itself is not too many. A server configured like this should realistically load in two or three seconds. Ziv, if you can email me a copy of the site, I can try replicating it on my own server and dig in further, since this looks like a bigger site that will take some real time to investigate properly.
Keeping A Media-Heavy Site Fast Without Sacrificing Image Quality
Pratik Ghela: On the topic of images: you always need to compress them properly. Here is a photography website we built that is genuinely full of images and video, since a photography site cannot get away with low-resolution images. They have to look good.
Even with heavy interactivity, including login with Facebook and Google and a full password reset flow, this site still loads quickly, because it follows the same core principles we have been walking through today. It is possible to have a media-rich, interactive site and still keep it fast, as long as the underlying build follows good practices.
Closing Thoughts And Where To Reach Pratik Ghela
Chris Badgett: As we wrap up, what are you working on, and how can people connect with you?
Pratik Ghela: You can reach me by email at pratik.ghela@pressmate.io. As for what’s next, expect us to keep building genuinely fast websites. We also offer a free trial: we host a copy of your site on our own server so you can see how much faster it runs before deciding whether to buy hosting from us. There is no pressure to purchase just to try it.
Chris Badgett: You took the Academy site from four and a half seconds down to about one second today. That is roughly a four times speed increase, done live, and you showed exactly how at every step, which is genuinely impressive. Thank you for adding so much value and demonstrating your expertise.
We do a fair amount of custom LifterLMS development ourselves too, including custom design and functionality. We are currently building a referral program using LifterLMS and WooCommerce together, where a referral link gives a discount to a new customer and a reward to the person who referred them. Since we build a lot of this custom, we know how to make websites that load quickly and hold up for years instead of breaking down after a few months.
What I have really enjoyed about getting to know you is that you have strong development skills, a real focus on speed, a good design sense, and you are a great communicator. Explaining something this technical to an audience with such different skill levels is not easy, and you did it well. Thank you for coming on.
Pratik Ghela: Be minimal. Build websites that load quickly, and help make people’s experience better in a world where so many visitors are frustrated with slow-loading sites.
Chris Badgett: Thank you, Pratik. I really appreciate it, and thank you for staying up late with us to do this presentation. I hope you have a great rest of your day. Thank you to everyone who came, and thank you for all the kind comments. We really appreciate it.
