How to optimize the load time of initial connection and SSL handshake phase of a web page on a 3G network?

Question

My website www.example.com(SSL enabled) is hosted on Amazon EC2 shared hosting. It loads faster (load time < 2 seconds) on a wifi/broadband connection. Issue is on 3G network in mobile**(H mode and not H+ mode)**. Initiate a connection phase and SSL handshake process takes a lot of time - 12 seconds. Monitored the timing parameters through Chrome Network tab. Below is the measured load timing for the webpage.

Kind of data handled on page: Tested web page receives 5 key-value paired JSON data through AJAX and displays it on the web page. It is a very lightweight page with only 5-6 text content.

I have seen many websites load faster on a 3G mobile network(H mode). My website is too slow during initial connection establishment phase on a 3G network. Can someone please assist me on how to resolve/optimize the delay in initial connection phase? Will moving to dedicated hosting resolve the present issue?

Web Server is not busy and there is lot of CPU AND memory available always.

Server Configuration: Amazon EC2 Instance - Shared hosting (32 CPU and 60 GB RAM). Web Server - Apache. SSL - Symantec.

Solution 1

Initial Connection

You will find that the initial connection includes negotiating the SSL, so since the handshake is high, its a good indicator that something is seriously wrong with the way you have setup the SSL.

Google Chrome: Understanding Resource Timing

Time it took to establish a connection, including TCP handshakes/retries and negotiating a SSL.

SSL Handshake and TTFB

You have two major issues, the Time spent completing a SSL handshake and the servers waiting TTFB (time to first byte).

• TTFB: 4079ms (should be less than 1000ms)
• SSL handshake 11830ms (should be less than 100ms)

It should also be noted that when testing with 3G/4G devices it can cause longer first bytes due to the fact that phone signals vary in strength... this can cause intermittent connection issues and varying latency times.

Step 1: Investigating the SSL issue

It's pretty obvious that you have a serious SSL issue and most likely due to a faulty install of OpenSSL or similar. Start by testing your SSL cert using SSL Labs and then correcting any issues or warnings it suggests.

If the SSL is still operating slowly then you most likely have a overloaded server or a server fault. If its the later then you will need to try and narrow down where the fault lies. Use the Server Fault stack should you need further assistance on this matter, one user reported that creating new keys resolved a slow SSL issue that he/she was encountering that may, or may not be relevant.

Load balancers can help if its a server resource issue.

Step 2: Investigating the TTFB

Once you have investigated resolved the issue of the SSL and you still have an increased TTFB then you should test your server by ensuring that it has enough resources.

The first byte time is influenced by but not limited to:

• Distance from user to data centre hosting the server can increase TTFB
• Uncached GZIP can increase TTFB
• Congested networks can increase TTFB
• Congested servers can increase TTFB

Sometimes increasing the CPU's and RAM isn't always the best option. Sometimes its better to introduce a load balancer because not only does it mean you can easily run multiple servers side by side but it actually offloads caching and SSL requests. Some other benefits include:

SOURCE

• Caching: The appliance can store content that does not change (such as images) and serve them directly to the client without sending traffic to the web server.
• Compression: Reduces that amount of traffic for HTTP objects by compressing files before they are sent.
• SSL Offloading: Processing SSL traffic is demanding on a web server's CPU, so a load balancer can perform this processing instead.
• High availability: Two load balancing appliances can be used in case one fails.

Tips for lowering your TTFB:

• Ensure your database is on the same network, or a quality SQL cloud.
• Ensure your database is read from memory and NEVER EVER the SWAP file!
• Make use of a content delivery network, it offloads server requests and compression tasks.
• Make use of Varnish Cache to reduce load on the database by caching pages
• Benchmark your static files on the hard disk using HDParm
• Benchmark your server using Apache HTTP server benchmarking tool
• Benchmark the website with 10 passes with multiple remote locations using WebPageTest

Solution 2

Reading the title of your question, there are two things you can do to speed up the initial connection and SSL/TLS handshake. These work for any connection, not just 3G, so you should use these as best practice anyway.

First, use HTTP/2 to serve the site. This requires Apache 2.4.17 or later.

Second, configure Apache to use OCSP stapling. This requires Apache 2.3.3 or later plus OpenSSL 0.9.8h or later, with a good guide to set it up here. OCSP stapling won't speed things way up but it will do some of the work for the client and spare them the trouble of attempting an OCSP lookup.

Reading the body text of your question, I think you have a much bigger problem with your hosting environment. Those load times are unacceptable. You mention that it is 'shared hosting', you should contact whoever is managing that shared hosting and ask why their server is so unusually slow. You are probably better off trying a different shared host, or running a VPS yourself (this is more work but gives better speed and flexibility).

Since you are already on AWS, why not try their free tier to test things out and get your own server working and optimised? Use it with a subdomain and some static HTML pages for testing and then move your primary site over (scaling up past the free tier limits if needed).

Comments

[Admin]

Have you tried using an elastic load balancer and having it handle the HTTPS? That is what I use at Amazon, and I haven't seen performance problems like this. Then again, I've never specifically tested against a 3G connection.

[Admin]

Thank you. Server is not load balanced. Will test the server on certain parameters again and will try it out.

[User234334]

Thank you for your detailed explanation. Will test the server again on the suggested parameters and will implement the best!

[Simon Hayter]

@StephenOstermiller nicely spotted. The waiting TTFB is 4000ms while the SSL is over 11000ms. It's likely the SSL is impacting the TTFB. I've updated the question to reflect that.

[User234334]

Thank you! I tested my SSL at www.ssllabs.com and rating was "A". No warnings/issues were reported. I found that Apache version is 2.2.15 which is outdated. Need to update it now. My website contents(size in TB) are in /var/www/html/. Will updating/reinstalling Apache remove my website contents? Any safest method to update without losing data?

[User234334]

One more point - OpenSSL is also of latest version.

[Goyllo]

Are you getting similar initial connection and TTFB time when you test it directly without selecting any device and network mode.

[User234334]

@Goyllo No. Load time is perfect in wifi/broadband connection on PC as well as mobile. Load time is worse only on a 3G network(H mode). In 3G(H+ mode), its perfect. Website server is located at US and i am accessing it from India.

[Simon Hayter]

Don't test it with your broadband alone... its biased and often cached. Use multiple locations using WebPageTest as I've said. Focus on the first view only information.

[Goyllo]

I highly doubt chrome network mode does not work like your local ISP 3g network work. Just test it in your local device with 3g mode, count a second manually and see weather it is fast or not. Lot's of things I did not understand how Google network mode work in reality. ISP have setup many of things on their background. Here Google chrome convert your wifi network into 3g network, so it might affect in timing. I have also tested my site, which is fast in real device but load slowly when I do throutlling in chrome dev tool

[Simon Hayter]

@Goyllo testing it on one connection and one browser is hardly a test at all. There are various ways you can remote test a site with multiple passes, multiple regions, multiple browsers and guess what... you can select 3G, 3G H and 3G H+, 4G LTE, DSL/CABLE and Fibre at WebPageSpeed. Using the inbuilt testing tool may be handy for sites that receive low traffic each day but for sites with lots of traffic from various regions you need to test multiple-regions, and not just multiple-devices.

[Simon Hayter]

Also with WebPageSpeed you can clear the SSL cache which is extremely handy.