Painful browsing the forum, like wading through treacle

[#1]

On iPhone over 4G (native EE)

Traceroute to community.plus.net (46.19.168.229), 64 hops max.
1 *
2 *
3 *
4 *
5 aptgm87544.lithium.com (46.19.168.229) time=1399 ms
6 aptgm87544.lithium.com (46.19.168.229) time=39 ms
7 aptgm87544.lithium.com (46.19.168.229) time=37 ms
8 aptgm87544.lithium.com (46.19.168.229) time=57 ms
9 *
10 *
11 *
12 aptgm87544.lithium.com (46.19.168.229) time=347 ms
13 aptgm87544.lithium.com (46.19.168.229) time=1124 ms
14 aptgm87544.lithium.com (46.19.168.229) time=745 ms
15 aptgm87544.lithium.com (46.19.168.229) time=405 ms
*** Traceroute at destination ***

Interesting that this trace shows multiple hops around the samecserver!!

[#2]

OMG Lithium aren't even on IPv6 !!!

$ mtr -r -w -c 100 community.plus.net

Start: Wed Feb  6 13:46:27 2019

HOST: My_Home_PC                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- My_Home_Router                          0.0%   100    0.1   0.1   0.1   0.2   0.0
  2.|-- gi12-0-1-451.ptn-ag04.plus.net          0.0%   100    7.6   7.9   7.1  11.6   0.4
  3.|-- 84.93.253.83                            0.0%   100    8.2   8.5   7.8  11.6   0.3
  4.|-- core1-BE1.colindale.ukcore.bt.net       0.0%   100    8.4   8.4   7.7   9.2   0.0
  5.|-- 194.72.16.114                           0.0%   100    8.5   9.4   7.7  18.7   2.3
  6.|-- ???                                    100.0   100    0.0   0.0   0.0   0.0   0.0
  7.|-- bbr2-xe-2-1-0.lon003.pnap.net           0.0%   100   15.7  16.6  15.2  40.8   3.2
  8.|-- core1.be3.ams004.pnap.net               0.0%   100   15.5  15.8  15.0  20.5   0.7
  9.|-- border3.ae2-bbnet2.ams004.pnap.net      0.0%   100   22.1  16.6  15.8  28.5   1.6
 10.|-- lithiumtechinc-5.edge1.ams004.pnap.net  0.0%   100   15.1  15.6  15.0  16.2   0.0
 11.|-- aptgm87544.lithium.com                  0.0%   100   15.3  15.6  14.8  16.8   0.1

[#3]

I thought the trace over 4G looked odd - indeed I wondered if I could trust the ping app on the phone.  Therefore I switched the phone on to WiFi and got a trace very similar to that in post #60 - swapped back to 4G and got the above again.  Flipped-flopped a couple of times and traces were identical.

Switched the phone down to 3G only and got the same trace as in #61.

Whilst network routing might have some impact on the overall experience, there is still a substantial amount which ought to be done to tune content caching and component loading.

• Why are images (graphics) not cached, thereby requiring them to be re-downloaded on each page load?
• Other elements could be better optimised - for example style sheets and code files
• Rendering (after down loading) is very variable - it is possible to see the detailed reformatting using Win10 Edge
• Why are the chat service components (live person) referenced at all from community pages - they are not necessary and are constantly utilising bandwidth polling the server

Has Lithium actually sat down and run diagnostic console loads of the various parts of the site on ALL of the common popular browsers and compared the user experience … or are we suffering the somewhat prevalent attitude of developers "We think Firefox is ace so if that's not your browser then tough, we are not testing the product experience on other platforms"?  Being anti Microsoft might be fashionable and hip, but it is not helpful.

[#4]

As a Firefox user I can confirm the experience for FF users is not good either. Typical 6 seconds to 18 seconds to load a page so the other browser users must be suffering.

[#5]

@Townman

I think it's the sporadic several second long waits with nothing at all being sent, received or rendered that is the main issue and what needs to be focussed on.

And I've amused myself by blocking the liveperson.net junk now as well - it makes no difference.

[#6]

@ejs, If you think about it blocking liveperson.net may actually be detrimental to the overall process as the request will still be made but the timeout detection may be longer than the actual response with content. 

[#7]

---

@Townman wrote:

Has Lithium actually sat down and run diagnostic console loads of the various parts of the site on ALL of the common popular browsers and compared the user experience … or are we suffering the somewhat prevalent attitude of developers "We think Firefox is ace so if that's not your browser then tough, we are not testing the product experience on other platforms"?  Being anti Microsoft might be fashionable and hip, but it is not helpful.

---

The problem with that statement is that my default browser IS Firefox, I am experiencing the problem with that browser, and others, over different connections on different machines.

[#8]

I've just been checking one of my sites after doing some rework and ran it through   pingdom to check performance.

So in an idle moment ran community.plus.net through the checks.  Quite revealing.

Here is the summary:

I just tested http://community.plus.net/ with the Full Page test in Pingdom Tools.
This specific test was done on February 7. The web page took 7364 ms to load, used 110 requests, and weighed in at 1.2 MB.
The Google Page Speed performance grade for this web page is 72/100.

There’s a ton of more information you can check out here: https://tools.pingdom.com/#5a31f05eba800000

Follow the link to see the full results.  It also generates a .har file if there is a way to attach and send?

[#9]

Todays visit greeted me with a blank page, moving bar and "your request is being processed" for 10+ seconds.

[#10]

@Anonymous

It doesn't appear to the way I've done it. I've done it so that dnsmasq returns an IP address of 0.0.0.0 for the blocked hosts. In addition, by blocking lptag.liveperson.net, then there are no requests made to lo.v.liveperson.net.

[#11]

I’ll be honest and say I’m not really convinced @ejs as you’d need to block *.liveperson.net as lo.v.liveperson.net may well have a different IP from lptag. I would be interested to see the console output for these requests if you have the time and the inclination.

[#12]

@JonoH

Is there any update from Lithium now that the requested tracert reports have been provided please?

Are they actively investigating any of the observations in the detailed webpage load performance reports provided?

Is the Plusnet team looking at their own space - for example caching of the PN components, consistent use of plus.net or www.plus.net http: / https: to optimise DNS queries and connection modes?

[#13]

It's been passed up the chain at Lithium, I now (finally) have access to raise and escalate issues with Lithium. I'll wait till the next update and see what comes back. 

Plusnet isn't looking at anything yet as it's all hosted at Lithium. If they spot something that we need to look at we of course will. 

[#14]

Jonoh,

Looking at the page load tracing, there are resources being loaded from the *.plus.net space which could benefit from some optimisation.

[#15]

@Anonymous

What I meant was that I have explicitly blocked both lptag.liveperson.net and lo.v.liveperson.net. I have added these lines to my dnsmasq config file:

address=/plusnet.tt.omtrdc.net/0.0.0.0
address=/lptag.liveperson.net/0.0.0.0
address=/lo.v.liveperson.net/0.0.0.0

It turns out that the second line makes the third redundant, because by blocking lptag.liveperson.net, then there are no requests made to lo.v.liveperson.net.

They appear as 0 bytes taking 0 ms in Firefox's network tool: