Updated: July 2020
There are no affiliate links on PagePipe.
Technobabble sounds like sophisticated language. But it’s incomprehensible techno-jargon. It conveys a false impression of meaningful scientific content. It’s deceptive, disingenuous, unfair, or nonsense. It’s a method of misleading with pure presumptuous rubbish. Meaningless technical language overwhelms and confuses the audience, masking the presenter’s dishonesty. It’s an indicator of propaganda.
Kinsta is a managed WordPress hosting provider founded in 2013. They say they’re obsessed with maximum speed performance. Hey! We’re obsessed with speed performance, too. We should be happy cousins. But we’re not. Why?
Because Kinsta expels technobabble. Spewing.
Technobabble bores us to distraction, frustration, and irritation. It smells funny.
Technobabble gives an impression the speaker knows things the audience doesn’t. Try decoding jargon. It’s then obvious it’s unclear, pretentious, and unacceptable. Even novice listeners detect careless technobabble as a sign of dishonesty and insincerity.
Technobabble doesn’t describe reality. The presenter picks things out or makes them up, to suit his purpose. Deceived by web myth, an innocent person repeats misinformation without intent to deceive others. A false manipulation or misrepresentation is perpetuated. Speed myth erupts from the mouths of supposed experts. Often with hidden agendas of secret or ulterior motives.
Ivory-tower pseudosciences within an industry convey confusing, misleading, or nonsensical ideas using technobabble. Multi-syllabic scientific jargon gives false impressions. It implies bold laboratory research and hard facts. Technobabble takes a simple concept and describes it in an overworked scientific manner. This masks its inherent simplicity.
Intentional technobabble convinces audiences the science explained is true. Even though it may not be. Serious people will accept a meaningless idea wrapped in enough impenetrable language.
So we sat through a 1-hour boring seminar on speed by Kinsta representative Brian Li. He spread many common speed untruths. We share the speed errors below. Keep reading:
Kinsta Speed Technobabble
by Brian Li
Here’s what Brian had to say about speed and Kinsta benefits in the free hour-long online seminar.
PHP version benefits are puny.
First Brian happily told us, “PHP 7 speeds up your site 3x.”
This is wrong. It speeds up the PHP code transfers. Your website also has a ton of other web assets that completely overwhelm this meager gain. Things like heavy images, offsite scripts, advertising, email automation, chat boxes, sliders, animation, videos, etc. These are where the speed problems lie. Not in speeding up PHP. That’s insignificant.
Database type? Does it matter? How much?
Brian told us “MariaDB is a faster alternative to MySQL database used by WordPress.” But didn’t tell us how much faster or how to get it. Only that if you buy Kinsta Hosting, you get it free. Well, it’s included in the price anyway. We suspect it’s not much help.
MariaDB shows an improved speed when compared to MySQL. MySQL exhibits a slower speed when compared to MariaDB. With the Memory storage engine of MariaDB, an INSERT statement can be completed 24% faster than in the standard MySQL. The memory storage engine of MySQL is slower compared to that MariaDB. – SOURCE
Specsmanship is the inappropriate use of specifications or measurement results to establish presumed superiority over competitors. Especially when no such superiority exists. We also call this vanity metrics.
Speeding up the database by 25 percent is fine and dandy. But
MariaDB doesn’t speed up your website by 25 percent. It’s the same gotcha as PHP gains. It doesn’t speed up the worst heavy assets like ads, third-party scripts, or image loading. Bragging about this is specsmanship.
Disk Drive Type and RAM are important? HDD vs SSD Brag
Bryan said, “SSD like Kinsta uses are better than magnetic drives.” Why? “Because read/write times are better and fetching is faster,” he says, “A fast server is better.”
This is true. But does it make a difference in real load time? Nope.
Sorry. We’ve never seen server options make any difference in actual load time. Mechanical spinners give the same poor quality Time To First Byte as Solid State Drives. That’s right. In real-world comparisons, the gain is unnoticeable. Vaporous specsmanship.
Brian Li then talks about Kinsta’s Fast RAM and caching benefits. And mentions that virtual machines are better. At Kinsta, you get this trendy stuff even on the starter plan. Wow! PHP 7, Maria DB, SSD, RAM, Virtuals. Sounds great! Doesn’t it?
Brian says, “These alone give solid performance.” You mean to tell us a garbage site with heavy theme and plugins will be fast with these toys. Sorry. Paying attention to origin optimization trumps this technobabble stuff always.
An eCommerce store on a cheap shared host with 1.7-second TTFB – can still, load in a 2-second performance budget. That’s right 300 milliseconds is the tiny headroom remaining to build the page. How? Don’t load fat popular security plugins like iThemes Security or WordFence. Or plugins like Yoast SEO or Google AMP.
Cool Kinsta Page Caching
Brian’s claim: “With Page Caching your site can handle 10X more traffic. But it breaks eCommerce, forums, and any interactive site.” That’s not very reassuring. And it doesn’t help non-cacheable cache. Let see? That would be third-party scripts like Google Analytics, Google Fonts, and Google Captcha. And many more.
Bryan is convinced NGINX and FastCGI on Kinsta do the world’s best caching. He claims we’ll see TTFB improve from 230 milliseconds to 138 milliseconds. Sorry guys. But that is only 92 milliseconds. Thanks, we’d gladly take those savings. But we can save 300 milliseconds by dumping Google Fonts with a plugin for Pete’s sake. Brian then tells us, “Fast TTFB is important for page ranking.” Yeah. We sort of agree. But it only makes less than a 1-percent difference in SEO.
Kinsta SSL and speed.
Bryan gets excited about a future *someday* when HTTP/2 is standard fare for hosts. But for today, it’s sort of geeky and beyond the reach of common site owners. Yeah. Sure. You can pay extra and have the future today. But is it essential to get speed? We don’t think so. He talks about HTTP/2 and HTTP/3 performance boosts. He recommends migration away from hosts that don’t provide it. Of course, his recommendation is his employer Kinsta. No bias here. Both require SSL certification. That forces you to be *secure.* He thinks that’s great for the web. We aren’t so impressed. You can learn more here:
Reducing server requests.
Then Bryan dives into concatenation and minification as if they are necessary. But he warns: “You might break your site.” Surprise! He then recommends customizing to rid conflicts. But sadly, he neglects telling us how that’s done. He notes that minification plugins don’t help HTTP/2 because of multiplexing. So why is he talking it about it? He just recommended HTTP/2 on Kinsta. We suppose he’s showing alternatives to Kinsta. He then recommends using Autoptimize or WP-Rocket plugins as helpers.
Here’s our free article on minification and concatenation:
Optimizing images in the media library.
Now the hour-long seminar takes a turn into saving load time reducing the page weight of heavy images. He says, “Using right format. JPEG not PNG for photos.” This is a basic truth and big error for novice website builders. But he doesn’t tell how to retrofit a media library polluted with fat PNG photographs.
He recommends using ShortPixel or Imagify plugins. Those aren’t our preferences but they work. He says to serve webP-formatted images to supported browsers. We rarely see much benefit from this Google-endorsed trick. It will reduce image sizes by 10 percent. But that isn’t significant because images load in parallel. Cloudflare Pro converts to webP. WebP is not supported by Apple. A downside is webP uses more disk space with duplicates. We never use webP format.
If you’ve botched your media library uploading huge PNG photographs instead of JPEGs, it can make a big difference when it’s fixed. Otherwise, image optimization doesn’t give as big of a speed boost as it used to. Why? Browsers are smarter about handling images fast. A lazy load plugin may solve many problems for you instead.
Fonts and speed.
We’re a big advocate of using a system font stack instead of slow-loading Google Fonts or Adobe fonts. So is Bryan. So we agree on something. But Bryan doesn’t tell you how to do this magic.
Read our take on this best practice:
Disable WP Native Cron
This is a geeky thing to do. It was faddish for awhile after WordPress added the Heartbeat API. Have we ever done it? Yes. Some hosts can’t handle the extra server load. Bryan recommends pinging wp-cron.php with better frequency. High traffic sites are most affected. And of course, the reason he mentions this puny feature is it’s a default on Kinsta.
The better and cheaper solution is learning about Heartbeat plugins.
Repair Render Blocking Assets
Why do professed speed experts recommend rewriting code to eliminate the page blockage rendered by scripts? Bryan recommends it. This is so esoteric, time-consuming, and costly. Few plugins help. Always it involves custom work. But the payback is so small compared to getting rid of popular multi-function plugins like Yoast SEO or AMP or iTheme Security. We’ve written about Async or Defer flag for JS loading. But we’ve found this more often than not breaks your site. Bryan also mentions inlining critical “above the fold ” CSS styles. These are costly make-work projects invented by programmers and coders. Don’t go there! Have we ever done it? Yes. But we were building experimental pages loading in under 300 milliseconds. That is unnecessary overkill.
CDN the wonder band-aid – promising after-speed-damage repair.
Nothing makes us more rabid than speed gurus recommending CDN as a solution. This a week excuse for building a cruddy bloated website. Bryan recommends CDN of course. But at least he mentions CDN may not help. CDN can slow down page load time. Bryan warns: “Don’t just slap CDN on by default.” We agree.
If you have a database problem, CDN won’t help. We steer clear of CDN with origin optimization. That means not being sloppy.
Tuning PHP and MySQL.
Now Bryan goes out on a speculative limb. He recommends Query Monitor plugin to identify slow components. This is a complicated plugin for professionals. He then tells us if we don’t know what to do “hire a developer” for solving problems. Absurd focusing on the wrong target. These need coding solutions. Ineffectiveness.
Is Kinsta expensive hosting?
You decide. Their pricing per month is here. Have we ever used them for client speed repairs? Yes. The sites were so broken we couldn’t migrate or backup. They contained obsolete WordPress versions and stale plugins. Absolute nightmares. Updates weren’t possible without breaking the site. Kinsta moved those sites. They were then faster loading – but still, time-bombs waiting to explode. The site didn’t *get pretty* just being moved to a different expensive host like Kinsta. Postponing the inevitable implosion.
You can get under 2-second load times on shared hosting. Pocket the money you’d spend elsewhere.
Kinsta is not the only speed solution. Build a better site from the ground up. Don’t add unnecessary junk.
If MailChimp messes up delivering your free report, email us and we’ll kick their monkey butt.