How Hosting Affects Website Speed: A Non-Technical Explanation

The Connection Between Your Hosting and Your Speed

Every second your website takes to load, you lose visitors. Studies consistently show that when a page takes longer than three seconds to appear, more than half of mobile users abandon it entirely. That bounce rate climbs higher with every additional second. What most website owners do not realize is that their hosting affects website speed at a fundamental level that no amount of image optimization or clean code can fully compensate for. Your hosting is the foundation — the engine, the location, the hardware, and the software that together determine how quickly your website can respond when someone tries to visit it. At Hosting Captain, we have diagnosed thousands of slow websites, and in the majority of cases, the hosting infrastructure plays a larger role than anything in the website's own code. This guide explains exactly how hosting affects website speed in plain, non-technical language so you can understand what is happening behind the scenes, spot the warning signs of bad hosting, and make informed decisions that keep your site fast and your visitors happy.

Before diving into the mechanics, it helps to understand the broader context of how websites are served to visitors. When someone types your domain name into a browser, a chain of events begins — DNS resolution, server connection, request processing, and finally the delivery of your page. If any link in that chain is slow, the entire experience suffers. Our web hosting basics guide walks through this entire process from scratch, and Mozilla provides an excellent technical primer on how domain names work at the protocol level. With that foundation in place, we can now focus specifically on the speed dimension of hosting — the part that directly determines whether your visitors see your page in under a second or watch a blank screen for five.

Server Location: Why Physical Distance Matters

The Speed of Light Is Not Instant

Data travels through fiber optic cables at roughly two-thirds the speed of light in a vacuum — fast by any human measure, but not instantaneous. Every mile between your hosting server and your visitor adds measurable delay to every single request. If your target audience is in London and your server sits in a data center in Singapore, every page load must cross continents and oceans before the first byte of data even begins its return journey. The round-trip latency alone can add 200 to 400 milliseconds — before the server has done any work at all. In an era where Google uses page speed as a ranking factor and visitors form first impressions in under a second, those milliseconds directly cost you traffic, conversions, and revenue.

Choosing Server Location Strategically

Most reputable hosting providers operate data centers on multiple continents and allow you to select your server location during signup. Hosting Captain recommends choosing a data center as close as possible to the geographic region where the majority of your visitors live. A small business serving customers in Mumbai should not host its website in Dallas, Texas. A blog whose readers are primarily in the United Kingdom gains nothing from a server in Sydney. The rule is simple: shorter physical distance means lower latency, and lower latency means faster page loads. If your audience is globally distributed, a Content Delivery Network — which we will cover in detail later — can replicate your static content to servers around the world, partially compensating for a distant origin server. But the origin server's location still determines the speed of every uncached request, every database query, and every logged-in user session, making it one of the most consequential decisions in how hosting affects website speed.

For a deeper understanding of the DNS infrastructure that routes traffic from domain names to server IP addresses — the very first step in every page load — our complete hosting glossary defines every term you will encounter in your hosting dashboard, including A records, nameservers, and TTL values that directly affect how quickly users reach your server.

Server Resources: The Engine Under the Hood

CPU: The Brain That Processes Every Request

The central processing unit inside your hosting server is what executes the actual code that generates your web pages. Every time someone visits a WordPress site, the server's CPU must run PHP scripts that query the database, assemble templates, process shortcodes, and construct the final HTML output. A server with fast, modern processors and generous CPU allocations handles this workload effortlessly, generating pages in tens of milliseconds. A server with outdated or overcommitted processors — common on ultra-budget hosting plans — takes hundreds of milliseconds or even multiple seconds to complete the same work. Worse, if your hosting provider has packed too many accounts onto a single server, the CPU is constantly busy servicing other websites, leaving your visitors waiting in a queue for processor time that arrives in slices too thin to deliver acceptable speed.

RAM: The Short-Term Memory Your Site Depends On

Random access memory holds actively used data for near-instant retrieval, functioning as the server's short-term memory. When a WordPress site has sufficient RAM available, frequently accessed database queries, pre-compiled PHP code, and other reusable data stay cached in memory where they can be retrieved in microseconds rather than milliseconds. When RAM runs short — either because your plan allocates too little or because the server is oversold — the server must constantly swap data between memory and storage, a process that is orders of magnitude slower. This is why two hosting plans that both advertise SSD storage can deliver dramatically different speeds: one has enough RAM to keep your site's working data in memory, and the other does not. For a thorough explanation of how shared hosting divides resources among tenants, read our complete guide to shared hosting, which covers the resource allocation model in detail.

Storage: Why SSD and NVMe Are Not Just Marketing Terms

The type of storage your hosting server uses directly affects how quickly it can read your website's files, serve your images, and execute database queries. Traditional hard disk drives store data on spinning magnetic platters accessed by a mechanical arm — a technology limited by how fast physical components can move. Solid-state drives eliminate all moving parts, reading and writing data electronically at speeds that make HDDs look glacial by comparison. Modern NVMe drives, which connect directly to the server's PCIe bus rather than going through the slower SATA interface, are another leap forward entirely. A server running on NVMe storage can serve pages three to ten times faster than one using spinning hard drives under the same load conditions. In 2026, any hosting provider still using mechanical hard drives for website storage is delivering a fundamentally inferior product, regardless of how attractive the price appears. Hosting Captain's infrastructure runs exclusively on NVMe storage because the speed difference is no longer a premium feature — it is a baseline requirement for acceptable website performance.

Server Software: The Invisible Speed Multiplier

Web Server Software: Apache vs LiteSpeed vs Nginx

The web server software running on your host is the program that receives incoming requests from browsers and decides how to handle them. Apache, the oldest and most widely deployed web server, processes requests using a model that spawns a new process or thread for each connection — an approach that works but becomes resource-intensive under heavy load. LiteSpeed Web Server, which has gained enormous adoption in the shared hosting industry, uses an event-driven architecture that handles thousands of simultaneous connections with dramatically lower memory and CPU consumption. In controlled benchmarks, LiteSpeed consistently delivers Time to First Byte values two to six times faster than Apache for cached content. Nginx, another event-driven web server, achieves similar results and is particularly popular in VPS and cloud hosting environments. Your hosting provider's choice of web server software is not a trivial technical detail — it is a primary determinant of how quickly your site responds under load. At Hosting Captain, every shared hosting plan runs on LiteSpeed with the LSCache plugin pre-configured, ensuring that the web server layer is never the bottleneck in your site's performance.

PHP Version and Configuration

Most dynamic websites — including every WordPress site — run on PHP, a server-side scripting language that generates HTML pages on the fly. The version of PHP your host runs matters enormously for speed: PHP 8.x executes code roughly twice as fast as PHP 5.6, the version that was standard on many shared hosting servers just a few years ago. Beyond the version number, PHP's configuration parameters — how many processes can run simultaneously, how much memory each process can consume, and how compiled code is cached — directly determine how many visitors your site can serve concurrently without slowing to a crawl. A hosting provider that keeps PHP updated to the latest stable release and configures PHP-FPM pools with appropriate resource limits for each plan tier has already done more for your site's speed than a dozen optimization plugins ever could. Our cPanel guide shows you exactly where to find your PHP version and configuration settings in your hosting control panel, making it easy to verify that your host is not running outdated software that silently drags down your performance.

The Noisy Neighbor Problem: Other Sites on Your Server

This is the aspect of how hosting affects website speed that catches the most beginners by surprise. On shared hosting, your website does not live alone — it shares a physical server with dozens, hundreds, or in extreme cases thousands of other websites. All of those sites draw from the same pool of CPU, RAM, storage I/O, and network bandwidth. When those other sites are idle or serving low traffic, your site performs well. But when one of your virtual neighbors experiences a traffic surge, runs a poorly optimized script, or gets hit by a bot attack, it can consume a disproportionate share of shared resources, slowing down every other site on that same machine — including yours.

The hosting industry calls this the noisy neighbor problem, and it is the single most common reason why one shared hosting plan at $3 per month performs drastically differently from another at $8 per month, even when both advertise the same storage and bandwidth numbers. The more expensive plan typically comes from a provider that deploys stronger tenant isolation — technologies like CloudLinux LVE that set hard limits on how much CPU, memory, and I/O any single account can consume. Without these protections, a single badly behaved website can degrade the experience of every other customer on the server, and you will have no way of knowing what caused your slowdown or when it will happen again.

The severity of the noisy neighbor problem is directly proportional to how aggressively your hosting provider oversells its servers. Overselling is the practice of selling more total resources than a server physically possesses, betting that most customers will never use their full allocation simultaneously. Some overselling is standard industry practice and harmless when managed responsibly. But extreme overselling — packing 2,000 accounts onto a server designed for 500 — makes the noisy neighbor problem chronic and unavoidable. Our shared hosting guide explains how to evaluate whether a provider's resource allocation model will protect your site or leave it vulnerable to neighbors you cannot control.

TTFB Explained Simply: The Number That Tells the Truth

Time to First Byte is the single most revealing metric for understanding how hosting affects website speed. Measured in milliseconds, TTFB captures the delay between the moment a browser requests a page and the moment the server sends back the very first byte of data. It does not measure how long images take to download, how quickly CSS renders, or how efficiently JavaScript executes. It measures only the server's responsiveness — how fast the hosting infrastructure itself reacts to an incoming request. This makes TTFB the cleanest signal of hosting quality available, stripped of confounding variables like image file sizes or theme efficiency.

Think of TTFB like the time between ringing a doorbell and hearing someone start to open the door. If that pause is half a second, the visit feels responsive. If it is three seconds, you wonder whether anyone is home. For websites, a TTFB under 200 milliseconds is excellent, 200 to 500 milliseconds is acceptable, 500 milliseconds to 1 second is noticeably slow, and anything above 1 second indicates a hosting problem that requires investigation. Google's own guidance recommends keeping TTFB under 800 milliseconds, and their Core Web Vitals assessment — which directly influences search rankings — penalizes sites that consistently exceed that threshold. When you test your site's speed and see a high TTFB, you know with near certainty that the bottleneck is at the hosting level, because nothing in your website's own code can make the server respond faster to the initial request.

Why Cheap Hosting Is Often Slow

The economics of web hosting are straightforward: server hardware, data center space, power, cooling, network connectivity, software licensing, and support staff all cost real money. A provider selling shared hosting at $1.99 per month must cut corners somewhere to remain profitable, and those corners directly translate into slower websites for customers. The most common cost-cutting measures include running outdated server hardware long past its reasonable service life, packing far too many accounts onto each server, using slow mechanical hard drives instead of SSDs or NVMe, providing minimal RAM allocations that force constant disk swapping, skimping on CPU cores or using older-generation processors, deploying Apache without proper optimization instead of LiteSpeed or Nginx, and maintaining dangerously outdated PHP versions because upgrading would risk breaking legacy customer sites.

Cheap hosting providers also tend to invest minimally in their support infrastructure. When your site slows to a crawl at 10:00 PM on a Saturday, the difference between a provider with 24/7 support staffed by engineers who can diagnose and resolve a server-level issue in minutes, versus a provider whose ticket system promises a response within 48 hours, is the difference between a brief inconvenience and a weekend of lost visitors. Hosting Captain has always believed that transparent, honest pricing paired with infrastructure that is not cut to the bone produces better outcomes for customers than the race-to-the-bottom pricing that defines the budget segment of the hosting market.

The renewal pricing trap compounds this problem. Many budget hosts advertise introductory rates of $1.99 to $2.99 per month that quadruple at renewal, but the infrastructure quality does not improve along with the price — you end up paying mid-tier rates for bottom-tier hardware because you were drawn in by a promotional discount that obscured the true cost. When evaluating hosting costs, always price your decision based on the renewal rate and ask yourself whether the infrastructure and support quality justify that price over a multi-year relationship. A plan at $8 per month on NVMe storage with LiteSpeed and CloudLinux isolation is genuinely less expensive in value-per-dollar terms than a plan at $3 per month on aging hardware that costs you visitors, rankings, and revenue through chronic slowness.

How to Test Your Hosting Speed

Tools That Measure What Matters

Testing your hosting speed does not require technical expertise — just the right tools and a basic understanding of what the numbers mean. Google's PageSpeed Insights is the most accessible starting point: enter your URL, run the test, and pay attention specifically to the "Reduce initial server response time" diagnostic and the TTFB value shown in the lab data. GTmetrix provides a more detailed breakdown, including a waterfall chart that visualizes exactly how long each component of your page takes to load, with the very first bar representing your server's initial response time. WebPageTest, the most comprehensive free testing tool, lets you select the test location, browser, and connection speed, giving you the most realistic picture of how your hosting performs for visitors in specific geographic regions.

Isolating Hosting from Website Factors

To determine whether your hosting is the problem or your website is, create a simple static HTML file — a plain text file with no images, no CSS, no JavaScript, and no database calls — and upload it to your hosting account. Test that file with the tools mentioned above. A static HTML file should load with a TTFB well under 200 milliseconds on any competent hosting. If your plain HTML file takes 500 milliseconds or more to begin loading, the problem is definitively your hosting infrastructure, because a file that requires zero server-side processing cannot be slowed down by anything in your website's code. If your static HTML file loads quickly but your actual WordPress pages do not, the bottleneck is somewhere in your website's theme, plugins, or database structure — and the hosting itself is performing adequately.

Run this test from multiple geographic locations using WebPageTest's server location selector. A hosting server in Frankfurt that delivers excellent TTFB to visitors in Germany may show terrible results when tested from Sydney — not because the hosting is slow, but because the physical distance introduces unavoidable latency. This pattern tells you that the solution is a CDN rather than a hosting upgrade. Understanding the distinction between hosting problems, website problems, and distance problems is the skill that separates site owners who throw money at the wrong fix from those who solve the actual issue the first time.

Simple Fixes That Dramatically Improve Speed

Caching: The Single Most Effective Optimization

Caching is the practice of storing a pre-generated version of your page so that the server can deliver it instantly rather than rebuilding it from scratch for every visitor. Without caching, every page load triggers a cascade of work: PHP scripts execute, database queries run, templates assemble, and the final HTML is constructed — a process that consumes CPU, RAM, and time. With caching, the server simply hands over a static HTML file that was generated once and reused thousands of times, reducing the server workload per request by 90 to 99 percent. A website that can handle 20 simultaneous visitors without caching can often handle 500 to 1,000 with caching enabled, using the exact same hosting plan.

There are multiple layers of caching that work together. Page caching stores complete HTML pages, either on the server's disk or in memory. Browser caching instructs visitors' browsers to save CSS, JavaScript, and image files locally so they do not need to be re-downloaded on every page visit. Object caching stores the results of expensive database queries in memory through systems like Redis or Memcached. Opcode caching stores pre-compiled PHP code so the server does not have to compile the same scripts repeatedly. A quality hosting provider configures these caching layers at the server level, where they operate faster and more comprehensively than any plugin can achieve. If your host runs LiteSpeed, the LSCache plugin for WordPress provides server-level page caching with minimal configuration. If your host runs Nginx, FastCGI cache accomplishes the same goal. For a walkthrough of where these settings live in your hosting dashboard, consult our cPanel explained guide.

Content Delivery Networks: Bringing Your Site Closer to Visitors

A Content Delivery Network is a distributed network of servers stationed in data centers around the world, each one capable of serving your static content — images, CSS files, JavaScript files, and fonts — to visitors from the location physically closest to them. When a visitor in Tokyo accesses a site whose origin server is in New York, the CDN serves the heavy static assets from a server in Tokyo, eliminating the trans-Pacific round trip for the bulk of the data that makes up a modern web page. The origin server still handles dynamic requests like database queries and form submissions, but the largest and slowest parts of each page load are handled locally by the CDN.

Cloudflare's free plan includes a global CDN with over 300 data center locations, making it the most accessible option for site owners at every budget level. The setup process typically involves changing your domain's nameservers to point to Cloudflare, after which the CDN automatically caches and distributes your static assets. The performance improvement is most dramatic for sites with geographically dispersed audiences and for media-heavy pages with large image files. Even for a local business serving a single city, a CDN provides additional benefits including DDoS protection, bandwidth savings, and improved reliability during traffic spikes — all at no cost on the free tier.

Image Optimization: Shrinking Your Largest Files

Images are almost always the largest files on any web page, and oversized images are the most common self-inflicted performance wound we see at Hosting Captain. Uploading photographs directly from a modern smartphone or digital camera — where a single image can easily be 5 to 10 megabytes — and displaying them at 800 pixels wide is like renting a cargo truck to deliver a single envelope. The browser still has to download the full 10-megabyte file, then resize it down to the display dimensions, wasting bandwidth and time on both ends of the connection.

The fix is straightforward: resize images to the maximum dimensions they will actually be displayed at before uploading them, compress them using tools like TinyPNG, ShortPixel, or the Smush plugin for WordPress, and serve them in modern formats like WebP or AVIF that deliver equivalent quality at substantially smaller file sizes than JPEG or PNG. Many hosting control panels include image optimization tools, and WordPress plugins like Smush and Imagify automate the entire process — compressing images on upload, converting them to WebP, and serving appropriately sized versions based on the visitor's screen. These optimizations require no ongoing effort once configured and can reduce total page weight by 50 to 70 percent on image-heavy pages.

Upgrading Your Plan: When Small Fixes Are Not Enough

Sometimes your hosting is simply inadequate for what your website has become. Caching, CDNs, and image optimization can stretch a plan's capacity significantly, but they cannot create resources that do not exist. If your site has grown from a hobby blog with 1,000 monthly visitors to a business asset with 50,000 monthly visitors, if you have added e-commerce functionality that generates uncacheable dynamic pages with every cart action, or if your TTFB remains stubbornly above one second after implementing every optimization described above, the solution is not another plugin — it is a hosting plan with more CPU, more RAM, and better isolation from neighboring accounts.

Upgrading within the same provider is usually straightforward: most hosts allow you to move from an entry-level shared plan to a premium shared plan or from shared hosting to a managed VPS with minimal downtime and no data migration required. The key is to upgrade before you hit a hard resource ceiling, not after — because by the time your site is erroring out with "508 Resource Limit Reached" messages or your provider has suspended your account for excessive resource usage, you have already lost visitors and revenue that an earlier upgrade would have preserved. Monitor your resource usage through your hosting control panel's metrics dashboard monthly, and act when you are consistently above 70 to 80 percent of any given limit.

When Your Host Is the Problem vs When Your Website Is

Diagnosing the true source of a slow website requires systematically eliminating variables until only one explanation remains. The static HTML test described earlier is the definitive first step: if a plain HTML file loads slowly, your host is the bottleneck, no further investigation required. If the plain file loads fast but your WordPress pages do not, the problem lives in your website's code or configuration. From there, disable all plugins temporarily and switch to a default WordPress theme like Twenty Twenty-Five. If speed returns to normal, re-enable plugins one by one, testing after each activation until you identify the specific plugin causing the slowdown. If speed does not return to normal even with all plugins disabled and a default theme active, the problem is likely in your database — bloated post revisions, orphaned metadata from deleted plugins, or accumulated spam comments that slow down every database query.

Certain symptoms point definitively toward hosting. Consistently high TTFB across all pages, even simple ones, indicates the server is underpowered or oversold. Intermittent slowdowns that correlate with specific times of day — for example, every weekday at 9:00 AM when businesses in the server's timezone come online — suggest resource contention with other accounts on a shared server. Errors related to resource limits, database connection failures, or PHP memory exhaustion that appear in your error logs or WordPress debug output indicate that your plan's allocated resources are insufficient for your site's workload. Conversely, symptoms that point toward your website include: a particular page being slow while others are fast (indicates a problem on that specific page, not the server), speed degrading gradually over months as you add content and plugins (indicates cumulative bloat), and mobile performance being poor while desktop is fine (indicates front-end issues like unoptimized images or render-blocking resources rather than server problems).

If you determine that your host is the bottleneck, the solution set is limited but effective: upgrade to a higher-tier plan with more resources, migrate to a provider that uses faster infrastructure (LiteSpeed, NVMe storage, newer processors), or move from shared hosting to a VPS where resources are guaranteed rather than shared. If your website is the bottleneck, the optimization strategies covered in the previous section — caching, CDN, image compression, plugin auditing, and database cleanup — will resolve the majority of cases without requiring a hosting change. The most expensive mistake is upgrading hosting to solve a website problem, or spending weeks optimizing a website that is hosted on fundamentally inadequate infrastructure. The diagnostic steps outlined here prevent both of those scenarios by identifying the true bottleneck before you invest time or money in fixing the wrong thing.

How Hosting Captain Keeps Your Site Fast

At Hosting Captain, we built our hosting infrastructure around a simple principle: every layer of the stack should be fast by default, not fast only after the customer configures a dozen optimization plugins. Every shared hosting plan runs on LiteSpeed Web Server with LSCache pre-configured, delivering server-level page caching that does not depend on third-party plugins. Our servers use exclusively NVMe solid-state storage, eliminating disk I/O as a bottleneck even under heavy concurrent load. PHP runs the latest stable 8.x release with OPcache enabled and PHP-FPM pools configured for each plan tier's resource allocation. CloudLinux LVE enforces hard resource limits that protect every tenant from noisy neighbors, ensuring that another customer's traffic spike cannot degrade your site's performance. And every plan includes free SSL certificates with automatic provisioning and renewal, because HTTPS is not a premium feature — it is a baseline requirement for security, trust, and search engine visibility.

We also believe that speed optimization should not require a computer science degree. Our support team helps customers configure caching, set up Cloudflare CDN integration, identify plugin conflicts that degrade performance, and interpret the speed test results that guide optimization decisions. The hosting industry has a long history of treating speed as an advanced topic that only developers need to understand. We reject that premise. Understanding how hosting affects website speed is not optional knowledge for a site owner whose business depends on visitors finding, loading, and engaging with their content. It is foundational knowledge, and it belongs in the hands of every person who pays for a hosting plan — regardless of their technical background. If you are ready to experience hosting that is fast from day one, explore our plans or reach out to our team for a personalized recommendation based on your specific site and traffic expectations.

Frequently Asked Questions

Q: How much does hosting actually affect website speed?

Hosting is the single largest factor in server response time — the time between a visitor's browser requesting a page and the server beginning to send data back. While content optimization like image compression and code minification affects how quickly the full page renders, the hosting infrastructure determines the floor below which your speed cannot go. A site with perfect optimization on slow hosting will still have slow Time to First Byte, and TTFB is the metric that triggers every subsequent step in the page load process. In practice, moving from budget shared hosting on outdated hardware to quality shared hosting on LiteSpeed with NVMe storage can cut TTFB from 1,500 milliseconds to under 200 milliseconds before any content optimization is performed — a seven-fold improvement that comes entirely from the hosting layer.

Q: Does server location still matter in 2026 with CDNs available?

Yes, and significantly. CDNs cache and distribute static files — images, CSS, JavaScript — to edge servers near your visitors, which dramatically reduces the download time for those assets. However, CDNs do not accelerate dynamic requests: uncached PHP processing, database queries, logged-in user sessions, and fresh content that has not been pre-warmed in the CDN cache all still travel the full distance to your origin server and back. For brochure sites with mostly static content, a CDN paired with a distant but well-provisioned server can produce acceptable results. For interactive sites, e-commerce stores, membership platforms, or any site where visitors frequently trigger uncached requests, the origin server's location relative to your primary audience remains a critical performance factor that a CDN cannot fully compensate for.

Q: What is a good TTFB, and how do I improve it?

A TTFB under 200 milliseconds is excellent, 200 to 500 milliseconds is acceptable, and anything consistently above 800 milliseconds indicates a problem that needs attention. Improving TTFB starts with verifying that your hosting infrastructure is adequate: ensure your plan uses SSD or NVMe storage, runs a modern web server like LiteSpeed or Nginx, deploys the latest stable PHP version, and provides sufficient RAM allocation for your site's workload. Next, implement server-level page caching — this is the single most impactful change because it eliminates PHP and database processing for the majority of requests. If your audience is geographically distant from your server, add a CDN to reduce latency for static assets and consider migrating to a data center closer to your primary visitors. Finally, if all optimization steps fail to bring TTFB below acceptable thresholds, your hosting plan is simply underpowered for your current traffic and workload — an upgrade is the appropriate next step.

Q: Can shared hosting ever be fast, or do I need a VPS?

Quality shared hosting on modern infrastructure — NVMe storage, LiteSpeed Web Server, CloudLinux LVE isolation, and PHP 8.x — can deliver excellent speed for the websites that fit its resource model: content-driven sites with effective caching, moderate traffic volumes, and standard software stacks. The key variable is not whether the server is shared but how the provider configures that shared environment. A shared host with strong tenant isolation, generous per-account resource limits, and properly configured caching can deliver faster page loads than a poorly configured VPS with inadequate resources. The decision to upgrade from shared to VPS should be driven by specific signals — consistent CPU throttling, memory exhaustion errors, the need for custom server software, or traffic volumes that exceed what shared resource ceilings can accommodate — rather than by an assumption that shared hosting is inherently slow.

Q: How do I know if my slow site is my host's fault or my fault?

Create a plain HTML file with no images, no CSS, and no server-side code, upload it to your hosting account, and test its load time using WebPageTest or GTmetrix from multiple geographic locations. If this bare file loads slowly — TTFB above 500 milliseconds — the problem is your hosting infrastructure. If the plain file loads quickly but your actual website pages are slow, the problem is in your website's theme, plugins, database bloat, or content optimization. You can further isolate website-side issues by temporarily disabling all plugins and switching to a default WordPress theme; if speed improves dramatically, re-enable elements one at a time to identify the specific culprit. This diagnostic sequence costs nothing, requires no technical expertise beyond creating a text file, and reliably distinguishes hosting problems from website problems in under thirty minutes.