Poor (general) website performance
Discussion
OK, so for quite some time I've cut the website some slack over poor performance both on desktop and tablet browsers as it was obviously getting a visual refresh.
Now that the refresh seems to be somewhat complete, I have to ask when can some optimisation be done of the browsing experience?
Given that there is only effectively one medium to access PH (I'm discounting Tapatalk at the moment), the dire state of the website optimisation is a huge barrier to continued usage. Apart from the overbearing ad loads of recent times (which are being discussed elsewhere on this forum), the webpage content is due some very basic optimisation to significantly enhance browsing experience.
Slow page loads, delayed page layouts, extreme loading times, screwed up CSS fonts/metrics, extremely bugged/poor layout on tablet, etc just make the whole experience painful and more of an effort than it should be.
For some direction, how about an effort to enhance these woeful scores for the browsing experience reported by Googles Pagespeed tools
https://developers.google.com/speed/pagespeed/insi...
rating a 33/100 for the mobile experience and 34/100 for the desktop (@2014-08-21) is pretty dire in this day and age. Enacting some (all?) of the recommendations made there would be a great start for those things you directly control!
I'd also suspect that those figures are far from a true reflection of how bad the experience can be for general users either as they don't really factor in delays in reaching advertisers sites/content as a general home/office/mobile UK user versus reachability from the Googleplex, which will be very significantly different.
I know this reads as overly negative, but I've used the site for years and loved the content and discussions and am genuinely distressed to see the current performance. I've ramped my AdBlocking s/w up to max to compensate some aspects, but I appreciate this is not good for the well-being of PH nor its finances and I'd love to back it off especially to safeguard the future of the site, but work needs to be done.
Is there any recognition that this is a problem and if so are any resources being applied to the issues?
Happy to help in any way I can if it moves the issue along ...
Now that the refresh seems to be somewhat complete, I have to ask when can some optimisation be done of the browsing experience?
Given that there is only effectively one medium to access PH (I'm discounting Tapatalk at the moment), the dire state of the website optimisation is a huge barrier to continued usage. Apart from the overbearing ad loads of recent times (which are being discussed elsewhere on this forum), the webpage content is due some very basic optimisation to significantly enhance browsing experience.
Slow page loads, delayed page layouts, extreme loading times, screwed up CSS fonts/metrics, extremely bugged/poor layout on tablet, etc just make the whole experience painful and more of an effort than it should be.
For some direction, how about an effort to enhance these woeful scores for the browsing experience reported by Googles Pagespeed tools
https://developers.google.com/speed/pagespeed/insi...
rating a 33/100 for the mobile experience and 34/100 for the desktop (@2014-08-21) is pretty dire in this day and age. Enacting some (all?) of the recommendations made there would be a great start for those things you directly control!
I'd also suspect that those figures are far from a true reflection of how bad the experience can be for general users either as they don't really factor in delays in reaching advertisers sites/content as a general home/office/mobile UK user versus reachability from the Googleplex, which will be very significantly different.
I know this reads as overly negative, but I've used the site for years and loved the content and discussions and am genuinely distressed to see the current performance. I've ramped my AdBlocking s/w up to max to compensate some aspects, but I appreciate this is not good for the well-being of PH nor its finances and I'd love to back it off especially to safeguard the future of the site, but work needs to be done.
Is there any recognition that this is a problem and if so are any resources being applied to the issues?
Happy to help in any way I can if it moves the issue along ...
Google [bot] said:
Not until next month you haven't 
Don't believe everything you read ...I'm a long time lurker on many sites and I've followed Pistonheads since its early years, many of those I spent drowning in email and rarely had the time/inclination to descend into more prolonged online discussion.
When you do IT/Tech as a living you sometimes need to disconnect in the free time you have and get out and drive/ride ...
Nice spot though, I had no idea until you pointed it out how long this account had been open/reg'ed
Happy to receive any feedback, so thank you.
First the techie numbers...
The current system operates at an average of 68ms~ at the application level and 6.74s~ for browser load time. This is split across DOM processing (2.65s) and page rendering (3.41s).
At a browser level we are operating at around 0.83 apdex level, and something we want to improve - that breaks down as:
68.7% users satisfied
28.4% users tolerating
2.9% users frustrated
I wanted to show the numbers to demonstrate that we are aware of the situation and have metrics in place to know if we are moving in the right (or wrong direction).
We have worked hard to put in place systems and architecture that speed up the system from an application level, and compared to a couple of years ago we are miles ahead of where we were and happy with our 68ms times.
Where we need to improve, and are working hard to do so, is the rendering of the page to the browser. A mixture of a lot of third party tooling and the ad serving is always going to cause a little delay in that, but I take on board the things we can do from a front end code point of view to speed things up.
We are currently working through a refresh of the experience on mobile, moving away from our current supplier (a third party site that scrapes the content) - so as we build each new section we are making sure we are keeping to good Front End coding standards, and have put things in place to speed up page load, reduce page size etc... this will then also improve the desktop/tablet experience too.
These will be rolled out over the next few months up to Christmas and hopefully you will see an improvement - as well as we hope on the metrics.
~over the last month
First the techie numbers...
The current system operates at an average of 68ms~ at the application level and 6.74s~ for browser load time. This is split across DOM processing (2.65s) and page rendering (3.41s).
At a browser level we are operating at around 0.83 apdex level, and something we want to improve - that breaks down as:
68.7% users satisfied
28.4% users tolerating
2.9% users frustrated
I wanted to show the numbers to demonstrate that we are aware of the situation and have metrics in place to know if we are moving in the right (or wrong direction).
We have worked hard to put in place systems and architecture that speed up the system from an application level, and compared to a couple of years ago we are miles ahead of where we were and happy with our 68ms times.
Where we need to improve, and are working hard to do so, is the rendering of the page to the browser. A mixture of a lot of third party tooling and the ad serving is always going to cause a little delay in that, but I take on board the things we can do from a front end code point of view to speed things up.
We are currently working through a refresh of the experience on mobile, moving away from our current supplier (a third party site that scrapes the content) - so as we build each new section we are making sure we are keeping to good Front End coding standards, and have put things in place to speed up page load, reduce page size etc... this will then also improve the desktop/tablet experience too.
These will be rolled out over the next few months up to Christmas and hopefully you will see an improvement - as well as we hope on the metrics.
~over the last month
RacingPete said:
Happy to receive any feedback, so thank you.
First the techie numbers...
The current system operates at an average of 68ms~ at the application level and 6.74s~ for browser load time. This is split across DOM processing (2.65s) and page rendering (3.41s).
At a browser level we are operating at around 0.83 apdex level, and something we want to improve - that breaks down as:
68.7% users satisfied
28.4% users tolerating
2.9% users frustrated
I wanted to show the numbers to demonstrate that we are aware of the situation and have metrics in place to know if we are moving in the right (or wrong direction).
Glad to see you have metrics in place, not because I believe them First the techie numbers...
The current system operates at an average of 68ms~ at the application level and 6.74s~ for browser load time. This is split across DOM processing (2.65s) and page rendering (3.41s).
At a browser level we are operating at around 0.83 apdex level, and something we want to improve - that breaks down as:
68.7% users satisfied
28.4% users tolerating
2.9% users frustrated
I wanted to show the numbers to demonstrate that we are aware of the situation and have metrics in place to know if we are moving in the right (or wrong direction).
as absolutes, but correctly as you point out because it gives you a mechanism to rate improvement/degradation in your service over time and thru enhancements. I appreciate you sharing the values however and whilst it looks like your backend processing is pretty good, like you I think the issues are to do with the rendering in client of the pages rather than the backend per se.
In the above satisfaction metrics, what was the T value used out of interest, as you appreciate the metrics are worthless without defining your base constraint value T … and I'll understand if you don't want to share as it would give insight into what you deem your ideal
RacingPete said:
We have worked hard to put in place systems and architecture that speed up the system from an application level, and compared to a couple of years ago we are miles ahead of where we were and happy with our 68ms times.
Where we need to improve, and are working hard to do so, is the rendering of the page to the browser. A mixture of a lot of third party tooling and the ad serving is always going to cause a little delay in that, but I take on board the things we can do from a front end code point of view to speed things up.
See above, I'd concur …Where we need to improve, and are working hard to do so, is the rendering of the page to the browser. A mixture of a lot of third party tooling and the ad serving is always going to cause a little delay in that, but I take on board the things we can do from a front end code point of view to speed things up.
RacingPete said:
We are currently working through a refresh of the experience on mobile, moving away from our current supplier (a third party site that scrapes the content) - so as we build each new section we are making sure we are keeping to good Front End coding standards, and have put things in place to speed up page load, reduce page size etc... this will then also improve the desktop/tablet experience too.
These will be rolled out over the next few months up to Christmas and hopefully you will see an improvement - as well as we hope on the metrics.
~over the last month
I'll look forward to the hopefully forthcoming improvements, I appreciate that the recent work on the look of the site has "lifted" and cleaned the form and content of some of the pages and if that can be followed through with work on reducing render time then I'm sure it will all be worth the upheaval.These will be rolled out over the next few months up to Christmas and hopefully you will see an improvement - as well as we hope on the metrics.
~over the last month
Many thanks for the rapid response, the insight into the direction and assurances that changes are coming. I also appreciate you sharing numbers, I understand a possible reluctance to do so on some parts, but its nice to know you have the tools in place to maybe measure some of the pain the users are feeling and see improvements coming ...
silvermog said:
In the above satisfaction metrics, what was the T value used out of interest, as you appreciate the metrics are worthless without defining your base constraint value T … and I'll understand if you don't want to share as it would give insight into what you deem your ideal
The end user T value is 7.0 seconds.This is not because we feel that is an acceptable value for the load of the site, I would be happy with sub 4 seconds, but it is a consistent value that we can work with to improve.
RacingPete said:
silvermog said:
In the above satisfaction metrics, what was the T value used out of interest, as you appreciate the metrics are worthless without defining your base constraint value T … and I'll understand if you don't want to share as it would give insight into what you deem your ideal
The end user T value is 7.0 seconds.This is not because we feel that is an acceptable value for the load of the site, I would be happy with sub 4 seconds, but it is a consistent value that we can work with to improve.
So as a metric for quantification of your improvement/degradation over time, or as I suspect a pan-corporate metric that can be used somewhat consistently to assess websites for multiple web properties, Apdex is OK. It does tend to reduce everything to averages though, so the outlier issues get smoothed out, no matter how important they may be to address in real life.
The real issue though is that when you peel away the layers what this really means is that your measure of:
RacingPete said:
68.7% users satisfied
28.4% users tolerating
2.9% users frustrated
equates to 28.4% users tolerating
2.9% users frustrated
68.7% users receive completed pages inside 7 secs
28.4% users are tolerating pages inside 28 secs !!!
2.9% users are frustrated because after 28 secs they still don't have a completed page
So, I'd stand by my original points, stats aside (as those above stated in English don't look stellar by any means for a massive web property in 2014), with nearly a third of your users/browsers falling into the 7-28sec bucket, you have a slow cumbersome feeling site.
I'd argue that T of 7 (hence F—the frustration point at which you lose viewers—of 28) is too high for the real world of short(er) attention spans, T in the 3-4 range sounds much more viable as you've identified
Anyway, not to labour the point, I really appreciate you being forthright about the stats, the fact it is known/understood and being worked on and I look forward to seeing the results of the impending changes … and maybe re-visiting the topic/stats after your changes are implemented.
Good luck ...
Gassing Station | Website Feedback | Top of Page | What's New | My Stuff