Archive for the ‘blog’ Category

Om web-hotell og norske domener – oppdatert

Om web-hotell og norske domener

Kiko har lenge levert hjemmesider til norske og spanske firmaer og organisasjoner. I det siste har vi fått en kunde som har .no adresse, og vi har derfor sett litt på domeregistrarer og web-hoteller i Norge. Både for kunden vår og for nye kunder.

Jeg fant en fin oversikt over domener i artikkelen Prissammenligning: Hvem er den rimeligste domene leverandøren?. Kiko og jeg gikk igang med å undersøke de seks rimeligste.

Vi vil gjerne ha en leverandør som også har engelsk tekst på domene-verktøyene, og aller helst på tilbudene sine også.

Dessuten ser vi at mange tilbyr domener for 50 kroner eller mindre det første året, men tar både to og tre-hundre for senere år.

Av de seks rimeligste og Webhuset som har satt ned prisene, fant vi følgende som så interessant ut for oss og våre kunder på Costa Blanca:

Slik det ser ut på lørdag formiddag ser ut til å være ok, men litt dyr. derimot er rimeligere og leverer SSD på web-hotell.

I løpet av helgen får vi nok bestemt oss…

Touching Node.js

A nice little blog made with node.js and express

A nice little blog made with node.js and express

I’ve had really fun following Ev bogue in how to learn webdesign, node.js, git, virtual hosted servers and his excellent compact web framework bitters. I’ve followed his advice in reading, coding and video-watching.

I did think I’ve got it, but I had to dive a bit more. For instance, I didn’t get how I could make a simple blog. There are blogframeworks for node.js out there like Calipso, but their complexity scared me. I know that I just want a simple blog without sidebars, but with excellent typography. And I didn’t have a clue on how to do that in node.js.

The other day i saw a interesting article in nettuts on node.js which lead me to Introduction to Express, which triggered me to write and run the code from the post.

This introduction was marvellous for me. I now could get a read-only blog pretty nice up on my Mac. It did use Bootstrap to get it nice, and I’m not so happy with such a huge CSS framework and the footprint it has in memory.

Now I just need to know how to connect the posts to a database. Any hints out there?

4 Modern Mobile website test results

Yesterday I spent some time on researching the way P. J. Onori, MattGemmel and Ven Portman has created and run their blog/websites. I also measured LightCMS, which are a competitor to

Matt Gemmel uses Octopress, which generate a static web-page on GitHub.

Portman however, I will better let him explain himself: is built on Bitters and deployed using Node.js on Digital Ocean(rewards link).

Both Gemmel and Portman are using exiting new technology, and I thought I should measure how the stack up to the fastest WordPress blog on the earth,

The following websites are all promoting speed and open source and I look at their websites as proof of concept of their ideas on web design.

Matt Gemmel and P.J. Onori is also promoting readability.

The result of the tests are quite interesting.

The contenders

  • by PJ Onori, is a full database/php application with a templating language.
  • by Matt Gemmel use Octopress, a static webapplication for blogs.
  • is just a website, with some pages, written in Bitter, which is a Node.js framework.

The tests

All tests are run by The test taken from Massachussets and with and iPhone 5 on Verizon 3G.

The following is written, a symbolic Markdown calculator app.

Mobile overhead is 0.7 seconds according to Google Mobile speed pages.

overhead = 0.7s

Average page size:

somerandomdude size = 43kb
mattgemmel size = 380kb
evbogue size  = 795kb
LightCMS size = 1173kb

Loadtime on mobitest:

somerandomdude time = 1.06s
mattgemmel time = 1.8s
evbogue time  = 0.71s
LightCMS time = 4.02s

Throughput kilobyte per second:

somerandomdude size / somerandomdude time => 40.566kb/s
mattgemmel size / mattgemmel time => 211.1111kb/s
evbogue size / evbogue time => 1119.7183kb/s
LightCMS size / LightCMS time => 291.791kb/s

Throughput justified for mobile overhead:

somerandomdude size / (somerandomdude time - overhead) => 119.4444kb/s
mattgemmel size / (mattgemmel time - overhead)=> 345.4545kb/s
evbogue size / (evbogue time - overhead)=> 79500kb/s
LightCMS size / (LightCMS time - overhead) => 353.3133kb/s

My comments

I’m impressed. First with which is a fullblown WordPress site. Delievering the front page with photo, graphic images and a list of posts on just a second is formiddable. It’s throughput is 119 kb/s.

The throughput on was impressive with 345 kb/s.

LightCMS managed an even higher throughput on 353kb/s, but fell short in loading the page which took 4 seconds.

But blows the two other away in terms of throughput with almost 80 Mb/s, or around 2500 better than the other.

My preliminary verdict is:

If we should follow Google’s recommendation on 1 second loadtime, only and evbogue would comply.

But taken the future into consideration, it’s clear that is obtaining results with Node.js that we not could even dream about some years ago.

The winner is…

For myself my final verdict is: is a WordPress blog passing the Google 1 second requirement.

That’s more than enough for me.

But the result of will make me invest time in Ghost which is built using Node.js. Ghost which will be launched in September and P. J. Onori is preparing a theme to it.

Furthermore, pointed at And combining their droplets with a nginX server on SSD is worth to try!

And as a desert – something good to read from one of the contenders

And lastly, Ven Portman – alias Ev Bogue in did write a thoughtful article, Distribute Everything, on why we should strive for true distribution, and not use sites like Medium, in which he actually wrote the article!!?

Smashing Magazine give mobile websites 1 second to load

Smashing Magazine has an article called Creating High-Performance Mobile Websites written for .NET developers. They write that the mobile communication takes 2 seconds and that website has 1 second left to load their content, before their readers fly.

Their introduction is quite interesting and the graphic they’ve got from is very telling. Here is the part where they explain the mobile tower challenges:

Mobile phones use radios for all communication, and they have little batteries that need to be carefully managed in order to avoid running out of power. As a result, radios are shut down very quickly when not in use, increasing the perceived time that a Web page takes to appear. 2G and 3G radios could require up to two seconds to establish an operational HTTP connection. If we accept that users start to lose interest after three seconds, then a website has only one second to respond. Think of this as the “golden second.”

The Golden Second.

I do view their story a bit exaggerated. Maybe .NET is slower than Linux. But I’ve tested website load-time to be less than 1 second. The test was run in the US.

Google however, are seriously working to enable website to load on 1 second, as I reported on earlier blogposts.

Finally someone expressing the “1 second blog” message clearer than water!

Lauren Hockenson in Gigaom Two second mobile time? Google says it’s vital to success, is posting a terrific good post on speed on mobile. And the post is littered with good links to relevant articles.

Regarding clearer as water, it may be have been taken from the Spanish mas claro que la agua, which is a way to paraphrase obvious. If so, I apologize.

The article refers mostly to Google research, that in sums shows that you at the best have from 0 to 300 milliseconds to render a page on a 3G and 300–700 milliseconds on LTE. The consequence is that we can not call any resources before the first page is loaded and showed.

The most impressing in the post is the graphic from Google showing what it takes to load a page on 1 second. It shows clearly the challenges the mobile web developers are up to, even when the mobile internet works at its best.

The time a "1 Second Blog" has left to do anything is 0.3 seconds!

The time a “1 Second Blog” has left to do anything is 0.3 seconds!

I’ve been diving into the links, and what’s clearly stood out for me, was that you have to render the page after the first 14 Kb of code, HTML, CSS and Javascript included. If you have more code, the TCP protocol will force you to make repeated calls and slow you down way above the 1 second goal.

But 14 Kb of code is almost nothing for a web site! If you will do this in WordPress, you must be sure to let these 14 Kb consist of text and just the necessary part of the CSS inline. What a challenge!

I let Gigaom conclude with:

The average mobile page loads in 7 seconds, and that just doesn’t cut it for users. Google, thankfully, has developed tools to get your website speedy and efficient.

Hvorfor mobile nettsteder gjerne kan være 100 ganger raskere

Oppkobling tar tid

Kommunikasjon via mobilnettet tar tid. I Googles video fortelles historien: Mobilen skal finne masta. Masta skal godkjenne mobilen, og gi den beskjed om dette. Alt sammen før noe som har med nettsiden å gjøre setter igang. Tiden dette tar er fra 0,7 sek til flere sekunder. Jo flere andre mobiler som snakker med masta samtidig, jo lenger må du vente.

Gjør deg ferdig, ellers…

Når så endelig mast og mobil blir enige, er det viktig at det du trenger kommer fort. Etter noen sekunder kaster nemlig masta deg ut, og forlanger at du starter på nytt. Dette for å slippe andre til.

Men hva sier statistikken?

Hvis en måler nettsider på mobil er de gjennomsnittlig 10 og opptil 66 ganger senere enn på en PC.

De undersøkte nettsidene er alle proffe nettsteder med nesten ubegrensede ressurser. Når deres sider kan være 66 ganger tregere på mobil, kan en forvente at nettsteder med mindre ressurser bak seg kan komme enda dårligere ut.

Crawford: Man kan ikke bruke PC verktøy på mobil

I en 10 tusen ord artikkel forklarer han hvorfor Javascript og memory-verktøy ødelegger for mobile web apper. Et sammendrag finnes i posten Brilliant @DrewCrawford: Why mobile web apps are slow.

Crawford viser hvordan den første kan redusere hastigheten mellom 5 og 50 ganger. Og den andre multiplisere svartiden når mobilen blirnstresset.

Det er summen av svakhetene gør det tregt

Kombinasjonen av svakhetene ovenfor gjør at en nettside fort kan bli 100 ganger så treg på en mobil, som på en PC på Wifi.

Googles initativ for en raskere web

Google har et initiativ for få svartiden ned til ett sekund. Siden mobilmastem kan ta hele syv tideler så må en egentlig ned til 0,3 sek, for å få en følelse av umiddelbar respons. Google forklare i detalj hvorfor det tar fra 0,7 til flere sekunder å bare få kontakt med mobilmasten.

“1 Second Blog” plattformen

Målet for arbeidet rundt denne plattformen er: øke hastigheten på mobile sider med omtrent 100 ganger slik at de kan laste på mindre enn et sekund.

Her er hva vi har gjort så langt:

  • designen er omtrent 5 ganger raskere
  • innholdet er komprimert til rundt en femdel
  • hastigheten på server er ca. firedoblet
  • Javascript er bannlyst

Av de tre første puntene følger regnestykket 5 * 5 * 4 = 100. Mao har vi økt hastigheten på de mobile sidene våre med rundt 100 ganger. Da først har vi en reell mulighet til å redusere fra 20–50 sekunder og ned mot de tre tidelene som skal til for at en mobil nettside kan åpne på ett sekund.

Vi er nesten 100 ganger raskere allerede!

Vi har målt reduksjon fra 20 til 0,7 sekunder på bloggen du leser her, når den kjører på 1 Second Blog" plattformen. Med ytterligere komprimering ser vi nå at 0,3 sekunder som et realistisk mål. Målinger er delvis publisert i tidligere poster.

Med hundre ganger raskere nettsider for mobil, vil internett fortsatt kunne være et alternativ til apper.