Between you and me, I've developed a bit of an obsession... I lie in bed awake thinking about it... and there's no support network I can join. Yes that's right, I've become completely obsessed with making TeamworkPM insanely fast. It's an issue. ;)
Introducing pushState
It started off as an experiment but I got so excited with the speed improvements that I worked solid for about 12 hours adding pushState support to the TeamworkPM.
"pushState" is a part of the HTML5 specification. It's essentially a system used by modern browsers to change the current page address but only load in the changed data.
So instead of a full page refresh which requires all the boilerplate HTML, CSS, Javascript and images to reload, only the part of the page that need to change is loaded.
So now if you are using Chrome, Firefox or Safari, pages will load much much much much quicker as you move between tabs.
Sweet... dreams are made of this. HTML5 rocks – the whole Internet will use pushStates shortly.
A little side note: We have pushState support coming for IE9 and IE10 shortly - we just want to do more testing to ensure that everything is perfect for you first. IE10 has 'proper' support for pushStates. Can't wait.
Page partials
It's a simple idea used by lots of high performance websites like Facebook and Google – load just enough primary top-of-page content so that the user sees something immediately, then load in the remaining segments as fast as you can.
We've applied this idea to activity steam sections on the Dashboard and Overview pages. We've also applied this to your task lists so you will see them subtly stream in now.
Browser caching with eTags
We've got incredibly serious about making sure your browser caches everything possible using eTags. So if you've loaded a task list a few minutes ago and there's been no changes to that task list, then when you revisit the list we tell your browser that you have it already. The result is that the task list loads instantly for you the second time round.
In-memory components
This month we also changed the internal architecture of TeamworkPM so that the underlying code that runs TeamworkPM is held in in-memory classes instead of slow template based files. It was a lot of work and we had a few glitches and long days but the result is definitely worth it.
Database optimisation
Last but definitely not least, this month we did some tweaking to the database servers settings to allow them to hold more data in-memory, allowing them to serve data quickly from memory instead of reading from the hard disk. It's very geeky so I won't go into too many details... (InnoDB cache size doubled).
This is just a start! We have some big plans to make TeamworkPM even faster including introducing pushState support to the entire application.