Of course, everyone should use an HTTPS connection with publicly available Xojo WebApps to ensure an encrypted connection.

The Basics

Theoretically, an HTTPS connection is slower: If a page is delivered via HTTPS (i.e. the secure variant of HTTP), the connection between the web server and the browser takes a little longer due to the so-called SSL handshake. But we’re only talking about a few milliseconds here.

Measuring the performance cost of an encrypted connection is a bit tricky, as it depends on multiple parameters, mainly:

• Caching behaviour of clients

• Client distance to the server

• Hardware

• The ratio of dynamic vs static content

• Server software

• Typical session length

Especially the ratio between static and dynamic content is crucial. One might conclude that the influence will be lower for static content, as it can be cached better, but — as often — it depends: the processing time of dynamic content is usually quite high, so the performance loss of a secure connection is comparably less.

But for sole static content in Xojo Web Apps (for instance icons in a toolbar), it makes sense to implement a kind of caching, as such that these resources are only loaded once. Xojo’s documentation is showing you how to do this:

https://documentation.xojo.com/topics/web/web_app_optimization.html#web-app-optimization

HTTP / 2 speeding your connection up

As part of its “HTTPS everywhere” offensive, Google has always been interested in having as many pages as possible run with SSL certificates.

Incidentally, that might also be the reason why Chrome is one of the official sponsors of Let’s Encrypt. The search engine giant was also significantly involved in the development of HTTP/2.

The previous protocol, SPDY, was initially developed as an experiment by Google to sound out technical possibilities with which the almost ancient HTTP/1 could be improved. That was in 2009. In 2015, the findings from the experimental SPDY project were then transferred to the standardized HTTP/2 protocol.

HTTP/2 has now been equipped with a wealth of new functions that enable data transmission to be much faster:

• Multiplexing

• Header Compression

• Cache push

• Binary protocol

• Request prioritizations

How To Enable HTTP/2 in Xojo Web 2?

Sadly, at the time of writing this article, there is no way you can do that. The Xojo Web 2 Web Framework comes with its own implemented web server in your apps (though it is wise to install your own web server in front of your publicly available app) which can only “speak” HTTP/1.

HTTP/2 wasn’t ratified when Xojo started on the journey to re-engineer Web 2.0 from scratch. According to Xojo HTTP/2 is on the list for a future version, but for the time being, we have to live with HTTP/1.
Though, if you have to use HTTP/2 for connecting to a remote API, you can use the MBS Curl Plugin from Monkeybread Software, which lets you deal with this.

Speed Improvements in Xojo Web 2 versus Xojo Web 1

Xojo has not yet implemented HTTP/2 but they optimized the web framework significantly by reducing traffic and overhead in web framework 2. Of course, this comes at a price. Reducing the need for too many (as in Web 1) pings between the browser and the server is needed to reduce the number of events on the client side. This is one reason why certain events are missing in Xojo Web 2.0, and you can’t for instance get the xy coordinates of the user’s mouse position out-of-the-box.

A savvy developer, Tim Parnell, from Strawberry Software developed a WebKit to add more events. But he is of course warning that it should be used cautiously if used on the public web: don’t forget that if your server is located close to you things might run fine, but for a user sitting a few thousand miles away, there might be a significant lack of performance.

Measuring the performance HTTPS versus HTTP

There are many tools available. My favourite is httpvshttps.com:

Of course, this is an extreme example and you can’t compare it to Xojo 1:1, as most of Xojo’s framework is only loaded once, and you only transfer your data and a few events.
But as we have to live with HTTP/1 for the time being, we should at least “cache” static content, like pictures. in our apps, wherever we can.

Overall the performance of the new Web Framework 2 is outstanding compared to the ten years old Web Framework 1. I would say that the HTTPS overhead is at max. 10–15 per cent for an average app.

But as the security level of HTTPS is these days an absolute must-have on the internet, there isn’t much we can do about it, other than waiting for a future implementation of HTTP/2, or perhaps even HTTP/3, which is already in the making: Internet Draft for HTTP/3.