Ci sono due cose di cui tenere conto, per quanto riguarda la lentezza di caricamento:
La prima è interna a Webbino: la pagina viene inviata al "driver" della scheda di rete (la libreria che la gestisce, insomma) un byte alla volta. Ora, se il driver non fa buffering (e credo che nessuno lo faccia), ogni byte viene inviato al client in un pacchetto separato, cosa che causa un overhead enorme, visto che per trasmettere un byte ne viaggeranno almeno un centinaio sulla rete, tra header IP, TCP e ACK di risposta.
Questo è noto ma, per mia esperienza, sulle connessioni cablate non crea un grosso problema, le pagina si caricano comunque in maniera accettabile. Sulle connessioni wireless però è un problema più pesante, vista la maggiore latenza, lentezza e perdita di pacchetti. Per questo nei driver wifi Webbino implementa un buffer, in modo da mitigare il problema.
Ovviamente se il tuo Arduino è collegato via Ethernet ma poi in mezzo c'è un ponte radio, il buffering andrebbe fatto, ma Webbino non può essere a conoscenza di questo. Potrei forse spostare il buffering più ad alto livello e mettere una direttiva di configurazione per forzarne l'utilizzo, che ne pensate? Non dite "abilitalo sempre" perché la RAM è preziosa ;).
Altro problema è la sostituzione dei tag, che viene effettuata "in diretta" mentre la pagina viene inviata al client. Se la funzione che gestisce il tag impiega 5 secondi, ovviamente l'invio della pagina è sospeso per 5 secondi. Lì sta a voi scrivere uno sketch "furbo" che sostituisca i tag il più rapidamente possibile. Ad esempio, io non farei mai leggere i sensori in diretta, li leggerei per conto mio in background ogni tanto (1 minuto, 5 minuti) e salverei i risultati in una variabile, in modo da poter ritornare subito questa variabile al momento della sostituzione del tag.