I often find a piece of nice software and I like to read “behind the scenes” about it, when a blog is available. Then it makes me slightly sad, when I find out the latest post is from 2 years ago. And yesterday I was like: “Hey, that’s MY blog as well!“ :)
Then I thought about it. It’s quite hard to do a job and then to blog about it. Even I’d like to, but I can’t promise I’ll do better in the future. Self made publicity steals time from the object of publicity, more time blogging means less time coding.
On the other hand – who says I have to write a War and Piece every time? I have about 20 unfinished posts in stock, so now it might be the right time to slice them into smaller finished ones.
Anyway. What I’ve been up to with QetriX? Finishing the concept. I did another iteration of it, quite finished Java version after PHP has been usable. From that point I understood the PHP version is wrong yet again, so now I’m (yet again) reeingineering and refactoring it.
The finished version will be even more consistent among platforms than ever. I discarded “index” script as the entry point and introduced “app” and “file”. For PHP it’s handled by .htaccess, for Java it’s handled by web.xml.
The WebApp will contain a HTML generator (basically Components with Converters to HTML) for internal WebView, which fits perfectly into the QetriX idea. I love this!
I finally decided to separate data from users and data from geodata. Coordinates and user info in data (= mostly in Particles) will be still supported, but not recommended.
I finished my tracker app for iOS, which works well and will replace Moves for good. I was really upset Moves is not working offline and unfortunately the biggest test for the tracker so far, my short trip to Dubai, failed, because I screwed up a final update and the app crashed on startup. But never mind.
Last month I exported my first worksheet from my time tracker as well, works like a charm. I’m thinking of merging it together with the tracker, so it will know when I arrived to work and when I left.
I would like to write “and that’s about it” now, but it isn’t. But I’ll get into it in some of the upcoming posts.
Optimize a website for optimal performance is not an easy task. It may feel it’s better to start from scratch, but who says you have to adopt all of it? Try this and that now, but next time you build a new site, try to use as much as possible.
Not only it will be faster for your readers or visitors, but you will decrease server load as a bonus. If you host your site in the cloud, it means you can reduce required hardware and lower the cost. And when search engines start to penalize poor preformace, you wouldn't have to do a thing.
Do not combine getting and setting visual styles, because it will cause browser to reflow layout many times. You should get all styles first in a batch and then set all styles in a batch.
Do not use for..in, because it's slower, than regular for loop.
Use objects as fast lookup hashtables for either DOM objects, or nested objects.
Take advantage of reference types: arrays, objects, dates. It's faster to pass a DOM reference. Comparing object references is also faster.
Use switch(true) if: if: instead of if-elseif-else statements. Also use === instead of == for faster typed comparisons, also use instanceof for type checking.
Numbers are stored with 8 bytes (double-precision 64-bit binary format IEEE 754 value), strings are 2 bytes per character (set of 16-bit unsinged integer values) a booleans are (surprisingly) stored with 4 bytes, because of C++ implementation using char type for booleans.
Always use proper image format – JPEG (JPG) for photos and PNG for everything else. Because JPEG is lossy format, you can tweak quality (from 0 being crappiest but smallest to 100 being best, but largest) to achieve best ratio between quality and file size. You may need just to re-save JPEG photos, even it slightly impacts quality – but often greatly lowers file size. For both formats there are online and downloadable optimization tools, that help lower their file size.
Consider resizing large photos, especially for mobile websites. On the other hand, because of different dpi, you may need double the size of graphics elements based on image to look good or hi-res displays. The best option is to use SVG, but like CSS, it may also affect performance if not used wisely.
You may not load the content (photo, video...), if it’s not yet visible. This technique is called “lazy loading”. You can detect it’s vertical position and compare it to the scrollbar position. When they meet, you can trigger download.
Be aware, that 4G/LTE or even 3G is still a dream in a lot of countries. You should build your responsive design to work as a lite version on mobile devices – without large cover images, animations, effects, transitions, shadows and gradients, because they are CPU heavy and drain batteries much faster.
Many effects, achieved by images in the past, are nowadays possible just by CSS effects. They are significantly smaller, of course, but increases CPU time required for their rendering. A lot of shadows and gradients, but also transitions and animations may kill performance on (low end = mostly used) mobile devices and drain their batteries faster.
Also you can omit webfonts on mobile. The only sensible use there is for icon fonts, but nowadays it's better to use SVG for that. Keep in mind you can't change it's color e.g. on :hover, if you use the SVG as background.
Selectors are evaluated from right to left, so “#main a” means browser would have to find all links anywhere on the page and then traverse the object tree for every single one of them to find which one has any descendant with id="main".
The fastest selectors are “class” and “id”, the slowest are attributes and pseudo-classes/-elements. But before you start rewriting your CSS into classes only, it would probably gain just milliseconds. Selectors performance is a job rather for browser creators, than web devs, and there are tons of more efficient optimizations. But it's good to know about it and use it as much as possible.
The best you can do with your selectors is use less of them, not overqualify them (instead of ul li span you may use just li > span) and benefit from inheritance more. And if you use a CSS preprocesor, check the output it makes – some of them generate tons of long descendant selectors.