Is there a speed benefit from costlier SSD hosting versus cheap magnetic servers?

Shared hosting is Web hosting in which the service provider serves pages for multiple Web sites, each having its own Internet domain name, from a single Web server. … Although shared hosting is a less expensive way for businesses to create a Web presence, it is usually not sufficient for Web sites with high traffic.

SOURCE: What is shared hosting? – Definition from WhatIs.com

Magnetic servers are old mechanical technology using spinning hard drives. Modern Solid State Drives (SSD) have no moving parts. An SSD is a type of mass storage device similar to a hard disk drive (HDD). Hosts claim SSDs are faster because they have faster access times. From our testing, that is theoretical improvement. We’ve never seen any real-world benefit. So paying more for SSD has no apparent advantage over cheaper magnetic technology.

The advantages for the host company are many including reducing cooling expenses and space and technical service time. They benefit. But should you pay more for SSD hosting?

We don’t usually recommend or prefer any hosting service. Because they fluctuate depending upon how well or bad their business is doing. It’s cyclical.

We use the two hosts with the most disrespected and low credibility for quality. Those are BlueHost and GoDaddy. They are the most hated hosts. They’re not a problem for us because of the way we build speed sites.

If you use original optimization as taught on PagePipe, about any host can get good-enough speed.

For clients who have money to burn, we recommend Pressidium hosting. But you can achieve the same speed results applying your brain and creativity – and cheap, shared hosting.

Remember, all hosts fluctuate from good to bad speed at some time. Our advice is don’t throw money at the problem. Build your site using origin optimization instead.

Why Google AMP is not the ultimate solution for mobile WordPress speed.

Google’s ambitious AMP project (October 2015) speeds up the entire mobile web. Right!? It’s a WordPress speed miracle – wait! No it’s not. It’s another Google sham. It promises better SEO results in exchange for people surrendering control and information. Google’s great boon for mobile publishing fizzled.

Three examples of Google AMP hijacking URLs and valuable screen space:


 


 

Three examples of Google AMP hijacking URLs and valuable screen space.

Google, to speed up AMP, stores publisher’s pages and serves from Google. When a reader clicks an AMP link, the address bar displays www.google.com instead of the publisher’s Web address. Oops? Where’d that site branding go?

Google says articles served from its Internet network is four times faster. That’s right. But developers disagree. Engineering or “designing in” origin optimization gives the same or even better results. That’s right. It appears Google has a hidden agenda not-so related to speed. That’s their mask.

What do these wonderful plugins claim?

AMP Active installs: 300,000+
Downloads: 1,962,560
Retention: 15 percent (moderate)
zip file size: 2.3M

AMP for WP – Accelerated Mobile PagesRetention: 4 percent (dismal)
zip file size: 1.6M

The Big Promise: AMP makes your website faster for mobile visitors. SEO pros claim Google prioritizes AMPs in search results. Feb. 24, 2016: Google integrated AMP listings into mobile search results. Big deal.

Really? But when we search on the phrase:

“Why Google AMP sucks”

we’re inundated with blog posts by developers. They say unexpected derogatory words about how AMP doesn’t help. They say it’s all a ploy by Google. These aren’t crackpots chiming in here. There are tech heavyweights who think AMP is bad for the free web. Why?

How to Setup Google AMP on WordPress Site (Using AMP Plugin) When you read the above post the propaganda sounds wonderful. Google AMP is the magic silver bullet curing all mobile speed problems. And there are two WordPress plugins helpers to get you set up. One authored and endorsed by Automattic, the  founders and owners of WordPress. What an amazing endorsement! (Question: What is Automattic doing in bed with Google?)

AMP hijacks the real URL of the page and provides no UI control to get back to the canonical URL. Consumers, publishers, sites and users are asking Google to give an opt out feature. AMP often loads broken links, takes longer to view, or may not format properly

When a user searches for an article on Google and clicks on an AMP link, it never leaves Google.com. Even if the AMP link is an external entity. Google rehosts pages from popular search destinations. But they truncate it and reformat it. It’s supposed to be helpful because it lets complex pages load faster, but it’s a pain because it frequently doesn’t format properly or they cut it off in an inconvenient place. You’ve got to waste time getting to the original page.

There’s no way to turn AMP off. If they’ve got an AMP mirror for a domain, they’ll give you those results instead of the actual page every time.

Smaller publishers have more to lose if they use AMP. For many, they think Google owns the small-guys story.

John Gruber at Daring Fireball says the following:

The Problem With AMP

The lock-in aspect makes no sense to me. Why would I want to cede control over my pages to Google? AMP pages do load fast, but if publishers want their web pages to load fast, they can just engineer them to load fast. Best answers I got were that it wasn’t really strategic — publishers are going with AMP just because their SEO people are telling them to, because Google features AMP pages in search results. I suppose that is a strategy, but ceding control over your content to Google isn’t a good one in the long term.

Wikipedia negative quotes about AMP (there aren’t any positive ones):

Some tech media outlets, including The Register have criticized AMP:

I feel this needs to be said very clearly: Google’s AMP is bad – bad in a potentially web-destroying way. Google AMP is bad news for how the web is built, it’s bad news for publishers of credible online content, and it’s bad news for consumers of that content. Google AMP is only good for one party: Google. Google, and possibly, purveyors of fake news… Pinboard founder Maciej Cegłowski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it’s faster than Google’s version… Anybody can cram an illegitimate idea into a web page and – so long as it’s encoded as AMP content – it’ll look like it’s from a legit new organization endorsed by Google.

Chris Coyier, cofounder of CodePen, writes that AMP would be better if it “was never used as search ranking factor (or anything that could be interpreted as such) by anybody.”

At AMP Conference, Gina Trapani described some aspects of AMP as being “scary to me.”

John Gruber (again) writes:

I’m on the record as being strongly opposed to AMP simply on the grounds of publication independence. I’d stand by that even if the implementation were great. But the implementation is not great — it’s terrible. Yes, AMP pages load fast, but you don’t need AMP for fast-loading web pages. […] It’s a deliberate effort by Google to break the open web.

Why is PagePipe against Google AMP?

[perfectpullquote align=”right” cite=”” link=”” color=”” class=”” size=””]Here’s a good offsite article about how Google AMP failed for Kinsta by actually impacting their SEO by a negative 59 percent drop in leads. Read it in a new tab.[/perfectpullquote]
Speed is a strategy not a band-aid. You build site and page quality in – not sprinkle it on afterwards. AMP serves Google’s purposes – not ordinary users. We’re surprised an AMP content blocker hasn’t shown up by now. Improving the web is a better answer than donating it to Google. AMP is for apathetic site creators. We can fix the problem without handing everything over to Google.


LONG but GOOD EXCERPT from:
PixelEnvy Written by Nick Heer.
“Given the assumption that any additional bandwidth offered to web developers will immediately be consumed, there seems to be just one possible solution, which is to reduce the amount of bytes that are transmitted. For some bizarre reason, this hasn’t happened on the main web, because it somehow makes more sense to create an exact copy of every page on their site that is expressly designed for speed. Welcome back, WAP — except, for some reason, this mobile-centric copy is entirely dependent on yet more bytes. This is the dumbfoundingly dumb premise of AMP.

Launched in February 2016, AMP is a collection of standard HTML elements and AMP-specific elements on a special ostensibly-lightweight page that needs an 80 kilobyte JavaScript file to load correctly. Let me explain: HTML5 allows custom elements like AMP’s <amp-img>, but will render them as <span> elements without any additional direction — provided, in AMP’s case, by its mandatory JavaScript file. This large script is also required by the AMP spec to be hotlinked from cdn.amp-project.org, which is a Google-owned domain. That makes an AMP website dependent on Google to display its basic markup, which is super weird for a platform as open as the web.

That belies the reason AMP has taken off. It isn’t necessarily because AMP pages are better for users, though that’s absolutely a consideration, but because Google wants it to be popular. When you search Google for anything remotely related to current events, you’ll see only AMP pages in the news carousel that sits above typical search results. You’ll also see AMP links crowding the first results page, too. Google has openly admitted that they promote AMP pages in their results and that the carousel is restricted to only AMP links on their mobile results page. They insist that this is because AMP pages are faster and, therefore, better for users, but that’s not a complete explanation for three reasons: AMP pages aren’t inherently faster than non-AMP pages, high-performing non-AMP pages are not mixed with AMP versions, and Google has a conflict of interest in promoting the format.

It seems ridiculous to argue that AMP pages aren’t actually faster than their plain HTML counterparts because it’s so easy to see these pages are actually very fast. And there’s a good reason for that. It isn’t that there’s some sort of special sauce that is being done with the AMP format, or some brilliant piece of programmatic rearchitecting. No, it’s just because AMP restricts the kinds of elements that can be used on a page and severely limits the scripts that can be used. That means that webpages can’t be littered with arbitrary and numerous tracking and advertiser scripts, and that, of course, leads to a dramatically faster page. A series of experiments by Tim Kadlec showed the effect of these limitations:

AMP’s biggest advantage isn’t the library — you can beat that on your own. It isn’t the AMP cache — you can get many of those optimizations through a good build script, and all of them through a decent CDN provider. That’s not to say there aren’t some really smart things happening in the AMP JS library or the cache — there are. It’s just not what makes the biggest difference from a performance perspective.

AMP’s biggest advantage is the restrictions it draws on how much stuff you can cram into a single page.

AMP’s restrictions mean less stuff. It’s a concession publishers are willing to make in exchange for the enhanced distribution Google provides, but that they hesitate to make for their canonical versions.

So: if you have a reasonably fast host and don’t litter your page with scripts, you, too, can have AMP-like results without creating a copy of your site dependent on Google and their slow crawl to gain control over the infrastructure of the web. But you can’t get into Google’s special promoted slots for AMP websites for reasons that are almost certainly driven by self-interest.”

REFERENCE


Below are 8 other offsite links worth checking out:

https://tech.slashdot.org/story/17/01/18/1455259/the-problem-with-google-amp


https://www.reddit.com/r/bigseo/comments/6751ne/google_amp_sucks/


https://daringfireball.net/linked/2017/05/20/gilbertson-amp


https://productforums.google.com/forum/#!topic/news/ixPneB4vpGk


Google AMP Is Not a Good Thing
https://news.ycombinator.com/item?id=13465467


https://www.theregister.co.uk/2017/05/19/open_source_insider_google_amp_bad_bad_bad/


http://www.osnews.com/story/29823/_Kill_Google_AMP_before_it_kills_the_web_


link: I decided to disable AMP on my site >


Remove WordPress child themes for mobile speed.

WordPress released core version 4.7 in early December 2016. The default Twenty Seventeen theme included a new Customizer CSS editor. The new editor allows the removal of child themes and related plugins. This helps your site load a little faster – every little bit counts.

Before then, using child themes added custom code to WordPress themes. You edited CSS in a child theme with the WordPress file editor. It protected custom code from being overwritten by theme updates. Without a child theme, updating caused loss of code changes.

Since WordPress 4.7, the option to add custom CSS is in the WordPress Customizer. You can then remove child themes. But you can’t edit PHP or JavaScript files – only CSS.

The custom CSS editor is in Appearance > Customize. Then select the “Additional CSS” option from the Customizer menu. That opens up a live CSS editor — no refreshing. Preview your changes immediately as you type. The live preview feature speeds up web work. There’s no waiting for page refreshes to view each change.

The “Additional CSS” menu keeps the edits safe in the confines of the Customizer. Your changes aren’t seen by users until you press Save and Publish. You can only edit CSS (not PHP or JS).

Child themes allow JS and PHP modification. So this doesn’t mean the extinction of child themes. But for most, it’s an opportunity to squeek out a little more speed. We do extreme performance optimization. We favor using the Customizer over a child theme.

“Additional CSS” is inlined before the closing head tag. This means no extra HTTP requests to fetch the custom CSS. Inlining CSS into HTML header removes CSS render-blocking. It also eliminates an extra HTTP request — both great things for speed. “Additional CSS” also does code syntax highlighting and error checking. Nice.

A child theme requires an extra HTTP request – unless combining by concatenation. Read more about minification plugins.

“Additional CSS” isn’t cached. It’s downloaded, processed, and rendered by the browser with every page load. This sounds inefficient. But for small amounts of CSS, it’s negligible speed difference. A few dozen – or even a hundred lines – of CSS loads fast inlined. Even Google recommends inlining CSS. No need calling an external style sheet when CSS code is small.

“If the external CSS resources are small, you can insert those directly into the HTML document, which is called inlining. Inlining small CSS in this way allows the browser to proceed with rendering the page.” – Google

From our past experiments with hand-coded sites, we agree with Google. This technique produces the fastest loading pages. Eliminating a child theme – by inlining custom CSS – produces a small boost in mobile site performance.

So, theme updates won’t wash away custom CSS – but that’s true only up to a point. If you change your theme (rather than just updating the theme), all the code added in the “Additional CSS” area disappears. Then it’ll all be gone.

Tom Usborne, the developer at GeneratePress, has a free plugin called “Simple CSS.” It’s a nice CSS editor – complete with code syntax highlighting to help you. It keeps all additional CSS safe from any theme updates and replacements. It works with all themes but Simple CSS is included as a standard feature with GeneratePress premium theme. With this plugin, you can also apply CSS only to one specific page. Navigate to your page or post in the Dashboard and look for the “Simple CSS” metabox.

NOTE: Don’t confuse this GeneratePress’ plugin offering with Simple Custom CSS plugin: 300,000+ active installs, 204k zip file, all-time downloads: 1,336,559, retention rate: 22 percent (average).

★★★★★
Simple CSS
Active installs: 70,000+
Zip file size: 136k

And it also opens up a new area in the Customizer where you can view your CSS changes live. This code saved by the plugin doesn’t disappear if the theme is changed.

Site owners can stop using child themes. Opportunities for CSS customization is in WordPress core.


Need to preserve your WordPress functions.php file changes besides the style.css file, here’s our tip use:

Code Snippets
Add code snippets to your site. No need to edit your theme’s functions.php file again!