One of the simplest ways to ensure WordPress speed grandeur is to focus on the things that can clog down your web server: media files. Every page has loads of them. Images, videos and too many stupid GIFs. I know, I know – who am I to talk. But let’s face it: text is not the most satisfying content out there any more. But what to do if you already have exhausted all the common strategies of improving performance – such as using proper caching or optimising all images?

Offloading media to the rescue!

Offloading media means to save your images not only in the „/wp-content/uploads/“ folder – a.k.a. your web server – but also on a specialised service providing you with cheap storage and fast delivery – a Content Delivery Network or CDN for short.

But why – in the name of Tim Berners-Lee – would I waste any more of my hard-earned golden nuggets on hosting?

Anyone hosting websites on the cheap

Good that you ask. Because first and foremost your users will thank you for improved speed and better user experience – and Google will rank you better. If that alone does not tickle your buttons, then listen to this:

Spending money on offloading media and a proper CDN setup will actually save you some bucks as you scale up.

Lonely Austrian Nerd

Spending money to save money? No, I am not entirely crazy. Let me explain.

Let’s say you host the Website of a medium sized company aiming for signups to a service – and assume that you regularly send out newsletters which lead to spikes in visitors. These spikes turn your website sluggish – the reason why your conversions are down 25% in comparison to any normal day. That sucks, mate.

So how do we fix this?

Well, doubling server resources would most certainly take care of things. But it seems crazy to basically double server costs just to handle one spike every couple of months. Going static rocks hard when it comes to performance – but would also require a full rewrite of the Website.

I say let’s get rid of media. But not by getting rid of the images itself but rather offloading them to a CDN. For this Proof-of-Concept I ran a WordPress Multisite installation on a basic tier droplet of DigitalOcean ($5/month) using a managed database (MySQL, $15/month) – using flood.io to load test three pages with multiple images and 100 concurrent users – resulting in thousands of requests per minute.

Initial run without offloading media

I hear you say „are you barking mad? 100 concurrent users on a tiny droplet like that?„. Well – if caching is used (in this test I use the W3 Total Cache plugin), this fares relatively well:

So, what do we have here? As you can see by the lack of red, the rate of failed requests was actually 0 – so no failed requests at all. That’s good. However, what becomes painfully obvious is the influence of concurrency on response time – after the ramp up period the perfectly acceptable 250ms jump up to a „I-will-bounce-from-this-site“ 8500ms; a bloody disgrace to any professional Website. All in all, this should not come as a surprise – using a $5/month server to be bombarded with almost 2,500,000 requests a day (approx. 1,760 requests per minute) seems to go a bit overboard

Performance of WordPress with media offloading to a CDN

New the moment of truth: how does WordPress fare when offloading all media to a CDN? Well, great. But before diving into the data let me explain what exactly I offloaded – so that you can judge the possible impact offloading media to a CDN can have for your WordPress installation.

First of all, I used DigitalOcean’s „Spaces Object Storage“ with a custom subdomain to offload media from my server. The process of uploading all media automatically to this object storage is done – quite unusually – not by plugin, but by using a combination of Lsyncd and s3cmd. But let’s not get distracted by the more exciting parts of this PoC and get back to the boring data – a post will follow on how to build a similar setup.

Same testing period, same ramp-up period – and most important of all, same amount of concurrent users. As you can see in the comparison above, the results are quite striking. Not only was the test able to run at a substantially higher transaction rate of 2,250 requests per minute – an increase of well over 25% – but also the response times decreased mindbogglingly: from a catastrophic 4.7 seconds to an average of 166ms. I cannot stress this improvement enough: while serving approximately 3,240,000 requests a day the response time decreased to an average of 3,5% of the initial reaction time – all at the negligible cost increase of $5/month.

How far can we push this?

So, now we have seen a direct comparison of WordPress running on a small server without and with CDN. We saw that offloading media to a CDN yields substantial benefits to anyone trying to squeeze out every inch of performance from good ol‘ WordPress.

Well – to be perfectly honest, this has nothing to do with WordPress itself. The reason why this works so well is simple: by offloading media to a managed service hosted somewhere else, there is no need for our server to flex its muscles. As the images are not loaded from the same host as WordPress, the web server (Apache in this case) does not have to work as hard due to fewer requests made (about half actually – but this greatly depends on your site/workload). Consequentially, with less requests the CPU does not need to work as hard, the memory does not fill up as quickly and the drives hum along softly as there are very few files to serve.

This is all great. But when are we finally going to break things?
Patience, young coder.

Alright – how far can we push this? Let’s give this another run – and triple the number of concurrent users to 300.

While it still amazes me that this setup can handle over 6.2 million requests per day without returning a single error, one thing becomes clear: with an average response time of almost 10 seconds we won’t be winning any medals from our customers. Nevertheless, this PoC strengthens my view that scaling WordPress is not only a matter of pushing more money to a better hosting provider but substantially depends on your ability to optimise.

Summa summarum

In this post we used Object Storage to offload our WordPress media. This enabled us to more than double the amount of concurrent users our server can handle – and still leaves some room for further optimisation, such as offloading CSS and JavaScript files, offloading minified files generated by T3 Total Cache, switching from Apache to nginx, …

Your Website experiences spikes and you want to save a buck while still being able to handle more users? Go ahead and use a CDN – your visitors will thank you with higher sign-up rates.

How do you optimise your WordPress installations?

The post Performance gains from offloading WordPress Media to S3 / DigitalOcean Spaces appeared first on jiaa.io Blog.

However, as peace of mind prevails, I tend to upgrade once the main upgrading related issues have been sorted out – or at least have been discussed in the community forums. For me the sweet spot to jump on a new release is around 2-3 months after its roll out. If you have to support something mission critical, this might take a bit longer.

Be that as it may, let’s get Ubuntu 16.04 upgraded to Ubuntu 18.04 on DigitalOcean ?.

Step 1: Snapshots, Snapshots, Snapshots

It seems redundant to write this – but it’s unfortunately still common practice to just wing it when upgrading a system. But it should go without saying that losing all of your data is a bit more than potentially problematic. As I run all of my infrastructure on virtual servers (Droplets) provided by DigitalOcean, it’s very easy to not only back-up all of my data, but to make a functional snapshot of the full machine.

If you want to take a snapshot of your droplet, you simply go to the droplet in question, select „Snapshots“ in the sidebar menu and click the „Take live snapshot“ button – and wait for it to finish.

It’s good practice to shutdown the droplet before doing so as well as ensuring that the snapshot actually works, so you don’t have any surprises if something does go wrong…

Step 2: Installing updates

Let’s start with the fun part: installing stuff. Hop onto your machine with the nice SSH access of yours.

$ ssh user@1.2.3.4

I hope for you, that you have a nice SSH key already installed so you don’t waste precious time thinking about your password.

Update already:

$ sudo apt update
$ sudo apt upgrade
$ sudo apt full-upgrade

I know, I know – the last one might be redundant. Sue me ?

Step 3: Upgrading to that hot new version

And here we are, finally ready to upgrade to Ubuntu 18.04.

$ sudo do-release-upgrade

You will be asked some questions before the upgrading process starts. Just hop along with ‚y‘ and everything will be fine (hopefully^^). A healthy dose of reading the output and thinking about what it means will do the trick. Just be aware that this might take a while. You’ll also be prompted with a SSH config step – as I have modified my sshd_config I will stick to my current one.

After some time your happy little machine should be telling you that the upgrade is complete – otherwise you will have encountered some error. As this requires a restart, continue with ‚y‘.

After accepting this, you will be disconnected. Give your machine a couple of seconds to reboot and reconnect.

And there we go – 18.04 LTS (XenialXerus) runs smoothly, including all services that were hosted on the machine before upgrading. For peace of heart, it’s not unreasonable to check ones firewall, so that just the needed ports are open to the public.

And that’s that ????

The post Upgrading Ubuntu 16.04 LTS to Ubuntu 18.04 LTS on DigitalOcean appeared first on jiaa.io Blog.

This transformation has most certainly brought a lot of benefits to humanity. Unrestricted access to information, reasonably priced global communications and faster shopping than anybody needs. However, this has come at a cost. Companies focusing on commercialising the web for their own profit quickly gained substantial power. These global players have grown so fast and so big, that we are struggling to grasp the full magnitude of the problems they pose.

On the 6th of December 2018 Tim Berners-Lee published an outstanding opinion in The New York Times. In this piece he not only reflects on what has gone wrong in the last couple of years but also outlines a way forward.

To preserve a web that serves all of humanity, not just the privileged and the powerful, we will have to fight for it.

Tim Berners-Lee

In this opinion he asks everyone to sign a set of core principles he developed with the World Wide Web Foundation, drafting responsibilities of all actors on the web. This should be a guide for a formal Contract for the Web, holding each and everyone accountable. 

So what do I think?

Even though I am not sure at all whether this voluntary contract based on self-regulation is deemed to fail or can actually improve the status quo, at least it is a start. Together with his „Solid“ project for a new re-decentralised web and other initiatives actively promoting privacy by design and privacy by default, I can see light at the end of the tunnel. But a lot needs to be done.

Image by Taduuda

The post A Web for the Many, not the Few appeared first on jiaa.io Blog.

Vor ein paar Wochen war ich bei meinen Schwiegereltern auf Besuch und das Unumgängliche ist passiert: das Internet funktionierte nicht. Ob ich mir das als „ITler“ anschauen könne? Sicher

Nerdom to the rescue! Ab ins WLAN und rein in den Terminal. Doch was als einfaches Problem begonnen hat (Netzwerkkarte des PCs hat gejammert), wurde nach einer kurzen Konsultierung des Routers zu einer klaffenden Sicherheitslücke.

Kontext: vor nicht allzu langer Zeit wurde ein “neues Internet” aka Vertrag abgeschlossen. A1 lieferte dabei ihren Flagschiff-Router aus: die A1 Hybrid Box aka Huawei HA35-22/AM. Auch wenn ich persönlich kein Fan von diesen mitgelieferten Kisten bin, weil oft technologisch veraltet, sollte der Router für “normale” Haushalte ausreichen. Was mich eher schockiert hat, war die Absicherung dieses Produkts – nämlich keine.

You read that right: A1-Router kommen per default ohne Passwort. Jede/r im Netzwerk kann also tun und lassen was ihm/ihr gefällt. Nice!

Als First-Class-Jammerer und mitteilungswütiger Mitbürger musste ich natürlich gleich meinen Unmut kundtun:

Liebes @A1Telekom. Das Ausliefern von Routern OHNE Passwort ist ein Verbrechen an der Sicherheit eurer Kunden! #network #security

— Michael Goldbeck (@m_goldbeck) June 17, 2017

So weit, so groovy. Was mich dann aber wirklich von den Socken gehauen hat, war die darauf folgende Konversation mit dem A1-Account. Und ich meine dabei nicht die offensichtlich mangelnde technische Expertise des Antwortenden – nicht jeder muss sich zwangsläufig mit dem Thema auseinandersetzen, immerhin werden die meisten Anfragen zu Paketen und Abrechnungen sein; so zumindest meine Annahme. Was mich zutiefst schockiert hat, war die entgegengebrachte Ignoranz und Gleichgültigkeit der Antworten.

Eigentlich sollte jeder Internetnutzer sich Gedanken über die Sicherheit seines Internetzgangs machen. ^LG Frederic

— A1 (@A1Telekom) June 17, 2017

I mean, wtaf? Der User ist selbst schuld, wenn er/sie ein vom Unternehmen als Plug-and-Play beworbenes Produkt nicht selbst absichert? Sonst geht’s aber schon noch, oder? In Zeiten des Internet-of-Bad-Things sollten vor allem ISPs ihrer Verantwortung gerecht werden und gängige Standards einhalten. Und wenn schon nicht dynamisch beim ersten Start des Routers ein Passwort generiert wird, dann sollte zumindest mit der Auslieferung des Geräts eines gesetzt sein. Vor allem wenn man sich auf der Website mit “Smart Home” Absicherung bewirbt (dabei aber eher Kameras als Netzwerksicherheit meint). 

Aber ja, so ist das bei vielen Anbietern leider der Fall.

Es wird aber noch besser. Gestern war ich wieder zu besuch. Natürlich wundervoll mit dem WLAN verbunden und ready to roll. Aufgabe: kurz meinen Telefonvertrag checken. Rein in den Browser, auf zu a1.net und einloggen. Hang on – warum bin ich schon eingeloggt? Hang on – mit welchem Account bin ich automatisch eingeloggt worden?

Natürlich mit dem Account meiner Schwiegereltern.

Naaa, das kann nicht stimmen. Telefon raus, ins WLAN verbunden, a1.net und BOOM! Wieder mit dem Account der Schwiegereltern verbunden. You’ve got to be kidding me.

Aber das kann doch nicht der volle Zugriff sein, oder? As it turns out, it is. Ich habe Einsicht auf Rechnungen, Zahlungsdaten, das volle Programm.

Zu deren „Verteidigung„: diese Einstellung kann zumindest abgestellt werden. Trotzdem ist mir schleierhaft, warum der Auto-Login standardmäßig aktiviert ist. Auch ein Logout hilft nicht; bei allen im Netzwerk befindlichen Geräten ist man automatisch eingeloggt – ergo müsste man alle Geräte einzeln ausloggen. Tausende Haushalte, die die Standardeinstellungen niemals zu Gesicht bekommen, sind durch diese Praktiken angreifbar und zutiefst unsicher.

Vor allem wenn der einzige Schutz ein Router ohne Passwort ist.

Liebes A1 und alle anderen Anbieter da draußen: die Sicherheit eurer Produkte ist kein Add-on, dass ihr nur auf der eigenen Website bewerben müsst. Gängige Standards sollten eingehalten und dem Endverbraucher die Absicherung der gekauften Produkte erleichtert werden. Und nicht nur das: Security sollte per default auch aktiviert sein. Kein Versteckspiel in User-Einstellungen oder Untermenüs. 

Image by Piotr Lohunko

The post Insecurity by Default: A1 Edition appeared first on jiaa.io Blog.

Dann hat die Post auch noch ein ziemlich ambitioniertes Projekt vorgestellt: shöpping.at. Ein österreichischer online Shop, der österreichischen Unternehmen aus den Klauen von Amazon, Zalando und Ebay helfen soll. So weit, so optimistisch.

Für ihr ambitioniertes Projekt hat die Post laut Medienberichten rund 30 Mio. Euro budgetiert. – derstandard.at/2000051569868/Post-startet-Amazon-Mitbewerber-shoeppingat-im-April

30 Millionen Euro.

Keine Sorge, ich musste den Satz auch ein zweites Mal lesen. Das ist viel Geld – da sollte technisch auch was ordentliches rausschauen, so zumindest meine Annahme.

Was macht ein Web-Entwickler, wenn er ein neues Produkt sieht? Genau, er sucht sich mal quer durch den Quelltext Was sich dort Interessantes finden lässt, will ich euch nicht enthalten!

https:// – gelebte Unsicherheit

Eine Entscheidung, die mich in den ersten 2 Sekunden nach Aufruf der Seite verwundert hat, war die Wahl https nicht zu erzwingen. Es sind beide Versionen möglich – https://www.shoepping.at und http://www.shoepping.at. Warum das ein Problem ist?

Weil News-Seiten nur die http-Version verlinkt haben, hat Google auch nur diese indexiert. Da Nutzer leider überdurchschnittlich oft Domains via Google suchen anstatt diese in die Adresszeile zu tippen, kommen sie automatisch auf die http-Version.

Was dabei noch spannender ist: in der http-Version wird eine Weiterleitung auf www erzwungen, d.h., jeder User, der via http auf die Seite zugreift, wird automatisch auf http://www.shoepping.at weitergeleitet. Logic dictates, dass, wenn ich in der http-Version auf www weitergeleitet werde, auch in der https-Version gleiches Verhalten feststellen kann. Nope.

„Your connection is not private„. Chrome & Co. machen also einen auf Gandalf. Aber warum? Developer Tools to the rescue!

Tja. Wenn ein Zertifikat einer anderen Domain (die nebenbei angemerkt auf post.at weiterleitet) angewandt werden soll, wundert mich die Gandalf’sche Reaktion des Browsers herzlichst wenig.

Und was passiert, wenn man trotz aller Warnungen auf https://shoepping.at weiter will? Genau, eine Weiterleitung auf die unsichere http-Version. Fehlerhafte vhost / .htaccess Konfigurationen stehen bei 30 Millionen Euro Projekten also auch noch auf der Tagesordnung. Das kann ja nur gut gehen.

Zugegebenermaßen, auf einer simplen statischen Landing-Page sind die Auswirkungen nicht so groß wie beim Webshop selbst. Trotzdem ist das Bad-Practice. Ganz davon abgesehen, dass verschiedenste Formulare auf der Seite eingebunden sind – und Eingaben somit innerhalb eines Netzwerks (z.B. Public Wlan) wunderbar einfach abgefangen werden können. Da helfen auch die vielen verschiedenen externen Dienste nicht, die auf der Seite eingebunden sind.

// EDIT: nach knapp einer Woche wurde der Redirecting-Fehler behoben.  https wird aber noch immer nicht komplett durchgesetzt.

Was der Quelltext noch alles verrät

Ok, das Schlimmste sei überstanden. Was kann den am Mark-up der Seite großartig schief gehen?

Die ersten Zeilen sind wenig interessant. Doctype und Co., ein wenig Meta-Daten. Umlaute zu kodieren wenn UTF-8 genutzt wird, finde ich ein wenig übertrieben, aber kein Ding. Spannend wird es erst ab dem CSS-Teil. Die Bilder werden über einen CDN-Dienst namens cloudfront  abgewickelt – ein Dienst, der zu Amazon Web Services gehört – dem größten Cloud Computing Anbieter der Welt. Das wäre an und für sich nicht nennenswert – werden CDNs dazu genutzt, um Dateien (Bilder & Co.) schneller an Kunden auszuliefern, wenn diese weitflächig verteilt sind. Glaubt man aber einem User im derStandard-Forum, ist shoepping.at IP locked auf Österreich.

Ich muss ehrlich zugeben, dass ich noch nie getestet habe wieviel Unterschied gemessen werden kann, wenn ein User in Wien und ein anderer aus Vorarlberg auf etwas zugreifen will. Schätze den Unterschied aber eher gering ein. Be it as it may – nicht wesentlich.

Was aber mit jeder Zeile im Quellcode offensichtlich wird, ist, dass sehr viele verschiedene externe Dienste genutzt werden, um diese simple Landing-Page zu generieren:

• Cloudfront – CDN zur Auslieferung von Files =>Amazon
• Unbounce – Dienst zur Erstellung von Landing-Pages (genutzt um die Seite zu bauen)
• jQuery von googleapis.com – CDN zur Bereitstellung von jQuery Library => Google (wird – warum auch immer- 2 mal eingebunden)
• Google Webfonts – CDN zur Bereitstellung von Web-Schriftarten => Google
• 123contactform – Anbieter zur Bereitstellung von Online-Formularen
• conversionfox – Tool zur Lead-Generierung
• hotjar – Tool zur Echtzeit Analyse vom User-Verhalten
• Google Tag Manager – Tool zur Analyse vom Klickverhalten der User => Google
• Google Forms – Tool zur Erstellung und Speicherung von Online-Formularen => Google

Ja, jedes dieser Tools ist mächtig. Es steht auch außer Debatte, dass viele dieser Tools das Leben eines Entwicklers leichter machen – ich nutze auf diesem Blog auch Google Analytics; aber nur bis der „How-to Setup PIWIK“ Beitrag fertig ist ;). Es muss aber trotzdem angemerkt werden, dass viele dieser Dienste aus Sicht der Privatsphäre alles andere als unproblematisch sind. Mit hotjar können die Mitarbeiter der Post  zusehen, wie Nutzer auf shoepping.at die Seite bedienen. Kino-Feeling, wie der Werbe-Clip verspricht. Wenn sich Händler eintragen wollen, werden sie gezwungen ihre Daten auch gleichermaßen an Google weiterzuleiten – immerhin landen dort alle Daten des Online-Formulars. Wo die Klick-Analysen durch den Google Tag Manager landen, will ich garnicht wissen.

Ganz spannend dabei: Der User wird über die Verwendung von Cookies sowie die bereits aufgezählten Dienste NICHT informiert. Gesetze und so, liebe Post.

Ok, jetzt wissen wir also, dass die Nutzerdaten von shoepping.at auf verschiedensten Diensten landen – keiner davon aus Österreich, die meisten davon nicht mal aus Europa. 

Blenden wir alles vorherige aus. Friede, Freude, Eierkuchen – oder so ähnlich. Besucht man die Seite, fällt eines auf: sie hat viel Whitespace.

Das ist an und für sich auch kein Problem – immerhin kann ich einfach bis zum nächsten Bereich scrollen. Aber was ist, wenn ich aufgrund einer Beeinträchtigung die einzelnen Bereiche nicht sehe, sondern auf einen Screenreader angewiesen bin?

Liebe Post, diese Seite ist durch Screenreader nahezu unbedienbar! Will man sich durch die Seite navigieren, springt man als erste Station auf  den Link „Pressekontakt“. Ja. Pressekontakt. Bei nahezu allen Bildern fehlt der alt-Text. Daher erfährt niemand, um was es eigentlich geht. Der User springt aufwärts – also entgegen der eigentlichen Nutzungsrichtung. Dies alles widerspricht nicht nur unseren  Gesellschaft Grundfesten, den gängigen Gesetzen sondern auch der Business-Logik eines jeden Online-Dienstes.

Zu beheben wäre dieses Problem ziemlich einfach: valides HTML.

Mit 73 Fehlern und 19 Warnungen hat sich irgendwer nicht Mühe gegeben (auch wenn die Seite noch so sehr von einem Generator erstellt wurde). Dabei würde valides HTML nicht „nur“ bei Accessibility helfen: die Suchmaschinen-Optimierung steigt wesentlich und der Code ist in Zukunft einfacher wart- und erweiterbar. Quasi drei Fliegen mit einer Klappe.

So sehr ich das Konzept als spannend empfinde, muss ich leider sagen, dass die Seite typisch österreichisch umgesetzt wurde. Von einem 30 Millionen Euro Budget sollte sich auch eine ordentliche Landing-Page finanzieren lassen.

Unabhängig davon habe ich nach über 24 Stunden noch keinen Zugang bekommen – würde man damit Nutzer aktiv ansprechen wollen (unabhängig ob eine Beta Version oder nicht), ist das nicht akzeptabel.

Schade.

The post shöpping.at: e-Commerce auf Österreichisch appeared first on jiaa.io Blog.