Using CSS Parameters to Stop Content Shifting with Dynamic Vue/React Content

Con­tent Shift­ing, also known as Con­tent Jump­ing, hap­pens when ele­ments of a web page change height while a page is load­ing. This can be dis­ori­en­tat­ing to users, and in extreme cas­es can cause prob­lems if a user clicks on an ele­ment as it moves, caus­ing unde­sired input. It’s also expect­ed in 2021 that search engines will begin penal­is­ing con­tent that exhibits con­tent shifting.

To avoid con­tent shift­ing, the ele­men­t’s height would be set regard­less of the dynam­ic con­tent it contains.

When using Vue or React JavaScript frame­works, I’ve found that CSS para­me­ters are use­ful. In my exam­ple, a Vue app loads dynam­ic con­tent and dis­plays it. Unfor­tu­nate­ly this caus­es con­tent shifting.

To avoid this, I pass the num­ber of rows in the HTML/view:

<div class="container" style="--preload-row-count: {{ $count }};">...</div>

In my CSS/SASS stylesheet, I then use this para­me­ter in a cal­cu­la­tion. There are two columns, so the num­ber of rows is divid­ed by 2. It is then mul­ti­plied by the height of a sin­gle row, and a min­i­mum height is set for the con­tain­er so that it will not shift:

    --calculated-board-rows: calc( var(--preload-row-count) / 2);
    min-height: calc( var(--calculated-board-rows) * 50px );

This fair­ly sim­ple method is an effec­tive way to stop con­tent shift­ing using CSS para­me­ters and calculations.

Twilio Studio — IVR and Chat Bots

Twilio Studio — IVR and Chat Bots

I’ve used Twilio for a while for pro­gram­mat­i­cal­ly send­ing and receiv­ing SMS mes­sages. There’s also a visu­al edi­tor called Stu­dio that can be used to make call and mes­sage flows:

It can be con­nect­ed to Twilio Autopi­lot to make AI-pow­ered bots. Tasks are trained with sam­ple phras­es. These sam­ple phras­es are vari­a­tions on what would be said to trig­ger an action e.g. ‘Call recep­tion,’ ‘Front desk,’ ‘Talk to a human.’

An exam­ple that comes to mind, is mak­ing a call han­dling sys­tem for an office. Rather than a voice menu that details each option fol­lowed by a num­ber, the caller could sim­ply say who they want­ed to talk to or what their request was about, and the sys­tem would han­dle it. This is far more respect­ful of the caller’s time com­pared to hav­ing them lis­ten to a long list of choices.

It works with SMS and voice calls, and seems a good way to build an IVR (Inter­ac­tive Voice Menu) sys­tem. TwiML can be used for more com­pli­cat­ed tasks, while still using Studio/Autopilot. The pric­ing is a lit­tle high­er than if you were to use a self-host­ed sys­tem, but there are so many com­pli­cat­ed func­tion­al­i­ties it seems well worth pay­ing the extra, as it would save time and reduce complexity.

I built a remote con­trolled car that used Twil­io’s cell­phone ser­vice. You can read about it here.

ESP32 E‑Paper Status Display

ESP32 E‑Paper Status Display

Using an ESP-32 board with an embed­ded E‑Paper dis­play, I cre­at­ed a gad­get that shows sta­tus infor­ma­tion from my web server.

E‑Paper, also known as E‑Ink, only needs pow­er when being updat­ed, and uses no pow­er between updates. This means that the gad­get can be pow­ered for weeks from a recharge­able battery.

The pur­pose of this gad­get is to put on my wall or desk, and show reg­u­lar­ly updat­ed impor­tant infor­ma­tion on my web serv­er, to keep informed of web site prob­lems and sta­tis­tics. The infor­ma­tion dis­played can be eas­i­ly changed, for exam­ple to the lat­est weath­er, news, cur­ren­cy prices or any­thing that can be accessed via the inter­net. E‑Paper means it uses a very small amount of pow­er and heat, com­pared to a com­put­er dis­play or television.

You can view my code on GitHub if you are inter­est­ed in mak­ing your own.

ESP32 E-Paper Display
ESP32 E-Paper Display
ESP32 E-Paper Display
Telepresence Internet Controlled 4G/LTE Long Range Robot Car

Telepresence Internet Controlled 4G/LTE Long Range Robot Car

For a long time I have want­ed to build a remote con­trolled robot car capa­ble of being con­trolled via the Inter­net, at long ranges using 4G/LTE cel­lu­lar con­nec­tiv­i­ty. So I did.

I used a Rasp­ber­ry Pi 3B+, an Adafruit DC and Step­per Motor Hat, and a Log­itech C930e USB UVC web­cam.

Build­ing the robot
Chas­sis with four motors
Chas­sis with four motors and top sec­tion attached
Com­plet­ed robot 
Com­plet­ed robot

The robot is capa­ble of con­nect­ing to the Inter­net using Wi-Fi. I was able to slight­ly increase the effec­tive Wi-Fi range by using a Mikrotik router and alter­ing the hard­ware retries set­ting and frame life set­tings. The inten­tion was to quick­ly recov­er from trans­mis­sion errors and avoid con­ges­tion. This dis­card­ed video pack­ets that could not be deliv­ered in real time, and kept the net­work clear for when trans­mis­sion would be suc­cess­ful. I also used ipt­a­bles and man­gle to alter the DSCP of the live video stream pack­ets with the same intention.

To enable a long range con­nec­tion, I used Twilio Pro­gram­ma­ble Wire­less to con­nect to local 4G/LTE cel­lu­lar net­works. I sub­stan­tial­ly low­ered the data rate to around 250 Kbps to make trans­mis­sion more reli­able and reduce costs, and was able to get a vir­tu­al­ly flaw­less live feed.

Twilio Wire­less Inter­net of Things Starter Pack
Mon­i­tor­ing 4G/LTE data usage with Twilio Pro­gram­ma­ble Wireless

The live video and audio stream uses FFMPEG for com­pres­sion and stream­ing, and has a pletho­ra of set­tings to tune. I took the time to tune bitrate, buffer­ing, keyframe inter­val. I also ensured the web cam­era was able to native­ly encode video with UVC at the select­ed res­o­lu­tion to reduce the load on the Rasp­ber­ry Pi’s CPU. Video laten­cy was often under a sec­ond, which is impres­sive espe­cial­ly con­sid­er­ing the round trip involved.

Robot remote­ly con­trolled via the internet

The con­trol sys­tem uses Let’s Robot (now, based at Cir­cuit Launch in Cal­i­for­nia, which has a com­mu­ni­ty of robot builders who love to cre­ate and share their devices. The pro­gram­ming lan­guage of choice is Python, and I also linked to an exist­ing API I had cre­at­ed in JavaScript with Node and PM2.

Mission 1

Mis­sion 1 — 30 minute Night Voyage

The first 4G/LTE long range mis­sion was suc­cess­ful, and the web­cam was good enough to be used at night. Dif­fer­ent mem­bers of the com­mu­ni­ty took turns to dri­ve the robot. It didn’t always dri­ve straight, so we had to dri­ve for­ward and turn to the left at reg­u­lar inter­vals. The robot drove for around 30 min­utes, and then got stuck when it fell down a side­walk. I had to quick­ly dri­ve to retrieve it =)

Mission 2

Mis­sion 2 — Involved Drama

The sec­ond mis­sion was intend­ed to dri­ve from my loca­tion to a friend work­ing at a local busi­ness. How­ev­er half way through the mis­sion, a sus­pi­cious mem­ber of the pub­lic grabbed the robot, threw it in a trash can, and called the police. I wait­ed for the police and calm­ly explained that the robot was an edu­ca­tion­al project in telep­res­ence, and also told the per­son report­ing the robot that there were no hard feel­ings, despite inter­fer­ing and dam­ag­ing my per­son­al property.


Mission 3

As part of the com­mu­ni­ty site, it is com­mon to leave your robot open to be con­trolled. While unat­tend­ed, a sneaky indi­vid­ual drove my robot into a void of the house and man­aged to get it cov­ered in spi­der webs and oth­er filth, as you can see below. Thanks.

Cov­ered in cobwebs
Very dirty

I found that cats were very curi­ous about the robot invad­ing their ter­ri­to­ry, as you can see below: 

A curi­ous cat inves­ti­gates the robot

I was very pleased with how the project worked, and had the oppor­tu­ni­ty to use Python, Node, and fine-tune wire­less net­work­ing and live video stream­ing, and of course remote­ly con­trol the robot as I had want­ed to do for a long time.

If you want to build your own robot, the guide to ‘build­ing a Bot­ting­ton’ is a great place to start.

Update: Twilio saw this post and gave me a $20.00 cred­it. Thank you 😁 

Robot sound 4

Page Speed Load Time Optimizations

Page Speed Load Time Optimizations

Here are a few impor­tant ways to speed up page load­ing times, togeth­er with the improved record­ed times for com­par­i­son on a typ­i­cal Word­Press web site. While Word­Press is hard­ly an opti­mized web appli­ca­tion, it does ben­e­fit from the same speedup meth­ods as most web applications.

I used Google Chrome Devel­op­er Tools to time net­work trans­fers and page load times. There are var­i­ous web-based tools avail­able as well:

Initial speed — 1.412 sec (TTFB 0.12 sec)

This was the speed on a fresh install of a Word­Press web site on a small VPS run­ning Nginx and PHP-FPM.

Enabling GZip compression — 1.326 sec (TTFB 0.13 sec)

Using com­pres­sion on net­work trans­fers can great­ly reduce file sizes, espe­cial­ly for text-based files such as HTML, CSS and JavaScript. The CPU over­head on mod­ern servers is neg­li­gi­ble, and can be cached if required.

PHP Opcode cache — 1.299 sec (TTFB 0.124 sec)

PHP scripts are typ­i­cal­ly com­piled to byte­code on demand. By caching this com­pli­ca­tion with OPcache or APC, page load times and serv­er load can be sig­nif­i­cant­ly reduced. APC did include a fast key/value cache, which has now been replaced by APCu.

WordPress Cache — 0.733 sec (TTFB 0.122 sec)

There are many Word­Press cache plu­g­ins avail­able, which reduce the amount of PHP code that has to be run on every request. Some caches can gen­er­ate flat files, which are sig­nif­i­cant­ly faster, and can be used with Nginx.

Nginx FastCGI Cache — 0.731 sec (TTFB 0.119 sec)

Nginx is able to use a fast memory/disk cache to cache requests to PHP-FPM, fur­ther reduc­ing page load times and serv­er loads. This can be very ben­e­fi­cial on web sites with high load.

There are many oth­er ways to speed up page load times, includ­ing depen­den­cy con­cate­na­tion and mini­fi­ca­tion and image opti­miza­tion. It is also impor­tant to opti­mize client-side JavaScript to allow the user’s web brows­er to dis­play con­tent quickly.

AnyCast DNS

An ini­tial vis­it to a web site requires a DNS lookup. Tra­di­tion­al­ly DNS has no way to send requests to the geo­graph­i­cal­ly clos­est serv­er, but this is pos­si­ble with Any­Cast DNS. This fea­ture is avail­able on many providers includ­ing Ama­zon’s Route 53, Google’s Cloud Plat­form and Microsoft Azure. It func­tions by allow­ing mul­ti­ple servers dis­trib­uted through­out the world to have the same IP address.

By using Any­Cast DNS, I was able to reduce an ini­tial DNS request from 93 mil­lisec­onds to 18 mil­lisec­onds. Com­bined with hav­ing an opti­mized web serv­er geo­graph­i­cal­ly close, even an ini­tial vis­it to a web page can be dis­played instantaneously.

Before Any­castDNS

After Any­castDNS


Sub­tract­ing the round trip time to the serv­er of 0.116 sec­onds, these opti­miza­tions reduced the effec­tive Time To First Byte to 3 mil­lisec­onds. On a busy serv­er, these opti­miza­tions will make a sig­nif­i­cant dif­fer­ence to the capac­i­ty of the server.


SSL/HTTPS Mixed Content Warnings — How to Automatically Report Errors

SSL/HTTPS Mixed Content Warnings — How to Automatically Report Errors

The gen­er­al push to use SSL/HTTPS for every web site is improv­ing secu­ri­ty and pri­va­cy on the Inter­net. How­ev­er, every request a web site makes will need to be secure, or browsers can remove the ‘Secure’ indi­ca­tor, show a warn­ing sym­bol, and some­times pop up errors.

You can add a sim­ple head­er that will tell browsers to report back to your serv­er if any inse­cure requests are made. I com­bined this with a sim­ple PHP script that logs to the server’s error log.  This alerts me to sites I host and devel­op that have inse­cure con­tent, so I can fix them.

Step 1 — Add the Content Security Policy reporting header

add_header Content-Security-Policy-Report-Only "report-uri /csp-report-endpoint.php";

Step 2 — Add PHP Script

Add this sim­ple PHP script as csp-report-endpoint.php:


Now, when a site attempts to load an inse­cure resource, you will get a mes­sage in your error log, and you can use this infor­ma­tion to fix your site.