15 August 2022

WordPress hostings are not all the same.

Let's see the case of this newspaper that has decided to change supplier by switching to a failed hosting.

As we wrote previously in this article citing a case study from a former customer, not all hosting is the same.

It is very rare to see customers leave, however it does happen, albeit not frequently, that ignorant customers (in the most etymological sense of the term, meaning they ignore, or do not know) are advised by people (even more ignorant) who, enjoying full trust, recommend solutions based on instinct or the good impression of a salesperson on duty, without bothering to evaluate the quality of the proposed solution and the validity of the company they will rely on.

As long as it's okay, and you make the right choice, being an idiot isn't a big deal, in fact it can be mistaken for a virtue. But when you make the wrong choice, idiocy has a cost to a lot of people that the idiot as such does not even have the knowledge of the facts.

While this might not be a problem for a local bar's showcase website, it could be detrimental and spell business failure for a newspaper operating under the now-standard business model of advertising revenue, which is directly proportional to the number of visits.

It is important to remember a very clear concept: being online today effectively means competing with other entities (in this case, online newspapers) in terms of content and its quality, as well as determining factors such as user experience, which today more than ever is becoming a ranking factor and no longer a mere vanity metrics that is an end in itself.

User experience is now evaluated by Google through Core Web Vitals data of the CRUX type and not just Labs.

In short, this means that every browser based on the Chromium engine, the engine developed by Google on which Chrome is based, will send data to Google for each page viewed which will indicate technical parameters called Core Web Vitals , including the page loading time.

It goes without saying that if a site is slow, visitors using Chrome will give Google these ratings and Google will understand that the site is slow.

At that point Google will have to decide whether to continue showing that content and that site, or whether to decide to prefer and position first, another competitor site that reports the same news but is much faster. Obviously the answer is obvious and the question rhetorical, because Google is interested in offering satisfactory user experiences and therefore the slower the site, the more likely it is (let's say certain) that the newspaper will lose traffic in an important way and therefore also visits, less banner impressions, less remuneration from advertising circuits and less monetization.

An unsustainable business model is that of online publishing below break even.

We must start from a fundamental concept in the world of online publishing, writing content has a cost, an editorial office has a cost (which is why many prefer to delegate remuneration to a single piece), and writing more articles a day is equivalent to buying more folders per day. game of bingo or tombola if you prefer.

Anyone who has to do with many online newspapers and blogs (we manage approximately a hundred of them), knows that not all articles produce the same traffic, for several factors:

  1. There are sites that deal with the topic better and are rewarded on the SERP
  2. There are sites that go viral first because they are relaunched by prominent people such as a politician (and this gives Google the check to keep it viral)
  3. There are sites that arrive before us, so for a few hours a small blog of some private blogger who writes a piece a week, will be ahead of nationally important newspapers.
  4. There are topics that are simply not of interest and therefore maybe we position ourselves first for whole days but we do 1000 visits a day.

From here it is easy to understand that an online magazine has to publish many pieces to find those two or three that are strong and allow not only to offset the costs of the other pieces that have not had enough readings to break even, but to produce a profit such as to cover the living costs of entrepreneurial activity as well as produce a more or less conspicuous profit for the publisher who remains in fact an entrepreneur.

Obviously, it is also necessary to evaluate the remuneration and the business model to be developed, each with its pros and cons, and very often a mix of the three main ones.

  1. Remuneration through Google AdSense Advertising Circuits : Normally it has a low RPM (Revenue per thousand), but it does not impact heavily with the user experience, limiting itself to loading display advertising banners and allows you to be quite calm according to the logic few but good and for a long time.
  2. Remuneration through advertising circuits alternative to Google AdSense : They tend to pay more and sometimes much more than Google Adsense, but in some cases some dealerships tend to be very intrusive, risking giving a bad user experience and seriously endangering long-term sustainability.
  3. The sale of Guest post : this is a rather profitable activity based on the authority of your site in which the writing of a piece can be sold for 50 - 100 euros and consists in fact in creating an advertorial with a follow exit link towards the client's site who pays to get a link from the site and then "push" the ranking. It goes without saying that a newspaper will never be able to live on guest posts, if not dosing them in a very parsimonious way within the editorial line. Moreover, Google does not like at all that a site starts to have many outgoing links, especially if they follow. It is not stupid and easily understands the reason and cause of outgoing links to sites that are just born and / or with a very low pagerank.
  4. Direct sale of banners without intermediaries : the classic example in which the newspaper that talks about Sardinia decides to sell advertising space to the car rental company to tourists visiting Sardinia. In this case, the banner is sold in what is a specific bargaining and which can significantly affect and bust the logic of the market. Let's assume that that banner in the Top Header position in the summer season is worth 1000 euros per month, compared to the winter season which is worth 200.

Regardless of how you want to think about it and mix the many options above, the goal does not change, to have a difference between turnover and costs that generates a profit. As long as the balance is strongly positive, positive, or slightly negative (for a short period), the publisher can push with the editorial line and its editorial staff and write many articles of which some will go negative, some will break even, others will go strong.

What happens when your site is slow and Google penalizes you or doesn't reward you?

When Google penalizes you or does not reward you, perhaps by not placing your articles in Google News, and by not making you appear on Discovery, or perhaps by making you appear on both, but less frequently and for fewer articles, it happens that the newspaper will begin to make fewer visits. . Let's say for example, one third less. That third less is not remunerated by Google (or by the alternative advertising circuit mentioned above) and therefore the publisher decides instead to publish 90 articles a day, to publish 60 to limit costs and always have a profit in relation to costs. .

It then happens in doing so, that in those 30 missing articles, perhaps the article on the candidacy of the former mayor councilor or the piece that talks about the worms found in a well-known pasta brand that would have been the trend of the moment and alone would have produced perhaps 250 thousand visits that at the “standard” cost of two euros for every 1000 impressions, would have brought in an amount of 500 euros.

If we consider that the average price of an online article is 5 euros, it means that those 500 euros would have given us the opportunity to write another 10 articles, of which maybe another 2 would have gone viral, bringing us another half a million visits, and allowing us to have earnings enough to set aside a portion of the income and reinvest the rest for writing new articles or other satellite activities such as positioning banners more effectively, hiring faster servers, SEO consultancy, PageSpeed ​​experts, and situations that if well structured lead the company to grow in traffic, value and RPM.

In short, if you have no visibility, and your site doesn't get hundreds of thousands of visits a day, you won't have the resources to maintain an editorial staff and pay the writers, to the point that, with one layoff after another, you'll be left alone to write articles for the newspaper before realizing that the game isn't worth the candle and you've stopped that "perpetual motion" of articles, visits, monetization, articles, visits, monetization, articles, visits, monetization, in a slow, continuous crescendo.

The specific case obviously censored.

For obvious reasons we cannot name and mention because there is always a professional approach even with the most itchy situations that we would really like to tell you in every single aspect, however it is sufficient to think that after two years and 3 months of WordPress hosting service offered to a newspaper journalistic, the publisher inspired by a personally run company that claims to advertise (in the customer portfolio there are no prominent names or admirable case studies) online and beyond, decides to change hosting provider.

That's fair enough. It's normal, legitimate, and correct to try to improve on what was already being done very well, considering, without too much modesty, but also without too much sensationalism, that all the technical specifications of a server-side software stack still allow us to serve clients like this one, with these numbers and this caliber, AMP traffic plus normal traffic, 85 million page views per month.

So it is easy to assume and understand that the new WordPress Hosting provider will certainly be better than ours and will certainly do better than us.

Therefore, we waited for the site to be migrated to first of all draw assessments, according to the "measure to decide" perspective, and subsequently also draw conclusions.

We therefore waited for the DNS switch to immediately notice by browsing it by normal users with the browser as any visitor would do that the site was extremely slow. A waiting time of several seconds before sending the resources and a user experience that was annoying and unnerving right from the start.

The same experience that became impossible with biblical waiting times if done by clicking on a link from Facebook.

We therefore assessed that the site was simply uploaded to a server with Plesk and that it did not support many of the technical and technological features that distinguish our performance-oriented WordPress Hosting service.

We therefore evaluated the browsing speed with Pingdom and compared it in an honest differential analysis to the data in our possession measured with Pingdom, of which we report the obviously censored screenshots below.

 

Site migrated Pingdom comparison before after

As we can see, the site that previously opened in 1,02 seconds now takes 7,25 seconds . For the sake of accuracy and transparency, although only one screenshot is provided, it should be noted that while our hosting provider opened the site on multiple tests in times ranging from 950 ms to 1,3 seconds, the new provider's minimum load time was 3,5 seconds and a maximum of 13 seconds, with an average load rate of no less than 4 seconds.

Let's just say that it's fair and fair to say, without considering the worst-case scenario, that in the best-case scenario the new supplier is FOUR TIMES SLOWER than us.

There are those who argue that a home page, or rather a web page weighing 5,5 megabytes, is an absolutely inadequate weight for a website and we can only agree with this observation, however it is good to focus on the fact that regardless of the weight which has not changed during the migration, remaining between 5.6 and 5.7 megabytes in total weight, the site previously loaded a good SEVEN TIMES faster.

We are not talking about 10% or 20% more, values ​​which in themselves justify the move to a better and more competent supplier, but we are talking about a worsening of 700%.

We spoke to the technical contact to raise the issue.

We spoke on the phone with the technical contact (also by searching through Outlook correspondence, he had already been a contact of ours since 2020) "the guy who deals with advertising" to discuss other collaboration opportunities and we ended up talking about the terrible job that had been done in terms of speed in the transition to the new provider, with a very high TTFB and a site opening time that even at 0:23 on August 15th (when the server should be low with no one connected) returns a TTFB that is nothing short of SHAMEFUL of 4,2 seconds.

A truly embarrassing value if compared with that of another client of ours “Ilcorrieredellacitta.com” which uses the exact same theme and has a TTFB of 0,169 seconds , or 24,8 times lower, or 24,8 times BETTER.

[root@mail ~]# time curl -I https://www.laCENSURATO.it HTTP/1.1 200 OK Date: Sun, 14 Aug 2022 22:22:58 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive link: ; rel=shortlink vary: Accept-Encoding x-cache-status: MISS x-powered-by: PleskLin CF-Cache-Status: DYNAMIC Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" Report-To: {"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v3?s=523ix60ANRh931Z7AmsEGyyptL%2BkA2kmPbqgbjFRK%2BbJymfkn8EPXn 9kdJESMDxx1xcNO%2Br1VXG4TBP45rPN6Ti1zMwPuP01yMnAL9a%2FcRGLwXoDFridRIT%2BO8Go0347CjaxAuqc0tpAXCc%3D"}],"group":"cf-nel","max_age":604800} NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800} Server: cloudflare CF-RAY: 73ad17865d3ec2ac-VIE alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400 real 0m4.269s user 0m0.037s sys 0m0.025s
[root @ mail ~] # time curl -I https://www.ilcorrieredellacitta.com HTTP / 1.1 200 OK Server: nginx Date: Sun, 14 Aug 2022 22:25:09 GMT Content-Type: text / html; charset = UTF-8 Connection: keep-alive Vary: Accept-Encoding Link: ; rel = "https://api.w.org/" Link: ; rel = "alternate"; type = "application / json" Link: ; rel = shortlink Last-Modified: Sun, 2 Aug 5 14:2022:22 GMT X-Cacheable: YES X-Varnish: 02 14 Age: 980407952 Via: 980393209 varnish X-Server: Managedserver.it Hosting X-Cache: HIT X -Hosting-By: managedserver.it - ​​Performance Managed Hosting real 1375m1.1s user 0m0.169s sys 0m0.040s

The fact is that when we contacted him, mentioning the problem and inviting him to check the speed values, he preferred to dismiss us by saying that he had spent 40 days planning the migration (I underline FORTY DAYS), and that he was in a hurry to go on vacation and didn't want to redo the migration again to return to the server where he was before.

When we reported imminent SEO issues that would soon arise for the reasons listed above, relating to Core Web Vitals and website speed, he invited us to address our complaints and suggestions to the publisher. The answer, of course, is rather obvious: we cannot address the publisher because they are ignorant in the etymological sense of the term, meaning they are incapable of technically dealing with terms like TTFB, Early Data, TCP BBR, and various acronyms that are complex to understand even for experienced system administrators.

This individual, who continues the phone call by calling himself a salesman and not a technician , thinks it is appropriate to contact the publisher to inform us that we have called him ignorant, taking it out of context and making it seem like a gratuitous insult, rather than a peaceful objective evaluation of his skills, in order to discredit us.

The publisher learned of what was communicated as an insult, communicates to third parties in common that our company is insulting him, and of course the service reseller calls to find out what was happening since the publisher communicated to him. that we were insulting him when in fact none of our company spoke to the publisher at all, but only with his trusted contact (the advertising handyman who also wants to understand technology).

Obviously we contact the publisher, first of all to apologize for the misunderstanding and obviously to explain the context referring to the uselessness of talking about technicalities with a non-technical as we have done above.

We found a prejudiced, unsympathetic person who effectively dismissed us in a 10-second phone call, not giving us even a minute to engage in a harmonious and peaceful conversation that would have shed light on the matter and warned him of the dire and looming consequences of such a reckless decision, namely, choosing a provider that transformed a fast website into one completely unsuitable for running an online newspaper.

Obviously, I understand the problems of the publisher, as well as the singular story that professionally speaking from 2005 to today has no equal, one wonders if the publisher or his trusted person has the competence to understand at least spannometrically what the consequences may be that should be obvious even to any non-technical person, when you start with "the site is now SEVEN times slower".

In this regard, we asked some professionals who populate Facebook groups like Fatti di SeoZoom, Web Developers Italia, and similar groups, posting the screenshot of the Pingdom test above in the before-and-after differential analysis, what the consequences of this slowness might be. Some even ventured to speculate on the possible causes, and this impartial approach serves once again to understand and demonstrate how many amateurs still operate out there without the slightest concern for the client's business , and for the editorial staff, who will soon be laid off because the newspaper will no longer generate sufficient revenue.

 

It was obviously easy to understand what the answers given by professionals were, for a professional, but it is good once again to have and show superpartes confirmations to show that we do not invent anything we approach them through lies as some Hosting companies do that do not have the decency and the moral ethics of not taking a customer if they fail to add value and improve a starting situation.

There are hosting companies out there (unfortunately) that have no respect for the customer and have no problem making entire businesses fail in order to sell one more server.

The most disconcerting thing of the whole story in this triptych of ignorant people is that no one seems to care about the fate of the newspaper, nor the publisher, a haughty character to understand that perhaps they are not doing their interest, nor the trusted character ( aka commercial advertising) that seems to have only an exclusive rush to go on vacation and not care about the damage done to which it is not remedying, nor the new hosting provider who is well disinterested in restoring or at least improving those values ​​shown above that suggest carelessness and absolute incompetence.

I am only very sorry for the editorial staff, the columnists and all those who will suffer the consequences of this bunch of improvised people who play at being entrepreneurs without any knowledge of the facts and even rejecting suggestions and warnings about what will happen if the current situation continues to persist.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.

0256569681

Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.

DISCLAIMER, Legal Notes and Copyright. RedHat, Inc. holds the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of the AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. holds the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt; Oracle Corporation holds the rights to Oracle®, MySQL®, MyRocks®, VirtualBox®, and ZFS®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; PostgreSQL® is a registered trademark of PostgreSQL Global Development Group; SQLite® is a registered trademark of Hipp, Wyrick & Company, Inc.; KeyDB® is a registered trademark of EQ Alpha Technology Ltd.; Typesense® is a registered trademark of Typesense Inc.; REDIS® is a registered trademark of Redis Labs Ltd; F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB; HAProxy® is a registered trademark of HAProxy Technologies LLC; Traefik® is a registered trademark of Traefik Labs; Envoy® is a registered trademark of CNCF; Adobe Inc. owns the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited; Automattic Inc. holds the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert owns the rights to Drupal®; Shopify® is a registered trademark of Shopify Inc.; BigCommerce® is a registered trademark of BigCommerce Pty. Ltd.; TYPO3® is a registered trademark of the TYPO3 Association; Ghost® is a registered trademark of the Ghost Foundation; Amazon Web Services, Inc. owns the rights to AWS® and Amazon SES®; Google LLC owns the rights to Google Cloud™, Chrome™, and Google Kubernetes Engine™; Alibaba Cloud® is a registered trademark of Alibaba Group Holding Limited; DigitalOcean® is a registered trademark of DigitalOcean, LLC; Linode® is a registered trademark of Linode, LLC; Vultr® is a registered trademark of The Constant Company, LLC; Akamai® is a registered trademark of Akamai Technologies, Inc.; Fastly® is a registered trademark of Fastly, Inc.; Let's Encrypt® is a registered trademark of the Internet Security Research Group; Microsoft Corporation owns the rights to Microsoft®, Azure®, Windows®, Office®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®; Apache® is a registered trademark of The Apache Software Foundation; Apache Tomcat® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group; Docker® is a registered trademark of Docker, Inc.; Kubernetes® is a registered trademark of The Linux Foundation; OpenShift® is a registered trademark of Red Hat, Inc.; Podman® is a registered trademark of Red Hat, Inc.; Proxmox® is a registered trademark of Proxmox Server Solutions GmbH; VMware® is a registered trademark of Broadcom Inc.; CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV; Grafana® is a registered trademark of Grafana Labs; Prometheus® is a registered trademark of The Linux Foundation; Zabbix® is a registered trademark of Zabbix LLC; Datadog® is a registered trademark of Datadog, Inc.; Ceph® is a registered trademark of Red Hat, Inc.; MinIO® is a registered trademark of MinIO, Inc.; Mailgun® is a registered trademark of Mailgun Technologies, Inc.; SendGrid® is a registered trademark of Twilio Inc.; Postmark® is a registered trademark of ActiveCampaign, LLC; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Hetzner® is a registered trademark of Hetzner Online GmbH; OVHcloud® is a registered trademark of OVH Groupe SAS; Contabo® is a registered trademark of Contabo GmbH; IONOS® is a registered trademark of IONOS SE; International Business Machines Corporation owns the rights to IBM® and IBM Cloud®; Terraform® is a registered trademark of HashiCorp, Inc.; Ansible® is a registered trademark of Red Hat, Inc.; cURL® is a registered trademark of Daniel Stenberg; Facebook®, Inc. owns the rights to Facebook®, Messenger® and Instagram®. This site is not affiliated with, sponsored by, or otherwise associated with any of the above-mentioned entities and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. All other trademarks mentioned are the property of their respective registrants. MANAGED SERVER® is a European registered trademark of MANAGED SERVER SRL, with registered office in Via Flavio Gioia, 6, 62012 Civitanova Marche (MC), Italy and operational headquarters in Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

JUST A MOMENT !

Have you ever wondered if your hosting sucks?

Find out now if your hosting provider is hurting you with a slow website worthy of 1990! Instant results.

Close the CTA
Back to top