The number everyone shops on stopped mattering
Almost every hosting plan a Mabank business gets shown is sold on two figures: gigabytes of storage and monthly bandwidth. Both stopped being meaningful specifications more than a decade ago. They survive on the sales page because they are easy to print, easy to line up side by side, and impossible to argue with.
The arithmetic ends the argument quickly. In the HTTP Archive's July 2025 crawl, the median web page weighed 2,164 KB on mobile and 2,412 KB on desktop. A brochure site for a marina on Cedar Creek Lake, a boutique on TX-334, or a septic contractor working Kaufman and Henderson counties is a few dozen pages, a contact form and a folder of job photos — pages, theme, images and database together normally landing well under a gigabyte. Every plan on the market clears that by an order of magnitude, starting with the cheapest.
So when one plan advertises ten gigabytes and the next fifty, neither number will ever be the constraint; you are being invited to compare on a dimension you cannot lose. Meanwhile the things that genuinely go wrong — a slow server at nine on a Monday morning, a backup nobody has tested, a PHP version two years past its support date, a support desk that will not open an error log — appear nowhere on that chart. Bandwidth is the same story in a different unit. What matters is not how much you are allowed to send. It is how quickly the server starts sending it.
What shared hosting actually is, and why the neighbors are the product
Shared hosting means one server runs many customers' sites at once. Each account gets a directory on a shared filesystem and a slice of the same processor, memory, disk and IP address. When a browser asks for your domain, the web server reads the Host header — the line in the request naming the site being asked for — and matches it to a configuration entry pointing at your directory. That mechanism, name-based virtual hosting, is why hundreds of domains can live behind a single IP address.
The consequence is the part nobody explains at the point of sale: your site's speed depends partly on what everyone else on the machine is doing. That is the real difference between a very cheap host and a moderately priced one. Not the feature list — density, and whether the host enforces per-account limits so one runaway neighbor cannot drag the rest down.
Those limits also produce a failure mode worth naming. When an account hits its own ceiling — the per-account controls enforced by CloudLinux, cPanel entry processes, or PHP's memory limit — the site does not get slow. It returns a 503 or a 508 and stops. A site that is intermittently down rather than intermittently slow is usually hitting a limit, not losing a race.
What happens between the request and the page is where the time goes. A static file is read off disk and returned in milliseconds. A WordPress page is handed to a PHP worker, which boots WordPress, runs every active plugin, queries the database and assembles the HTML before answering — so thirty plugins is thirty plugins' worth of work before your homepage exists. Caching skips that sequence and hands back saved HTML, which is also why caching hides a slow host until a logged-in user or a form submission bypasses it.
The five things that actually vary between hosts
In rough order of how much a visitor feels them:
- Time To First Byte. TTFB is how long the server takes to start answering after the request arrives. Google's published guidance treats 0.8 seconds or less as good and anything over 1.8 seconds as poor. TTFB is deliberately not one of the Core Web Vitals, but it is the floor underneath them — nothing paints on screen before the bytes arrive. Google's TTFB documentation is the reference, and it is readable.
- Uptime, and what the guarantee actually pays out. The percentage is meaningless until you convert it into hours, which is the next section.
- PHP version, and how fast the host adds new ones. As of August 2026, PHP 8.0 and 8.1 are fully end-of-life. 8.2 gets security fixes only through the end of 2026 and 8.3 through the end of 2027; 8.4 and 8.5 are in active support. A host whose newest option is years old is telling you how it is run. The official support schedule is public and takes ten seconds to check.
- Backup frequency, retention, and whether you can restore without asking. Daily backups with seven days of retention do nothing for a defacement you noticed three weeks late. Ask how far back the copies go, whether they live on a different machine, and whether you can restore one yourself at eleven at night.
- Who answers support, and whether they can read a PHP error log. On a bad day this is the entire product, and no features table will tell you.
Server location matters a little: visitors to a Kaufman County business are overwhelmingly in the DFW area, so a Texas-region data center shaves real milliseconds off the round trip.
What an uptime percentage means once you convert it to hours
Uptime is quoted as a percentage because a percentage sounds reassuring. Convert it and it stops. A year is 8,760 hours.
- 99% allows 87.6 hours of downtime — three days, fifteen hours and thirty-six minutes a year.
- 99.9% allows 8.76 hours — eight hours and forty-five minutes a year, roughly forty-four minutes in an average month.
- 99.95% allows about four hours and twenty-three minutes a year.
- 99.99% allows about fifty-two and a half minutes a year.
The distance between 99% and 99.9% is the distance between a long weekend offline and a lunch break.
The second half is less comfortable. Most uptime guarantees pay out in hosting credit rather than money, and only if you notice the outage, document it and file a claim inside a window you probably have not read. That is a marketing instrument, not insurance. Read the number as a statement of how a host intends to operate, then judge it on something more useful: whether it tells you, unprompted, when something broke.
How hosting is priced, and where the trap is
Prices are rendered from a single source rather than typed into prose, so they cannot quietly drift page by page. The structure is what is worth explaining, because the structure is where small businesses get caught.
The promotional term
The industry norm is a deeply discounted first term, frequently twelve to thirty-six months paid up front, renewing at a multiple of the introductory rate. The advertised figure is not the price of hosting; it is the price of the first term. Find the renewal rate before buying — it is published, usually two clicks away — and build the budget on that.
"Unlimited" storage and bandwidth
Every unlimited plan carries limits elsewhere in the acceptable use policy: a cap on the number of files, a processor ceiling, a concurrent-process limit. The limit you eventually hit is never the one that was advertised.
What actually drives cost
Density, support staffing, backup retention, and where the backups live. A host that holds a month of off-server copies and employs people who can read a log carries costs a host packing accounts onto a box does not. Annual billing is cheaper than monthly for the ordinary reason — it removes churn and failed cards — but neither is a commitment worth making before you have seen how a host behaves on a bad day.
Your host and your domain are not the same purchase
These are two different industries under two different sets of rules, and the difference is not academic.
Web hosting is an unregulated commercial service. There is no accreditation, no licensing body, and nobody vets your host. If it vanishes tomorrow, no policy authority can compel it to hand your files back.
Domain registration is the opposite. Only ICANN-accredited registrars may sell registrations in .com, .net and .org, and every one operates under contract — including ICANN's Transfer Policy, which sets out what a registrar must do when you want to move a name, and how quickly. A registrar that stalls is in breach, and the compliance process works.
So: keep the registration somewhere you personally control, separate from the host. Do that and the host becomes replaceable, and leaving a bad one is an afternoon of work. Let the host hold the registration and leaving becomes a negotiation with the party holding the only copy of your address.
When a Mabank business does not need hosting from us
Four situations, and we run into every one of them.
You have no website and do not want one. For a single-location trade — a plumber in Payne Springs, a boat mechanic in Tool, a septic contractor working the east side of the lake — a complete Google Business Profile and an active presence in the Cedar Creek Lake Facebook groups genuinely do most of the discovery work, and the phone does the rest. Hosting starts earning its keep when there is something a listing cannot hold: service-area pages, a price list, a booking form, before-and-after photos. Until then it is a bill with no job.
Your store already runs on Shopify, Square Online or Etsy. Those platforms host themselves. Selling you hosting for a Shopify store is selling you a domain and calling it hosting.
Your site is one page, with no forms, no login and no CMS. That does not need PHP hosting at all. Static hosting is cheaper, faster and effectively unhackable, because there is no database and no code on the server for anyone to exploit.
Somebody is upselling you to a VPS or a "cloud" plan. A brochure site is nowhere near needing one. The honest trigger for leaving shared hosting is a specific symptom — sustained processor-limit hits, a store with genuinely concurrent checkouts, a membership site where nothing can be cached — not ambition about traffic that has not arrived.
How we run hosting around Cedar Creek Lake
We are based in Kaufman and we serve Mabank, Gun Barrel City, Seven Points, Payne Springs, Kemp, Athens, Canton and the rest of the Cedar Creek Lake area. Bill Hartzer founded this business in 2003. The three sites we point to publicly are EmolaFarm.com in Mabank, HCFoodPantry.org for the Henderson County Food Pantry, and MabankOnline.com, which is ours.
In practice: current PHP versions switchable per site; off-server backups with retention you can use; certificates renewed automatically rather than sold as a line item; and a straight answer when the thing you are asking about is not a hosting problem. A large share of "the host is slow" tickets are a five-megabyte hero image, and we will say so instead of taking the migration.
We also do not hold anything hostage as a retention strategy. If you leave, you get a full archive of files and database, an export of your DNS records, and cooperation with whoever is taking over. That is worth asking your current provider to put in writing.
Common questions
Can I keep my current domain name if I move hosting to you?
Yes, and you can keep it registered where it is. Hosting and domain registration are separate purchases from separate industries. Moving a site normally means changing one DNS record so the name points at the new server — the registration itself does not have to move at all. We generally recommend it does not, because keeping the registration in an account you personally control is what makes every host, including us, replaceable.
How much storage does a small business website really use?
Less than almost anyone expects. A typical twenty to forty page brochure site with a photo gallery usually sits under a gigabyte in total, though we have not found a published dataset that measures this properly, so treat it as an estimate rather than a number. The practical point stands either way: the storage allowance on essentially every plan sold today is far larger than a local business site will use, so it is not a useful basis for choosing between plans.
My website is slow. Will moving hosts fix it?
Sometimes, and often not. Measure first. If the server starts answering in a couple of hundred milliseconds but the page still takes six seconds to appear, the server is not the problem — an oversized image, a page builder and thirty active plugins are. Moving that site to a faster host changes almost nothing, and we would rather fix it where it sits. If the server itself is taking well over a second to begin answering, that is a hosting problem and a move is a reasonable answer.
What happens to my email if I move the website?
Nothing, if the move is done properly, because the records that direct mail are separate from the record that directs the website. The damage happens when someone changes nameservers instead of changing a single record, and the new host's default configuration quietly redirects mail to an empty mailbox on the web server. Mail delivered during that window is generally not recoverable. We copy mail routing before anything else moves, and we leave it pointing wherever it already works.