New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Propose Page speed reports, Load time analytics #1700
Comments
See also #1985 |
This was released in GA: http://www.google.com/support/analyticshelp/bin/answer.py?hl=en&answer=1205784&topic=1120718 We could do something similar, by doing:
Regarding "how to track the page load speed", we could either fire a different beacon (like GA does), or maybe approximate the page load speed by stopping the timer when the asynchronous beacon is fired? But, it might be not accurate enough to do this approximation. |
Reference http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/timing-overview.png We wouldn't capture every perf metric. I think we can condense it two main ones (similar to "drive/road" and "curb" time metrics):
The second metric can be approximated using the naive method shown in the spec example 1. |
It would be great to tackle this before Piwik 2.0... increasing priority so we can figure out the implementation plan |
I'll post my idea later tonight. |
Attachment: changes to piwik.js |
I've attached a patch for proposed (minimum) changes to piwik.js.
Usage:
or asynchronous method:
|
it looks very interesting! For user friendliness and ease of use and maintenance, I'm not sure about asking users to add the "var domLoading = ..." at the top of the page. If we don't pass this value, timing will only work for recent browsers. I think that's good enough, rather than introduce an API input that we may not want to maintain in the future. What do you think? For the php side, I'm working on Custom Var per page, so we could create a "fake pageview" with 2 custom vars that could maybe "update" the previous page view row rather than create a new one... That would make reporting easier I think |
Replying to matt:
Sure, timing for newer browsers only would be easier.
Are you talking about page-level custom vars? |
Yes, #2432 |
OK for limiting this to new browsers implementing timing APIs. These are the browsers we want to spend most of our time on since these are the ones we can easily time and profile. Aim to provide new interesting reports:
Implementation proposal:
I think this would be a fantastic new feature to have. |
This feature is becoming increasingly important for Web Analytics and Piwik should have this very interesting report :) |
New metrics in the site speed reports in GA: it looks very interesting! Tracking Javascript
Note: we don't have to track them all, maybe we should only track the general aggregated value for all visits rather than per-page value since it'd be too much data overhead to store in the Actions reports. |
All part of the Navigation Timing spec (linked above in ticket description). Not in my patch, but could be added. The GA implementation has site and per page averages. |
Hello, have there been any more developments on this? At the company I work for I have been asked to develop a Piwik plugin which will track and display page loading metrics. The plugin will most likely become open-source once it is done. So, in order not to duplicate effort, apart from the attached patch is there any more info or code on the ticket subject? |
Banezaklan: feel free to develop and contribute this feature |
This feature is just too important and too good not to assign the highest priority ;) |
Anybody working on this? I am new to piwik but would be happy to contribute if someone could point me in the right direction. We need this functionality ourselves. Is the best place to start the example plugin? |
My bad! Educated myself a little and figured out where it stands. Replying to nnnnathann:
|
Hi, I have applied the patch uploaded by vipsoft and it seems to work, at least the part where 'nettime' and 'domtime' values are sent to piwik server. My question is what now? How can I view this data that in the Dashboard UI ? Is a new plug-in needed for that? Thanks, |
Hi Horatiu, I am about 1000% naive when it comes to Piwik, and the first thing I did was try to hack a page speed number into the Actions section using the implementation proposal by matt as a guide. I didn't want to submit a patch to SVN as this solution is about as hacky as it gets, but it might give you some insight into where things happen, especially if you are new like me: https://github.com/nnnnathann/piwik/compare/master...page_load Hope that helps! Would love to spend some time to get this working the right way, Piwik is pretty awesome |
Hi nnnnathann, Thanks for your info, I have applied your patch and it works! However, as you said, it's kind of hard to interpret the data since the values of the Custom Variable don't Thanks again, |
Hello all, Notes: Example JS script to be added to monitored website is in the archive. |
Attachment: Site Performance plugin (work in progress) |
Any progress on this? |
No progress yet, we are waiting for a company to sponsor the development on this feature! please contact us for more info |
Anthon's patch to piwik.js is great. I think however that the API should rather be piwikTracker.enableTiming(0.1) to track 10% of page views. We should also use the HTML5 Web Performance API to get the data. Supporting newer browser only is ok for this feature. http://www.html5rocks.com/en/tutorials/webperformance/basics |
In 65458d0: refs #1700 basic performance analytics: handle server generation time for each page and page title CORE
SCHEMA
TRACKER
ACTIONS PLUGIN
plus TESTS for everything |
In f56c9d6: refs #1700 performance tracking in piwik.js
|
flushing the templates worked... Strange I think it's the first time I had to manually delete compiled templates on upgrade on the demo... maybe we introduced a regression somewhere else. It's working anyway, very nice! |
Reopening as we found a bug, eg. on the demo: Some records show an average generation time of "12 years". Some page views have a max generation time of 412 years and 90 days. There could be a bug in the DOMTiming API for some browser, or a bug in the tracker or arcihving mechanism. We should:
|
Also,
|
Could you run this on the demo server to find out more about the records with high generation times?
The generation time is performance.timing.responseEnd - performance.timing.requestStart. Maybe this happens if responseEnd is 0. We should catch this case in JS anyway. |
I was just wondering, would the median maybe be better than the average? |
Attachment: showing requests with wrong performance time |
I think average is OK. See screenshots. I added check to ignore requests longer than 1 hour, which should fix it going forward! |
Hi, not sure if this is helpful. But when I made a hack to measure response time (discreet steps), I used the following javascript to work a bit better whenever profiling time is not available. As you can see there is one for loading the page itself, and one for the entire roundtrip...
and
|
@matt Looks like all the high values come from one visitor... I have no idea why this would happen. Thanks for the patch, that should work. @nicomen you can use piwikTracker.setGenerationTimeMs to use your current method of measurement. In Piwik Core, we were looking for a way that does not require modifications of the tracked site. If you want to do better, just use piwikTracker.setGenerationTimeMs. The time can also be measured on the server side to be even more accurate. |
@ezdesign: ah cool thanks ;) (Although I still think it might be useful to be able to have both traffic/bandwidth speed including the whole roundtrip, and the actual finishing of loading a page. And maybe support for other timings, so maybe it should have been a set of custom variables that are averaged rather than aggregated?) |
I think this is now fixed. The result is beautiful, the perfect V1 of an awesome feature. Well done Timo and thanks to the customer! |
In 1d91fd2: refs #1700 time tracking
|
Added to the User Tracking API doc the new param:
|
We still need to document the JS tracker changes, see my comment about that. Should we add that to the JS tracker doc or write a separate page for performance analytics? |
I added to the js tracker doc the following:
I think you're right, creating a new small user guide for Page Speed report. I created the page at: Site Speed - feel free to improve it (but no need to discuss the "Disable" feature since we dont want users to disable) Btw I also found a bug:
|
Nice documentation, Matt. Well done! |
In 6803f67: Refs #1700 important: renaming generation_time_ms to gt_ms for keeping parameters name short. |
See also ticket #4173 to Add Page Generation Time for Site Search requests |
In Piwik 1.12 we are shipping Page Speed Report in Piwik! A new column "Average Response time" is displayed in the Pages Urls and Page title reports. This column is the time it takes for server to generate the response and for the visitor to download it.
The historical view of the time can be seen via Row evolution feature.
The average time across all pages is plotted on Visitor > Overview.
Time tracking works for all modern browsers, who most implement the Dom timing API.
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html
Enjoy this new simple page speed report in Piwik.
The text was updated successfully, but these errors were encountered: