When I first started caching, travel bugs didn’t even exist, but they were in the making. I remember thinking that they were a good idea at the time and ordered four of them right away when they came out. At that point in time, I didn’t know what I wanted to do with them, but decided that one of them would be my personal bug that I would take with me to every cache. I would virtually log it into each cache so I could keep track of mileage for myself when I was caching. It was also nice because it has every log that I’ve written for each and every cache that I’ve found. I’d copy and paste the log I’d write for the cache and then paste it into my retrieval log for the travel bug. I decided to call the travel bug, A Walk With Webfoot, not particularly because I walked to every cache, most I did drive to, but I wanted it to convey the message that geocaching was a walking activity, that you should get out and enjoy the outdoors.
If you clicked on the link above, you probably noticed that the travel bug page takes an incredibly long time to load. I started noticing this several months ago. I even wrote emails to friends asking them to check it out and they all agreed that it was loading slowly. It seemed like all other pages at GC.com loaded quickly, with the exception of that particular page, so it seemed like I couldn’t even blame the hamsters that were running the servers at GC.com.
I have a system worked around, so I never have to worry about how long the page takes to load when I’m logging caches. When I log a cache, I click on the “Log your find” link, then use another tab to then click on the Walk With Webfoot page. While I’m writing my cache log, the Walk With Webfoot page loads. It’s loaded by the time I’ve finished writing the cache log and clicked the submit button, so then I just toggle to the travel bug page and then retrieve the travel bug from the cache page and repeat the process for the caches. It hasn’t been a problem thus far, but I wanted to know from the Powers that Be at GC.com what was up and why it was taking so long for that particular page to load, so I sent a trouble ticket to Groundspeak.
“Trackable pages were never intended to be used as personal log pages. Because it is being used in a manner for which it was not designed, it will take longer and longer to load, the more content it takes on. There may be others with more entries, but yours is one of the largest for total data size.
Is this his polite way of saying I’m verbose?
But then, I started thinking to myself, wait a minute. This is a travel bug. It's designed to travel from cache to cache, having cachers find it and write on the page about it. Groundspeak has on one of their pages the following information about travel bugs. “A Travel Bug is a trackable item that moves from place to place, picking up stories along the way. Here you can add your own story, or live vicariously through each bug's adventures.” So why is a personal log page different than a regular travel bug? If a travel bug ended up in a cache and then was taken by the next cacher who then wrote a story about it and then dropped it in another cache and it happened again and again, wouldn’t that cause that particular bug’s page to load more slowly? Of course it would. So I guess the next question is, did Groundspeak not anticipate travel bugs having lots of entries, or were they just expecting travel bugs to disappear quickly?
Now, I know most people will read this and say, “but your page has a lot more entries.” Yes it does, but if it’s a travel bug, shouldn’t Groundspeak have anticipated a travel bug possibly having a lot of entries? I mean, isn’t that what they were supposed to do, travel from place to place, picking up stories? It’s a puzzlement, that’s for sure and it’s just been on my mind recently.
I’m planning on retiring A Walk With Webfoot when I get to 2000 cache finds. I have a geocoin all picked out to continue my caching trek. Until then, I’ll continue to use my logging method described above.All pictures have been main pictures from A Walk With Webfoot at different points in time.