I’ve created a [little snippet][1]… plugin… how do you call it that calculates and show the rendertime of every page.
Disclaimer - I created it very quickly and did not always follow the Kirby Guidelines for implementing this little snippet… so do try this at home, not at work or development first
##VARIABLES##
The “plugin” takes two variables;
Where / how to show the rendertime.
What text is used to show the rendertime.
The first option has three basic values;
A. Show in the footer
B. Show in the html-source
C. Show on the browser tab- titlebar
##BASIC USAGE##
Add a custom-field to your site-blueprint like this;
label: Rendertime
type: text
default: (rendertime:1 text:page rendered in @ seconds)```
****
This will output something like below at your sites-panel page;
<img src="//cdck-file-uploads-europe1.s3.dualstack.eu-west-1.amazonaws.com/standard20/uploads/getkirby/original/2X/6/6a8748206ff491538c093bfc3ac1f35344e16eae.png" width="646" height="237">
As you can see in the helper-tag, the key "**rendertime**" accepts several values (numeric only)
- 1 : show rendertime in code
- 3 : show rendertime in page
- 5 : show rendertime on tab
You can also take the sum of these individual numbers;
- 1 and 3 = 4 : this will show the rendertime in both pag and code
- 1 and 5 = 6 : this will show it in code and on tab
- 1 and 3 and 5 = 9 : this will show it all over the place
- etc...
The key "**text**" is the string that is returned, while the "**@**" character is replaced with the actual rendertime.
****
##INSTALLATION##
****
Installation is simple, jump to the **[GitHub-page][2]** and download the **[.zip-file][3]** that includes the directory-structure.
Alternatively you can create this folder: ```\site\tags\``` and place the file "**rendertime.php**" in it.
When you have setup the blueprint for your site (so you can get the rendertime site-wide, and not only at a specific page), you have to alter the header- and footer of your site.
This is mostly done in the "**header.php**" and "**footer.php**" snippet.
Simply add ```<?php rendertime('start'); ?>``` at the very first line of your html-header-template (even before the <html> tag).
Navigate to the footer, and place ```<?php rendertime($site->rendertime()->kt()); ?>``` just before the closing </body> tag of your html-template.
Now everything is done;
- You have the "**rendertime.php**" file in your "**tag**" folder.
- You have setup the blueprint for your site, where you can change the default settings.
- You have placed the **start-** and the **endcode** which the snippet needs to calculate the rendertime.
[1]: https://github.com/dmotion/kirby-rendertime
[2]: https://github.com/dmotion/kirby-rendertime
[3]: https://github.com/dmotion/kirby-rendertime/archive/master.zip
Use-case is development… I need / want to know how much impact some code-changes do have on my sites performance.
Using this snippet, I can see the effects on the fly…
And I’m migrating two Wordpress-sites to Kirby, they have the same snippet - so I can compare the speed of a Kirby-page with the exact same page, rendered in Wordpress (same server, same content, same design, etc…).
Alright. Because the plugin is only being used for development, it makes even more sense to store the configuration in the config file (even a host-specific one for your development host), not in the content.
I’ve made a new class of this plugin based on yours, but using the Kirby coding style guidelines and a config.php file for the development environment.
When I created my version, I knew Kirby for less than a week… so my code was actually some kind of a code-doodle…
Now I see you code, I can imagine way better how to write my new / next plug-ins, thanks!
It’s very interesting to have access to your rendertime; because you can compare it against something like Wordpress, or see on the fly what code-changes / content-changes do to your server- / page-performance!
Maybe we should also change the timestamp;
$rendertime = date('Y/m/d - H:i:s', time());
(I re-ordered the Y/m/d, so the format is more universal - I originally used a European format, but maybe the American standard is better to follow).
But I did fiddle around with it (in my own original code, a week ago) and some shared servers did not allow access to memory_get_usage(true); resulting in a php-error.
So I decided to skip that part, just to be sure.
But it is very nice to have it in the updated plug-in, because the memory-usage is also very important (some cheap server do restrict it, so this way you can keep an eye on it).
that calculates and show the rendertime of every page.
