<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Daniel Parker</title>
    <description>The latest articles on DEV Community by Daniel Parker (@goldendunesdesertsafari).</description>
    <link>https://dev.to/goldendunesdesertsafari</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4204491%2F74595dd9-af13-4821-ba18-c4c42ffa9f6a.png</url>
      <title>DEV Community: Daniel Parker</title>
      <link>https://dev.to/goldendunesdesertsafari</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/goldendunesdesertsafari"/>
    <language>en</language>
    <item>
      <title>What rebuilding a small tour-booking page taught me about page speed</title>
      <dc:creator>Daniel Parker</dc:creator>
      <pubDate>Sat, 24 Oct 2026 10:47:25 +0000</pubDate>
      <link>https://dev.to/goldendunesdesertsafari/what-rebuilding-a-small-tour-booking-page-taught-me-about-page-speed-244f</link>
      <guid>https://dev.to/goldendunesdesertsafari/what-rebuilding-a-small-tour-booking-page-taught-me-about-page-speed-244f</guid>
      <description>&lt;p&gt;Most speed advice is written for big apps. I spent time on the opposite end of the scale: a single small booking page for a tour business, where every extra script and oversized image showed up directly in how the page felt on a phone.&lt;/p&gt;

&lt;p&gt;Here is what actually mattered, in the order I would do it again.&lt;/p&gt;

&lt;h3&gt;
  
  
  1. Measure on a real phone, not just on a desktop
&lt;/h3&gt;

&lt;p&gt;Desktop scores flattered the page. The problems only showed up on a mid-range phone on a mobile connection: images that were far larger than the screen, and third-party embeds loading before the content a visitor came for. If you only test on desktop, you are testing a different page than most visitors see.&lt;/p&gt;

&lt;h3&gt;
  
  
  2. Images first, everything else second
&lt;/h3&gt;

&lt;p&gt;The single biggest win was resizing images to the size they are actually displayed at and serving a modern format, instead of uploading camera-sized files and letting the browser shrink them. A hero image does not need to be several megabytes to look good on a phone screen. This one change did more than any plugin or script tweak.&lt;/p&gt;

&lt;h3&gt;
  
  
  3. Load third-party stuff last
&lt;/h3&gt;

&lt;p&gt;Maps, chat widgets and review embeds are useful, but none of them is the reason someone opens a booking page. Deferring them until after the main content — or loading them only when the visitor scrolls near them — kept the page usable while the extras caught up in the background.&lt;/p&gt;

&lt;h3&gt;
  
  
  4. Keep the booking path short
&lt;/h3&gt;

&lt;p&gt;Every extra step between "I want this trip" and the booking form is a place to lose someone. The page that worked best stated the trip, the timings and the price up front, with one clear next step, instead of making visitors hunt through sections to find the basics. You can see how that reads on &lt;a href="https://abudhabidesertsafaritour.com" rel="noopener noreferrer"&gt;the live booking page&lt;/a&gt; for the desert safari site this came from.&lt;/p&gt;

&lt;h3&gt;
  
  
  5. Don't chase a perfect score
&lt;/h3&gt;

&lt;p&gt;A perfect Lighthouse score is not the goal; a page that loads fast enough that a visitor never notices the loading is. Once the obvious weight was gone, further tweaks had diminishing returns, and time was better spent on the content itself: clear timings, honest descriptions of what is included, and photos of the actual experience rather than stock imagery.&lt;/p&gt;

&lt;p&gt;The unglamorous lesson: for a small site, speed work is mostly subtraction — fewer images at full size, fewer scripts up front, fewer steps to book. Nothing here required a framework change or a rebuild, just deciding what the visitor actually needs first.&lt;/p&gt;

</description>
      <category>performance</category>
      <category>webperf</category>
    </item>
  </channel>
</rss>
